Keegan McAllister writes technical posts on Rust, low-level Linux and x86 tricks, and kernel exploitation, plus some essays on depression and online activism.
HN links it for the tiny Rust binary and the x86 no-registers Turing-completeness posts, and commenters cite its kernel JIT spraying write-up.
> Being pragmatic is a very questionable claim. Its exact meaning varies from time to time, and a property that a certain people consider to be pragmatic can be considered to be not pragmatic by another people. It's mostly meaningless.
I disagree that it is meaningless. It's simply subjective. I've used D since 2006 and tried most new programming languages that appeared since, and it seems like they all tried to solve a specific problem (e.g. Go - concurrency, Rust - memory safety) while giving less attention to everything else.
> For example, for embedded devices D is a no-go from the beginning.
Existing D projects contradict that. They simply don't use the standard D runtime when it's not appropriate. Alternative runtimes exist. Rust users do the same thing:
http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html
> D and Rust have different kinds of expressiveness. While D has much better compile-time metaprogramming, how do you express affine type in D? In Rust affine type is very fundamental and we can utilize it to define the exact meaning of our programs.
Can you provide a good example of affine types and how they help with expressiveness?
My view of expressiveness in D does not stop at compile-time metaprogramming. For example, here's an excerpt from one of my programs:
http://dump.thecybershadow.net/fb6c5a080c7a42ecd8d1f062b58a540d/000000CF.txt
> How can a GC'ed language be faster than a non-GC'ed language?
It is entirely…
> UNIX is married with C, so any attempt to replace C, means breaking with the UNIX mindset, which has proven very hard to do.
I don't believe this is particularly true, although I haven't explored it very far. UNIX is married with the API/ABI exposed by the so-called "C" library. So far, there have been no languages that offer native interoperability with C and have gained significant popularity, other than C++, and C++ is certainly pretty popular on UNIX (Qt, gcc, etc.). Rust does offer that and is (evidently) picking up a ton of steam, and you can get to the point where stupid tricks that previously required a C derivative can be done in Rust.
http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html
In fairness, this often also requires things like "C" strings, the "C" locale, etc. But those things can either be done smoothly enough from Rust, or are wrong anyway, that I think there's a chance to break the C stranglehold here.
"To complicate matters, most of the people in the industry are young men, a cohort not good at acknowledging their own problems, or understanding other people’s."
Does this not seem like oversimplification and rampant stereotyping?
I am a "young man" (well, below 30 anyway, though in SV I'm probably a bit long in the tooth), and it hurts to be constantly and systematically belittled in this manner. I have problems, and other people in the industry do too. Singling out one particular gender and age group and making them the bad party doesn't help anyone.
A great related article: (http://mainisusuallyafunction.blogspot.com/2014/06/on-depression-privilege-and-online.html)
As with everything, there are tradeoffs - For instance this from a few years ago:
http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html
Which allows bpf-jit to be part of a larger privilege escalation scheme. (To properly use this attack you need to gain control of an applicaion first, then you can maybe use this attack, and if successful you own the box).
I haven't kept up with this at all, so I don't know if it has been fixed (or even is fixable) but it is interesting.
A direct comparison like that is somewhat comparing apples to oranges. Don't get me wrong, defaults matter, but Rust still does offer the control required to get small binaries, and, those defaults are not nearly as bad for low-level domains where one isn't using the standard library, which is where binary size is most critical. See also https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html and even http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html .
I guess the examples use the default std libs, and runtimes of the languages. So in this sense your D example is the misrepresentation, by directly calling libc.
If these kinds of low level size optimizations are enabled then both Nim and Rust can be more than 50 times smaller than your D example ;) :
150 byte Nim: https://hookrace.net/blog/nim-binary-size/
151 byte Rust: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html