supersillyus

IIRC Servo is using html5ever for HTML parsing, which (at least in one branch) uses SSE4.2 for parsing.

So, do you consider the Go1 compatibility guarantee to be a mistake? Most suggested stdlib or lang improvements are DOA for the time being as a result, which is annoying, but of course so too would be frequent breakages. I'm curious about your take, since you have some relevant experience.

I read that they have static analysis tools to track the flow of Contexts, making it much easier to verify that Contexts are threaded through correctly, which can make things a bit safer statically. It seems Go-like I guess: instead of language support for that sort of type system, simple enough lang and good enough tooling to implement the analysis externally.

Yes, in the same sense that any language with first class functions can.

So, like:

   var SomeFunc = RequireAuth(func(...) {
        ...
   });

However, there's no language-level support, so you can't decorate methods as easily as you might in a language like Python.

I somewhat disagree. Even if you don't use channels as iterators/generators (which many folks do), it's not hard to end up with a goroutine blocked on a channel that'll never be closed/written to, and this situation (like memory leaks) can result from changes elsewhere in the program or branches not normally taken. A goroutine count doesn't seem like it'd be useful for diagnosing this in a non-trivial program. The runtime could probably detect if there are goroutines blocked on channels that no other goroutine has access to, and that'd be quite helpful for debugging, but as of now it doesn't. Even if it did, it couldn't catch all goroutine leaks.

You can leak memory by leaking goroutines. If a goroutine is waiting on a channel that nobody else has access to, it lives forever, as does the memory it references.

So, you can pretty easily leak memory without messing with unsafe things.

According to Last Call by Daniel Okrent, Gough St was named after famed temperance orator John Bartholomew Gough. I'd assumed that was true until I saw this site. Wikipedia has support for both theories, but it looks like Charles H was the real namesake.

Why should C and Go (AOT compiled) be faster than Java for pure integer numerics? For long-running simple tight loops of numerics, I'd assume HotSpot would be faster.

I agree with them on the readability issue mostly, but I don't understand the preference for parens-less function calls, especially where there are arguments.

Maybe it's a matter of training, but

   @_update_status_position(e, files)

looks much clearer to me than

   @_update_status_position e, files

If you don't care about types, schemas, and schema changes, probably not.

My "ah ha" moment with Haskell was after a few years of using it quite regularly, I realized that it wasn't actually making me more productive in the kind of code I actually write from day-to-day. It's a lovely language and I wouldn't discourage anyone from using it, but for my purposes I realized it was more exciting than useful at some point, and after that I haven't been back to it as much.