> Asm is simple enough that "mental execution" is far easier, if more tedious, than in HLLs
Ya totally I can also keep 32 registers, a memory file, and stack pointer all in my head at once ...fellow human... (In 2026 I might actually be an LLM in which I really can keep all that context in my "head"!)
For real! I occasionally write assembly because, for some reason, I kind of enjoy it, and also to keep my brain sharp. But yes, there is no way I could do it without pencil and paper (unless I’m on a site like CPUlator that visually shows everything that’s happening).
Expressing qualms about hiring somebody who has voluntarily demonstrated a lack of ethics isn't 'being an asshole'. In fact, it's usually a good business decision and always an ethically-sound one.
Here's a sample question, feel free to use:
"If somebody offered you money to build the brains for fully-autonomous killbots PLUS mass domestic surveillance of the civilian population, would you accept the offer?"
"Yes" => They are unethical => No-hire.
"No" => They did do that, and thus are a liar, and thus are unethical => No-hire.
> absolutely none of these things will fly on an interview feedback in any big company
Sure, you never write "no hire because they worked at Palantir". You write "candidate didn't ask clarifying questions about {X} and jumped to answer {Y} which is not what I expect from a candidate of this level, no hire".
....this assumes that anyone at all reads your detailed notes if you submit an initial rating of "no hire", and I have very little evidence from my interviewing career across multiple companies to believe that's the case..
My experience at FAANG is that if you get a "no hire" vote, then unless several other reviewers are "strong hire" the candidate doesn't even make it to a committee and is already rejected - and this was before 2022.
If you want to blatantly lie and hide your true reason for rejecting them by making up other stuff in the debrief notes, that would be possible. But at that point, you are the unethical person. You can technically do the same thing just because you wanted to discriminate based on race, sex, etc (that would be both illegal as well as violation of corporate HR policies).
> I think this is solid proof that the bedrock of academia is deeply motivated by money and still defaults to optimizing where it impacts its bottom line.
no shit - could've asked literally anyone that's finished their phd to save yourself the conjecturing/hypothesizing about this fact.
> My conclusion after using Julia for many years is that there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters.
i hope you realize this is purely because julia uses LLVM and LLVM has backends for those targets (noticeably absent are GPUs which do not have LLVM backends). any other language which uses LLVM could do the same exact same thing (and would be hampered in the exact same way).
Probably true, but one unique thing about Julia is, that exposes almost all stages of the compilation to the user. From typed IR to native code generation you can customise the compilation in many ways. Together with the power of LISP's metaprogramming features, that's a really fine basis for powerful and performamt DSLs and code transformations.
All those GPU targets are powered by libraries, that are not part of Julia itself (GPUCompiler.jl). The same goes for automatic differentiation. That's remarkable in my opinion.
So you're right, that many programming languages could do it, but it's no wonder, that other languages are lacking in this regard compared to Julia.
> but absolutely no one is going to switch from C to C++ just for dtors
The decision would be easier if the C subset in C++ would be compatible with modern C standards instead of being a non-standard dialect of C stuck in ca. 1995.
For two reasons: First, where C++ features are used, it make the code harder to understand rather than easier. Second, it requires newer and more complex toolchains to build GCC itself. Some people still maintain the last C version of GCC just to keep the bootstrap path open.
This is not my experience at all. In fact, my experience is where C++ is used in GCC it became harder to read. Note that GCC was written in C and then introduced C++ features later so this is not hypothetical.
In general, I think clean C code is easier to read than C++ due to much less complexity and not having language features that make it more difficult to understand by hiding crucial information from the reader (overloading, references, templates, auto, ..).
Ya totally I can also keep 32 registers, a memory file, and stack pointer all in my head at once ...fellow human... (In 2026 I might actually be an LLM in which I really can keep all that context in my "head"!)