It's been a little while since I looked at it, but I recall that much less state had to be saved in an Erlang process switch in the usual case; I seem to recall it can be done in a handful of instructions in many cases. Go of course has to save a bunch of registers much as you'd have to do in any native context switch.
Edited to add: it can be useful to look at that part of the BEAM disassembled in objdump or gdb, to appreciate it, since it's hard to tell how much work is happening with all those macros.
I've worked a bunch in both, and Go really doesn't compare; you can't judge based on watching a talk. I find it much, much easier to write safe, robust code in Erlang, and operationally, you have so much more power to inspect the state of the BEAM. Another key BEAM thing is the process heap, which amounts to region allocation when used carefully. The reduction mechanism used for scheduling processes, though crude, is also still much lighter-weight than Go's approach.
On the other hand, Erlang is a weird language and a weird environment, that takes a lot of time to really understand, so I understand why it's never going to "win", and golang tools and the runtime will continue to improve. YMMV.
Hobbyists move first. Speaking of nostalgia, I'm sure you remember when people would mention they were moving to Linux and were laughed at — Windows, Solaris, AIX, HP-UX, and so on were the serious server OSes.
I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it's good.
https://www.sqlite.org/malloc.html is a welcome contrast to the typical behavior you're describing, but I agree that such measures are rare. (and, not an application: though it provides the mechanisms for applications to follow its lead.)
Our team is developing brand new hardware to do high-performance neural network and deep learning inference. We're remote-first, senior people trying to raise the bar on high-performance and low-energy AI hardware.
We have interesting problems in the domains of optimizing compilers, graph algorithms, computer architecture, and machine learning. Candidates with experience working with performance-sensitive systems preferred.
Our team is developing brand new hardware to do high-performance neural network and deep learning inference. We're remote-first, senior people trying to raise the bar on high-performance and low-energy AI hardware.
We have interesting problems in the domains of optimizing compilers, graph algorithms, computer architecture, and machine learning. Candidates with experience working with performance-sensitive systems preferred.
Our team is developing brand new hardware to do high-performance neural network and deep learning inference. We're remote-first, senior people trying to raise the bar on high-performance and low-energy AI hardware.
We have interesting problems in the domains of optimizing compilers, graph algorithms, computer architecture, and machine learning. Candidates with experience working with performance-sensitive systems preferred.
Reading code is essential to growth as a programmer. I do it all the time, often for pleasure. But reading snippets without context, like you're suggesting, is a common source of bugs in my experience.
So often when working on a legacy codebase, I'll track down a bug to some bit of code that makes no sense, and then search for that code and find it on Stack Overflow or similar. Even examples from documentation can be dangerous taken out of context; I can think of numerous times I encountered this with snippets that had been copied directly from MSDN without understanding.
Given that poorly-understood code reuse was implicated in many of our industry's greatest disasters, maybe the legality isn't what our concern should be here.
Yep, seems to be pitch class notation with T and E replaced with a and b. People interested in this kind of orthogonality should definitely check out Introduction to Post Tonal Theory by Joseph Straus. Even outside of the serial contexts people traditionally associate with that notation, there are interesting things that can be done with it.
I wouldn't scrutinize it too much as the benchmarking approach is wildly inaccurate, but I'm curious about that too. I might investigate it later. (I am the author of the post.) This was also run on a pretty ancient AMD machine, which isn't terribly representative of modern branch prediction hardware.
Well, it's been happening since the '80s when several OSes were written in ostensibly garbage-collected languages. So it might be a little late to complain.
Since the average professional software engineer has more experience than our average subject,
the effect sizes reported may be overstated for some populations
I did this about a year ago after being self-employed for about 6 years. One of the biggest reasons was actually the social aspects of working; I rarely worked with other people, or if I did, not for long.
There are plenty of downsides to going back to being an employee, though. I wouldn't do it if it weren't with the right people. At the time, I took a pay cut to do it, but it worked out and I'm happy with my decision, because I got what I wanted: to work with great people and build relationships with them. And the reduced stress from not having to hustle all the time has been good.
Since you're self-employed, take your time and really find an employer that suits you. You have a lot of leverage in negotiations since you know you don't _need_ any given job you interview for.
I've gone through more than one cycle before of building up a set of clients from scratch, so I know that I can always go back to freelancing if I want to. I wouldn't be too worried about getting stuck as an employee unless you let your skills stagnate.
I don't think it's that unusual, but obviously there are tradeoffs.