7 ms·

I don't program in rust or ada, however it seems like such a comparison is missing important details. After all, if memory safety was all that mattered we'd all

• ajxs 2y ago
  I look at the problem the other way around: There are certain domains that significantly constrain the choice of programming language, for reasons like compatibility, or performance. If you're already limited to a small set of statically-compiled 'systems languages' like C, Ada, Rust, etc, then memory-safety is a secondary factor that will really influence your choice of which systems programming language you use.
• pjmlp 2y ago
  What got Rust adoption if anything was human factor, most folks adopting it never programmed in Ada, Object Pascal, Modula-2, Delphi,... They weren't even born when we were using them, or if they were their toys were actually toys not systems programming languages. Rust was their first encounter with systems programming, and Standard ML linage, after lots of Python, Ruby and JavaScript, and most likely never seen anything else other than C and C++. Most likely that also believe the fairy tale of C being the very first systems programming language.
  • dakom 2y ago
    I'd agree it's largely the human factor, but maybe from a different angle. Rust has got the "there's a crate for that" factor, like JavaScript, which helps onboard people who are afraid of getting stuck writing everything from scratch. For example, serde (and serde_json, toml, etc.) is a gamechanger, as is tracing, reqwest, and many others. So, maybe less about the language itself for many people, but more about the human factor of overcoming fear of being stuck on an island
  • IshKebab 2y ago
    I'm not sure what point you're trying to make. Do you think Object Pascal is as good as Rust?
    • pjmlp 2y ago
      Nope, but definitly better than C in regards to safety in systems programming.
      • bawolff 2y ago
        That's a pretty low bar. What would be less safe than c?
        • pjmlp 2y ago
          And yet here we stand, still not having it replaced at scale. To quote Hoare in 1980, "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." ===> I note with fear and horror that even in 1980 language designers and users have not learned this lesson. Referring naturally to C, by the way 1988 is the birth year of the Morris Worm, taking advantage of C's buffer management capabilities. Yes, a pretty low bar that 40 years after those events is still largely used across the industry. And the copy paste compatibility of Objective-C and C++ with C doesn't help, because even though those languages provide better capabilities and safer alternatives than writing raw C, there are always those folks that will write C style code no matter what.
          • pdimitar 2y ago
  • bawolff 2y ago
    The human factor doesn't just come out of nowhere.
    • pjmlp 2y ago
      Indeed, but it definitly matters, and it doesn't always pick the best technology.
  • Yoric 2y ago
    To complete what you write, the people in the room during the design of Rust were all very much aware of memory-safe languages. Rust was largely designed by putting C++ developers (who were tired of undefined behaviors) and ML developers (who were aware that ML was not great at system programming) in the same room and have them negotiate a language together, in the hope of producing something that would convince C++ developers to migrate to something less risky. I kinda vaguely remember Erlang being mentioned, but I don't recall Ada being discussed. To be fair, I didn't attend many of these conversations.
    • adrian_b 2y ago
      The Rust designers might have known that other memory-safe programming languages had existed, but certainly they were not familiar with them. Otherwise Rust would not have inherited a ton of obsolete and useless features of C. For example, when I have seen for the first time a "Hello, world" written in Rust, I have been appalled to see that in a language designed in the 3rd millennium one still has to specify whether function parameters are passed by value or by reference, which is the wrong thing to specify about function parameters, exactly like specifying in old C language whether a local variable was "register" or "auto" was the wrong thing to specify. (The right thing to specify about function parameters has been established in 1977, almost a half of century ago, by DoD "IRONMAN", which has been implemented only in a few languages, the most important being Ada. In my opinion, most difficulties and complexities of C++ have been generated by its failure to comply with "IRONMAN".) In my opinion, attempting to design a new programming language without first studying carefully the history of programming languages, in order to know well the many good and bad choices that have already been used in various programming languages and to understand which have been their advantages and disadvantages, is an amateurish approach that cannot result in real progress. Most recent programming languages have been built around some innovative great idea that makes that programming language better than the previous in some respect, e.g. Rust for compile-time checking of memory accesses, but because in the other areas of the language the best previous features have not been chosen, no language is uniformly better than older languages, all of them are better for something than older languages, but worse than older languages for other things, which makes the choice of a programming language very frustrating.
  • pdimitar 2y ago
    I clearly remember sighing deeply back in 2002 realizing I have to introduce yet another array type so my code could compile in Object Pascal. And this is just one example of many. Rust is objectively better than what I tried before, in several ways. From where I was standing several years ago, there was almost zero "human factor" in adopting Rust for many companies (and devs). People simply saw the better features, performance and security and got excited and wanted to work with that language. And then many mistook that for hype. Yourself included apparently? Sometimes things get popular just because they are good, you know. Not super often historically, mind you, but it does happen. IME Rust is one of these outliers.
    • pjmlp 2y ago
      Open arrays would have been the answer, which I imagine is the point being made.
      • pdimitar 2y ago
        Could be. Back then I didn't have any detailed docs on hand. It also wasn't the point. There was a number of completely unnecessary annoyances. Academics writing compilers actually seemed like a good idea to people back then. Still makes me smile thinking of it sometimes.
        • pjmlp 2y ago
          Most of mainstream compilers are the output of academics work.
          • pdimitar 2y ago
            Only if you trace the chain of work back to its source, as far as I'm aware -- could be wrong. A lot of modern compilers don't seem to be directly done by academics though. If you know of such modern examples I'd be happy to be proven wrong.
            • 2y ago
• cyberax 2y ago
  Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed. Ada does not offer anything similar. It's designed for programs that are mostly static. It also does not compose well, as you can't dynamically allocate without losing most of Ada touted advantages. To be fair, they recognized it. Their plan is to adopt a borrow-checker.
  • tubs 2y ago
    In rust dynamic allocations usually just end up with runtime asserts from your ref counting gc implementation though.
    • IshKebab 2y ago
      No they don't. Most programs are full of dynamic allocations (String, Vec, etc.) with only rare use of RefCell (I assume that's what you're talking about).
      • Galanwe 2y ago
        Most non trivial programs I've seen in Rust just end up with Arc<> and copies all over the place, because getting lifetimes right becomes borderline insanity.
        • IshKebab 2y ago
          It totally depends on the program. Sometimes you need to use Arc, sometimes you don't. Arc doesn't involve any runtime asserts though and it's not a crime to use it. For example I just ripgrep. Arc is used 29 times, compared to 185 uses of Vec.
  • palata 2y ago
    > Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed. Is that true, though? Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). Feels like mostly they compromise on memory, don't they? Rust seems to be a good replacement for those use-cases where C++ is needed. But given the popularity of Rust, it seems to me that many people use Rust where they don't actually need it. (Disclaimer: I do like Rust)
• zaphirplane 2y ago
  Surprising to hear this, life time and borrow checker have to be one of those in-spite of people still like rust
  • timeon 2y ago
    Maybe for those that have to use Rust. But borrow checker was sole reason why I wanted to learn Rust. And at that time (~2018) it was also reason why people were recommending it.
  • Thiez 2y ago
    And people like C in spite of the segfaults. It's the same disliked thing, Rust just moves it to compile time instead of production. Which many people prefer, since it avoids security issues, data loss, and mysterious crashes.
• lolinder 2y ago
  > if memory safety was all that mattered we'd all be using python. I've seen more segfaults in my Python code than I have in any other language ecosystem. Yes, that's in the C modules that Python libraries so often wrap, but the result is still that Python is far from the best choice for memory safety. JavaScript actually tends to be better at avoiding dropping into C unless absolutely necessary.
• zelphirkalt 2y ago
  Python does not offer the same guarantees for safety when it comes to concurrency. Afaik Rust makes data races impossible, by forcing you to make use of specific types, when you have a concurrent scenario, and since everything has to type check (in contrast to Python) before you can run it, that limits you in what you can do, making it safe.