6 ms·
> Rust's focus on embedded and system's development is a core strength. June, on the other hand, has a lean towards application development with a system's appr
by pron 2y ago
> Rust's focus on embedded and system's development is a core strength. June, on the other hand, has a lean towards application development with a system's approach. This lets both co-exist and offer safe systems programming to a larger audience.
I think this is a mistake, both on June's part and on Rust's. All low-level languages (by which I mean languages that offer control over all/most memory allocation) inherently suffer from low abstraction, i.e. there are fewer implementations of a particular interface or, conversely, more changes to the implementation require changes to the interface itself or to its client. This is why even though writing a program in many low-level languages can be not much more expensive than writing the program in a high-level language (one where memory management is entirely or largely automatic), costs accrue in maintenance.
This feature of low-level programming isn't inherently good or bad -- it just is, and it's a tradeoff that is implicitly taken when choosing such a language. It seems that both June and Rust try to hide it, each in their own way, Rust by adopting C++'s "zero-cost abstraction approach", which is low abstraction masquerading as high abstraction when it appears as code on the screen, and June by yielding some amount of control. But because the tradeoff of low-level programming is real and inescapable, ultimately (after some years of seeing the maintenance costs) users learn to pick the right tradeoff for their domain.
As such, languages should focus on domains that are most appropriate for the tradeoffs they force, while trying to aim for others usually backfires (as we've seen happen with C++). Given that ultimately virtually all users of a low level language will be those using it in a domain where the low-level tradeoff is appropriate -- i.e. programs in resource-constrained environments or programs requiring full and flexible control over every resource like OS kernels -- trying to hide the tradeoff in the (IMO) unattainable hope of growing the market beyond the appropriate domain, will result in disappointment due to a bad product-market fit.
Sure, it's possible that C++'s vision of broadening the scope of low-level programming was right and it's only the execution that was wrong, but I wouldn't bet on it on both theoretical (low abstraction and its impact on maintenance) and empirical (for decades, no low-level languages have shown signs of taking a significant market share from high-level languages in the applications space) grounds. Trying to erase tradeoffs that appear fundamental -- to have your cake and eat it -- has consistently proven elusive.
- gpderetta 2y agoC++ managed to get market share from C by being both as low level and higher level. It is true that it hasn't happened again since, as other higher level languages took market share from C++ for applications, but didn't replace it for lower level stuff. Still is conceivable that another language might do to C++ what it did to C.
- pron 2y agoI think that the way you use "high level" here is vague and so makes it hard to see what's going on. I define a high-level language as one that trades off control over memory resources in exchange for higher abstraction (by relying on automatic memory management, AKA garbage collection -- be it based on a refcounting or a tracing algorithm -- as the primary means of memory management), while a low-level language makes the opposite tradeoff. By this definition, C++ is just as low-level as C. We can argue over which C++ features made it more attractive than C in the low-level space, but it is clear that the overall market share of C + C++ has only declined over the past thirty years, and C++ has failed to make significant inroads in application programming over the long term (it had a short-lived rise followed by a drop). The question I focus on is whether a low-level language, by my definition, should have features specifically accommodating application programming. The obvious failure of low-level languages -- which include C++ according to my definition -- to take a significant market share of application programming leads me to answer that question in the negative. Various features accommodating low-level programming -- those that may have helped C++ take market share away from C but, crucially, have not helped it gain market share in application programming (over the long term) are, therefore, irrelevant to this core question. It's one thing to make a low-level language more attractive to low-level programming, and a whole other thing to make it more attractive to application programming. C++ has succeeded in the former but failed in the latter.
- gpderetta 2y ago[Note I used "higher" as opposed to "high"] I would say that an higher level language provides more abstractions than a lower level one. Memory and resource management is an aspect of it, but not a requirement (C is an higher level language than asm, yet it doesn't provide any memory management other than implicit stack allocation). In any case yes, the definition is nebulous. I would add that at the turn of the millennium C++ had a clear domination of the application space. edit: I don't claim any specific knowledge, but, more than GC, I would say the lack of built-in networking and enterprise[1] features to integrate with web application stacks prevented C++ from taking an hold in the early Internet era (outside of large tech companies). In the last decade or so, I think the main reason it is being displaced in the desktop space simply by virtue of not being JS. [1] I'm not using this disparagingly