Probably the answer around 45m. The channel makes sense with coroutines, but once you’re completely synchronous it just adds overhead.

I have a feeling this is another case of, when a new paradigm starts to take off (the actor model) everyone wants to write everything in it, and it all seems beautiful until we actually work with it and begin to learn why this new idea is not always appropriate for every task.

He's a very good speaker. I do enjoy his talks. Even if you're not interested in the topic, you'll become interested in the topic. You come away with insights that you didn't even know you were missing before watching the talk.

Underrated comment. Great to know, thank you!

The CL chose to revert back to the initial design because it is simpler, but the workaround is pretty simple too. In fact the workaround seems simpler than using a goroutine, because you no longer have to juggle the execution of two concurrent functions in your head: Original goroutine method: run() function keeps running in the background, occasionally pushing an item into the channel. nextItem() function will block until it receives something from that channel. Number of running functions: 2. New workaround method: Calling nextItem() will repeatedly call the state transition function until one of the state transitions pushes an item into the channel, at which point that item is simply returned. Number of running functions: 1. I think the goroutine method is just using goroutines for the sake of using goroutines.

This appears to work: talks.golang.org/2011/lex.slide#1

The parser code is there: golang.org/src/text/template/parse/parse.go I did not find any course on the topic either, though

Jackson structured programming is hardly obscure.

Andy Herbet Nerd

Fairly certain it was a joke.

Go 的成功证明你就是个傻逼，事实证明了你真是个傻逼。

It was a joke and I'm so sad no one laughed! I sure did when I heard him offhandedly quip "as you know, Michael Jackson developed Jackson Structured Programming".

I am interested if you are still interested in helping me out?

ochgottnochma github.com/golang/go/blob/master/src/text/template/parse/lex.go

Сергей Линник Nice, thanks!

Reminds me the horrible days of Math courses: "We'll skip this demonstration, it's trivial." "IT IS? Gosh I'm lost..." I couldn't agree with you more

No, but it is available on PyPi: pypi.python.org/pypi/nonblockingloghandler/

@@skepticmoderate5790 lmao bf doesn't even require lexing. Each character is a token. This is the worse qualification to talk about parsing.

@@russellchidoCan you explain this in more details?

@@kamilziemian995 I think he's just saying that brainfuck doesn't need lexing, you just emit each character as a lexeme, don't know why that would make this talk bad but ok

You have to call the "run()" method on the lexer you get back before you would get anything from the channel. I suppose that could be kicked off inside the same lex() function, but that's not how it was shown in the talk.