tokenrove

This paper was influential with regards this idea: https://www.usenix.org/conference/hotos-ix/crash-only-softwa...

I don't think it's that unusual, but obviously there are tradeoffs.

Check out Kleinrock's Queueing Systems.

And, note, I'm not saying Go is bad, here, just that there is a lot that is underrated and misunderstood about Erlang.

On the Erlang side, check out the BEAM Book chapter on scheduling: https://blog.stenmans.org/theBeamBook/#CH-Scheduling and the core scheduling loop in the BEAM: https://github.com/erlang/otp/blob/master/erts/emulator/beam...

On the Go side, check out https://github.com/golang/go/tree/master/src/runtime/proc.go and the asm* implementations.

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.

No, it was the need for this on Windows that made Citrix all its money.

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.)

Untether.ai | multiple developers | Toronto & Montreal, Canada | REMOTE | Full-Time | https://untether.ai

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.

Untether.ai | multiple developers | Toronto & Montreal, Canada | REMOTE | Full-Time | https://untether.ai

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.

Please reach out directly at careers@untether.ai.

Untether.ai | multiple developers | Toronto & Montreal, Canada | REMOTE | Full-Time | https://untether.ai

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.

Note that the claims in that abstract were retracted because the authors messed up when benchmarking. Note the changed title and abstract here: https://cseweb.ucsd.edu/~lerner/papers/fp-printing-popl16.pd...

Yeah, I should have finished this article when it was still fresh. Hardware always seems to catch up with codegen from the '70s.

(Thanks for the excellent paper reference.)

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.

The most useful caveat, from the paper:

  Since the average professional software engineer has more experience than our average subject,
  the effect sizes reported may be overstated for some populations

Also, grafx2 is very heavily DP-inspired: http://pulkomandy.tk/projects/GrafX2

Great for pixelling.

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 agree, although I think this is mostly cultural.

If we're only talking about single-threaded, CPU-bound code, this is basically true of any imperative language without fancy data structures: even a fairly naive native compiler will produce "pretty fast" code in our modern times where the standard for pretty fast is pretty low.

It seems intuitive that the further a language is from the machine, the harder the compiler has to work to make that language's idiomatic constructs efficient on a machine.

The kicker here is that C is no longer so close to the machine. It's still a PDP-11, and today's machine is not. This idea is what I think is still useful about the original article, for all its other faults.

I admire compilers like MLton that actually deliver on the promise of higher-level languages without the usual performance compromises for abstraction. Hopefully we'll see more of this as time goes on, as well as more languages like Sequoia that are close to the new machine.

An underlying point to this article that is still true is that C isn't inherently fast -- you have to work together with the compiler to make sure it generates what you want.

Why is this even worth pointing out? Well, in many languages communities (Common Lisp is a good example), the speed argument comes up, and it's pointed out that carefully working with the compiler (declares in all the right places and so on) makes the implementation competitive, and this is often dismissed as "too much work", ignoring the fact that even in C, there's no free lunch.

When one recognizes that good performance often requires a dialogue with the compiler, one starts to recognize that a criteria for performant language implementations is not "it's just like C" but rather "it's possible to tell the compiler to make this fast".

This makes many alternate languages viable choices for high-performance work (and eliminates some!), at least based on the current state of their implementations.

Imagine if as much work had gone into their compilers as has gone into the production C and Fortran compilers of today.

https://github.com/danluu/debugging-stories is a good start

To answer the titular question: I hate C++ because I worked in it for 10 years, and I came to realize things could be otherwise.

I almost came back to the language with C++11, but its core problem remains the same: the only maintainable codebases seem to be those strictly ruled over by language experts with an iron fist -- and too many people think they're experts (hint: if you haven't read the language standards (or written them!) and hacked on a compiler or two, you probably aren't an expert).

You inevitably have to choose an opinionated subset of C++, which often results in a language which is more on par with many modern languages, but with more pitfalls and traps, and which you have to teach to every person you bring on board.

And let's not even start on compile times and other problems C++'s legacy brings with it.

FWIW, I still do a lot of C and assembly. Modern C is pretty nice, although it will be nice to see a newer systems language finally take over.

You will probably end up doing C++ professionally, and that's fine, but for your own sake and the sake of your coworkers, learn some other languages that will broaden your mind.

You can find many suggestions in this thread, and I could go on about the more mind-broadening ones (logic programming, dependent types, metaprogramming, etc), but the most valuable might be another systems language, even if it's not popular, just so you can see how things could be otherwise. I think reasonable candidates might include Ada, Modula-3, Rust, D (which is a little too close to C++), BLISS if you can track down a compiler, Forth; maybe even Common Lisp.

If you are manually adjusting the volume of the track in response to its level, you are performing compression manually.

The overcompression people complain about in the "loudness war" could have been added at the mixing stage, but is much more likely to have been added at the mastering stage.

TAOCP is also great because the implementations are in assembly language, which encourages you to think about efficiency in terms of the operations your machine performs, not statements in some high-level language. Not only is the writing excellent, but it is clearly written by a programmer with much practical experience, unlike some other algorithm texts. I deeply wish there were more modern books in the same style, with the same spanning focus of high and low level concerns.

Sadly no mention of SCTP, which, if you don't need to communicate with arbitrary hosts over the Internet, sits in a nice middleground between TCP and UDP.

When developing something new, I make tons of tiny work-in-progress commits, sometimes dozens in a day, and frequently go back and squash them with rebase into a logical flow of changes, once it's more clear what that logical flow really is. I keep my WIP branches around locally for a while so I can go back and dig out the experiments I made along the way.

I prefer this over trying to get every commit right the first time. I also feel there's a nice change of pace in the process of stepping back, looking over the previous work, and shaping it into something that communicates the ideas well to reviewers.

Consider SCTP as an alternative if you want messages but want them in order.

It's great to see this available and updated. It was one of my favorite compiler books growing up because it's so small and straight-forward. I feel it's a much better starting point for someone actually interested in building a compiler than say, the Dragon book.

Even more immediate and hands-on is Abdulaziz Ghuloum's "An Incremental Approach to Compiler Construction" paper: http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf (which chides Wirth for oversimplifying)