News for hackers. Stuff that matters.
Re:Apple is looking for engineers to convert its code from C... by anonymoushn on Saturday March 21, 2020 @04:34AM (#22645338)
This sort of standard seems hard to meet for any language, if the bar is "all abstractions should be included and zero-cost." In practice, you probably write a specialized quicksort for a given type in C to work around the lack of generic quicksort. You do this in the same way you manually convert your suspendable forkable computations into a struct that has all your "local variables" and an "instruction counter" inside to work around the lack of copyable coroutines in almost every language.

Depending on your choice of compiler, a more legitimate concern with C is maybe the lack of computed goto. See here about the nonzero cost of missing this feature: https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...

Re:Apple is looking for engineers to convert its code from C... by emn13 on Saturday March 21, 2020 @09:30AM (#22646349)
So there's an intrinsic cost to abstractions: namely that by using an abstraction, you're not specializing to the optimal extent possible; your general-purpose algorithm may well be close to ideal, but various details will not be; and even in languages that support specialization, you're likely to end up in a not quite optimal solution.

But that's not what people usually mean with zero-cost, right? They mean that assuming you do use the same algorithm, then the abstracted version is just as fast and memory efficient as the specialized version.

And that is a bar that C++ at least clearly meets, and, by the looks of it, rust is in practice much closer than C. Other languages have various features that address this need too; it's not that rare. C really is particularly poor here, but even C has macros, and although it's horrible in terms of usability, people nevertheless manage to do some pretty nifty stuff with macros.

Still; it's fair to say C is pretty bad at zero-cost abstractions, and that widely used alternatives support that a lot better (even C++ alone is a solid chunk of the market, more than C - https://redmonk.com/sogrady/2020/02/28/language-rankings-1-2...) Implementing a custom quicksort in C is a pain, enough pain that I expect most hand-tuned special case quicksorts are likely slower than general versions available for C++ simply because people aren't going to bother doing a good job; it's too much work. And that's just quicksort; the same goes for lots and lots and lots of other things too; reimplementing everything from scratch is just too much pain - in practice people are likely to not bother, and just pay the costs.

So while "zero-cost" abstractions are a slightly nebulous goal, clearly C in particular is worse at providing those than all of its low level competitors and wannabe competitors (C++, Rust, D, Nim, etc).

Re:Apple is looking for engineers to convert its code from C... by anonymoushn on Saturday March 21, 2020 @10:36AM (#22646747)
This is a great comment and I endorse it.

Lots of other languages make it way easier than C to write "fused quicksort". Although it doesn't pay much regard to programming language theory, Jai is another interesting language in this area, made by a guy who's mostly concerned with being able to express the fully specialized/fused version of everything without creating extra work for the programmer.