4 ms·
> Seems like the wrong problem to solve. "Systems programming" is hard, and should be hard, for reasons unrelated to the programming language used. Something li
by K0nserv 2y ago
> Seems like the wrong problem to solve. "Systems programming" is hard, and should be hard, for reasons unrelated to the programming language used. Something like Rust which forces you to constantly reevaluate your design before you even press the compile button, is ideal.
I was recently musing about this on Mastodon[0], commenting on a tweet that said something to the effect of "C++ isn't complex, it just doesn't lie about the complexity of reality". I think Rust is similar, and really any system language has too be. However, there's a space between lying about reality and fully reflecting reality where useful abstractions, such as Rust's lifetimes live. If you hardline the "lying about reality" framing, any abstractions on top of machine code must be ruled out. So while I see where you are coming from, I think lots of space to improve system programming, as Rust did.
> What's really lacking are safe, easy, strong typed general purpose languages that can leverage AOT compilation for high performance and static analysis etc. A language with the learning curve of Python, near C performance and strong safety guarantees of Rust. There is nothing that suggests to me such a language would not be possible. Swift and C# come closest but they are warped by their respective corporate overlords.
I agree about Swift fitting this mold, it's unfortunate that it has failed to gain traction outside of Apple's ecosystem.
0: https://infosec.exchange/@k0nserv/112399102914339131 https://infosec.exchange/@k0nserv/112399102914339131
- neonsunset 2y ago.NET of today seems to stand out quite a bit in comparison to many other MSFT-backed projects. Especially if you look not at non-essential and possibly azure-related (a tiny part of ecosystem) tooling but rather at the "core" itself (that is, SDK, runtime and compilers) which is distributed under permissive MIT license which you can just take and do anything with. To surprise of many outside of .NET community, it has much better performance than Swift[0][1][2] and lets you match performance of C and C++ in areas that matter. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/swift-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-csharpaot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (better performance for short-running benchmarks sensitive to JIT) [bonus] C# AOT vs Go https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-csharpaot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (no direct comparison but Tl;Dr: ARC and Swift defaulting to virtual dispatch that can't always be elided with WMO results in Swift having much lower (even if more consistent) performance)
- pjc50 2y agoWith AOT and "[UnmanagedCallersOnly]" you can even emit C# libraries that are callable from true native code using the C FFI.
- neonsunset 2y agoYup, you can even statically link them into C/C++/Rust/etc. (or vice versa)!
- igouy 2y agonow direct https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/swift-csharpaot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- neonsunset 2y agoThanks! Also wow, I stand corrected, Swift is a much stronger contender in Benchmarks Game scenarios than earlier microbenchmarks and research projects that I've seen would suggest. Particularly when using its own SIMD abstraction, it is likely LLVM makes very competent transformations, possibly merging narrower operations into a wider ones, replacing one set of intrinsics with another, etc. However, still seems to suffer quite a bit, just like Go, in Binary Trees (it's not like C# does the best there either, the winners use bump allocators, and then there's also a 2.6s magic entry by Java, write barrier elision?).
- gjm11 2y agoIt doesn't feel to me like much of C++'s complexity is just "the complexity of reality" being faithfully exposed. I'd wonder whether that's just me being dim, but if so then I think Bjarne Stroustrup and Herb Sutter are dim in the same way. (Stroustrup, quoted approvingly by Sutter: "Inside C++, there is a much smaller and cleaner language struggling to get out." and "Say 10% of the size of C++ in definition and similar in front-end compiler size. ... most of the simplification would come from generalization.") And it doesn't seem likely to me that they are ignorantly overpessimistic about the complexity of C++.
- UncleMeat 2y agoC++ has a bazillion different ways of initializing a value, most of which contain syntactic footguns of some kind that don't do what you probably intended. That's not fundamental complexity of reality, that's messy evolution over decades coupled with the inability to break backwards compatibility. C++ also does "lie" about reality in a lot of ways, in the sense that the actual compiled program behaves quite a bit differently than a plain reading of the code implies to a nonexpert. The most obvious form of this is the rules for effect ordering. Even the recurring complaints about the compiler doing unexpected things based on the as-if rule and undefined behavior seem to count here.
- pjmlp 2y agoActually, it has enough for having a 200+ pages book full of them. "C++ Initialization Story: A Guide Through All Initialization Options and Related C++ Areas" https://www.amazon.com/Initialization-Story-Through-Options-Related/dp/B0BW38DDBK https://www.amazon.com/Initialization-Story-Through-Options-...
- ModernMech 2y agoC++ is the poster child for incidental complexity.
- bluGill 2y agoThe reality is people have 30 year old code bases, and so a messy evolution without breaking backward compatibility is and important part of reality. C++ could have been a much better language without backwards compatibility - but nobody would used it and so what is the point.
- UncleMeat 2y agoI don't think that C++'s rigorous adherence to backwards compatibility (include binary compatibility) is a bad choice. It has served the language well. It just has consequences.
- pjc50 2y ago> it just doesn't lie about the complexity of reality "Undefined behavior" is not reality; it's a strange shadow world where anything may happen. The compiler reserves the right to reject your reality and substitute its own - which it will not show you within the language, nor let you choose or hint, nor warn you. People like to use C and C++ as if they were a species of typesafe macro assembler that always produces predictable machine code, and that breaks down often enough that the world is full of systems-level CVEs.
- bluGill 2y agoPeople keep saying this, yet undefined behavior sanitizer proves in the real world it isn't an issue most of the time. Most real world security issues have nothing to do with code. Social engineering breaks more security than memory issues. We are also skewed by many of the fundamental programs are written in C and so there is a lot of value in finding holes.