6 ms·

It's an actual selling point more than a "loved" situation. If I see something built for massive concurrency and I see Erlang or Elixir, I'm immediately much m

It's an actual selling point more than a "loved" situation. If I see something built for massive concurrency and I see Erlang or Elixir, I'm immediately much more confident in the tooling. If I see something written in Rust, I'm confident in it's memory safety at a minimum but it usually bodes well for quality code in general.

Thaxll 4y ago
> bodes well for quality code in general Built in Rust does not assess of good code quality at all, it just tells you that you will most likely not have a class of bugs or issues, but the code itself can be very ugly. As a matter of fact given that Rust is "young" most people don't have a lot of knowledge and will most likely copy paterns from other languages, especially when fighting with the borrow checker. Just open some random Rust code, open the lib.rs and see how things are organized in there, you will be very surprised.
- brightball 4y ago
  That's fair. Code quality may have been a stretch. I'm mostly basing that on what I've read about Rust both here and in various other communities about the guarantees provided by the compiler/runtime itself. I haven't even dabbled in it yet myself, but I plan to at some point.
- wyager 4y ago
  Language choice is absolutely a powerful indicator of expected code quality. I don't want to start a language flame war, but I have some heuristics around P(I am satisfied with software|software is written in language X) that are very predictive. Besides the first-order effects of choice of language on program behavior (e.g. presence of type errors, memory errors, etc.) it also has a second-order filtering effect on the type of people writing programs and their mindset. There are certain languages without a strong first-order effect that nonetheless have a very strong second-order effect.
  - cozzyd 4y ago
    It's a bit of a curse though, isn't it? If a language becomes popular enough rather than something used only by enthusiasts, then all sorts of crap will appear? Now there are other issues other than popularity (like you can expect anything written in JavaScript/Python/Java to have a higher probability of a bloated mess, not only because they're popular...).
  - nylonstrung 4y ago
    I think this especially true when someone is explicitly remaking something in Rust to make it more performant "X but in Rust" IME almost always implies something with at best feature parity, but also debloated code
- Hirrolot 4y ago
  Can agree. Rust-specific things (ownership, AsRef, Deref, all this stuff) drastically pollute the final code, to compare with GC languages.
  - Tozen 4y ago
    To push this argument further along, in numerous use cases the GC using languages have comparable memory safety and performance (thus equal mention by government agencies), but were easier to use or faster for production.
- davidkunz 4y ago
  It depends. - Rust is a complicated language, so novice developers probably use something else. - Its ownership/borrowing system makes sure that architecture is not an afterthought (unless you pollute your code with countless smart pointers). - You get memory safety in safe Rust code and don't need a garbage collector. - Non-optimal solutions usually are visible/more cumbersome to write. In the end it's up to the individual developer, but Rust really helps to produce high-quality code.
  - BiteCode_dev 4y ago
    And the community and philosophy/culture the languages come with seems to promote that as well.
  - moffkalast 4y ago
    > Non-optimal solutions usually are visible/more cumbersome to write How's that? The difference between a suboptimal and an optimal solution can be perfectly valid normal code for lots of procedures. It's not something that's knowable without semantic meaning of what the code's trying to do.
    - davidkunz 4y ago
      A few examples: - Rust forces you to deal with errors and "null" values (Option). If you just unwrap them, it's visible. - Rust requires systems with clear ownership. You can opt out with various smart pointers, it's visible. - Rust requires you to use Box for heap allocations, it's visible. Note: I'm not talking about optimal solutions in the sense of "best algorithm", more in the sense of "well thought out and without lazy shortcuts".
      - moffkalast 4y ago
        Yeah I think that's just called enforcing best practices, not optimal solutions.
        davidkunz 4y ago
deleted 4y ago
[deleted]
FieryTransition 4y ago
No language will save you from: - A lack of knowledge about the domain, this includes the technical framework in which your program exists, behaves and interacts - Code errors which result in valid code, but does the wrong thing, Rust isn't magic - Bad choice of datastructures and algorithms - Incomprihensible code documentation and bad development practices. While I get that languages can eliminate a type of problem, they don't eliminate badly written software. Most of the time, the software development process itself, is more important, if you really want to examine what it means to build secure/safe software. Having a team dedicated to developing software safely and using a language with stronger type safety guarantees vs. having a person just build something with the same language, does not magically imbue the end product with good qualities. Take your example, if you don't have a good foundation in distributed systems, and try to build a distributed system in Erlang, you will only get so far, before you hit your head against the wall so hard, you start studying distributed systems instead.
- ironmagma 4y ago
  This kind of thinking is strange. It's similar to saying no type of exercise can save you from death. While true, we are talking about probability bounds here, not certainties.
  - FieryTransition 4y ago
    I totally understand what you are saying, in terms of probabilities, but what I'm arguing against, is thinking that safety, robustness etc. for a program is just a given, just because you happen to use Rust or whatever else is claiming X feature. In it's essence, it's like saying something is made of military grade materials, but then the materials are used all wrong in the actual design or not of importance at all. The fact that someone used Rust, does not really tell me much, other than certain types of errors are eliminated, and that is assuming they used Rust correctly, for the type system to work properly. If you ask people explicitly about whether Rust just makes better products, they might say that they have doubts, or give a vague answer. But asking like this is just a leading question, and therefore the process itself of asking the question, will probably cast doubt over some automatic assumptions about what the type safetly of Rust really does for the end product. But the reality is, "Made with Rust" is starting to look like a certificate/claim of validity, and its definitely not, just like any other language isn't either.
enougrustspam 4y ago
It's one of dozens if not hundreds of memory-safe languages. The false marketing claim that Rust somehow invented it is absolutely infuriating.
- albrewer 4y ago
  For one reason or another, those other languages didn't take off and Rust did. Language adoption isn't just about technical merits (although those have to be there). The ecosystem, tooling, core team, learning resources, and overall community have to be there, too. To your point - if I want to get started in another language that is 1) statically compiled, 2) non-garbage collected, and 3) memory-safe by design, as far as I can tell my only other mainstream options are Swift / Objective-C, Ada / SPARK, and Nim. I don't see nearly as much activity in those language's open source ecosystems, and "basic" libraries might not even exist due to the small communities.
  - TheFlyingFish 4y ago
    Nim is garbage-collected, actually. It has an option to disable garbage-collection (though I thought there was talk of removing that at some point) but then it just leaks memory, it doesn't have a comprehensive system for GC-less memory management like Rust does.
    - Tozen 4y ago
      Nim is also not the only language with the combination of optional GC and memory management. Dlang and Vlang are two others, where the GC is optional and are compiled languages. Golang appears to be more seriously experimenting with various forms of manual memory management, so at some point, we might see it offer a choice of memory management options too. In fact, Dlang even has an experimental borrow checker. Care should be taken to not be in so much of a bubble, to not realize that other languages have viable solutions too or are developing alternatives to what's presently available. If our choice for one or the other, is more a matter of personal preference, it would arguably be better to acknowledge such.
    - 4y ago

Thaxll 4y ago

> bodes well for quality code in general Built in Rust does not assess of good code quality at all, it just tells you that you will most likely not have a class of bugs or issues, but the code itself can be very ugly. As a matter of fact given that Rust is "young" most people don't have a lot of knowledge and will most likely copy paterns from other languages, especially when fighting with the borrow checker. Just open some random Rust code, open the lib.rs and see how things are organized in there, you will be very surprised.

brightball 4y ago
That's fair. Code quality may have been a stretch. I'm mostly basing that on what I've read about Rust both here and in various other communities about the guarantees provided by the compiler/runtime itself. I haven't even dabbled in it yet myself, but I plan to at some point.
wyager 4y ago
Language choice is absolutely a powerful indicator of expected code quality. I don't want to start a language flame war, but I have some heuristics around P(I am satisfied with software|software is written in language X) that are very predictive. Besides the first-order effects of choice of language on program behavior (e.g. presence of type errors, memory errors, etc.) it also has a second-order filtering effect on the type of people writing programs and their mindset. There are certain languages without a strong first-order effect that nonetheless have a very strong second-order effect.
- cozzyd 4y ago
  It's a bit of a curse though, isn't it? If a language becomes popular enough rather than something used only by enthusiasts, then all sorts of crap will appear? Now there are other issues other than popularity (like you can expect anything written in JavaScript/Python/Java to have a higher probability of a bloated mess, not only because they're popular...).
- nylonstrung 4y ago
  I think this especially true when someone is explicitly remaking something in Rust to make it more performant "X but in Rust" IME almost always implies something with at best feature parity, but also debloated code
Hirrolot 4y ago
Can agree. Rust-specific things (ownership, AsRef, Deref, all this stuff) drastically pollute the final code, to compare with GC languages.
- Tozen 4y ago
  To push this argument further along, in numerous use cases the GC using languages have comparable memory safety and performance (thus equal mention by government agencies), but were easier to use or faster for production.
davidkunz 4y ago
It depends. - Rust is a complicated language, so novice developers probably use something else. - Its ownership/borrowing system makes sure that architecture is not an afterthought (unless you pollute your code with countless smart pointers). - You get memory safety in safe Rust code and don't need a garbage collector. - Non-optimal solutions usually are visible/more cumbersome to write. In the end it's up to the individual developer, but Rust really helps to produce high-quality code.
- BiteCode_dev 4y ago
  And the community and philosophy/culture the languages come with seems to promote that as well.
- moffkalast 4y ago
  > Non-optimal solutions usually are visible/more cumbersome to write How's that? The difference between a suboptimal and an optimal solution can be perfectly valid normal code for lots of procedures. It's not something that's knowable without semantic meaning of what the code's trying to do.
  - davidkunz 4y ago
    A few examples: - Rust forces you to deal with errors and "null" values (Option). If you just unwrap them, it's visible. - Rust requires systems with clear ownership. You can opt out with various smart pointers, it's visible. - Rust requires you to use Box for heap allocations, it's visible. Note: I'm not talking about optimal solutions in the sense of "best algorithm", more in the sense of "well thought out and without lazy shortcuts".
    - moffkalast 4y ago
      Yeah I think that's just called enforcing best practices, not optimal solutions.
      - davidkunz 4y ago

deleted 4y ago

[deleted]

FieryTransition 4y ago

No language will save you from: - A lack of knowledge about the domain, this includes the technical framework in which your program exists, behaves and interacts - Code errors which result in valid code, but does the wrong thing, Rust isn't magic - Bad choice of datastructures and algorithms - Incomprihensible code documentation and bad development practices. While I get that languages can eliminate a type of problem, they don't eliminate badly written software. Most of the time, the software development process itself, is more important, if you really want to examine what it means to build secure/safe software. Having a team dedicated to developing software safely and using a language with stronger type safety guarantees vs. having a person just build something with the same language, does not magically imbue the end product with good qualities. Take your example, if you don't have a good foundation in distributed systems, and try to build a distributed system in Erlang, you will only get so far, before you hit your head against the wall so hard, you start studying distributed systems instead.

ironmagma 4y ago
This kind of thinking is strange. It's similar to saying no type of exercise can save you from death. While true, we are talking about probability bounds here, not certainties.
- FieryTransition 4y ago
  I totally understand what you are saying, in terms of probabilities, but what I'm arguing against, is thinking that safety, robustness etc. for a program is just a given, just because you happen to use Rust or whatever else is claiming X feature. In it's essence, it's like saying something is made of military grade materials, but then the materials are used all wrong in the actual design or not of importance at all. The fact that someone used Rust, does not really tell me much, other than certain types of errors are eliminated, and that is assuming they used Rust correctly, for the type system to work properly. If you ask people explicitly about whether Rust just makes better products, they might say that they have doubts, or give a vague answer. But asking like this is just a leading question, and therefore the process itself of asking the question, will probably cast doubt over some automatic assumptions about what the type safetly of Rust really does for the end product. But the reality is, "Made with Rust" is starting to look like a certificate/claim of validity, and its definitely not, just like any other language isn't either.

enougrustspam 4y ago

It's one of dozens if not hundreds of memory-safe languages. The false marketing claim that Rust somehow invented it is absolutely infuriating.

albrewer 4y ago
For one reason or another, those other languages didn't take off and Rust did. Language adoption isn't just about technical merits (although those have to be there). The ecosystem, tooling, core team, learning resources, and overall community have to be there, too. To your point - if I want to get started in another language that is 1) statically compiled, 2) non-garbage collected, and 3) memory-safe by design, as far as I can tell my only other mainstream options are Swift / Objective-C, Ada / SPARK, and Nim. I don't see nearly as much activity in those language's open source ecosystems, and "basic" libraries might not even exist due to the small communities.
- TheFlyingFish 4y ago
  Nim is garbage-collected, actually. It has an option to disable garbage-collection (though I thought there was talk of removing that at some point) but then it just leaks memory, it doesn't have a comprehensive system for GC-less memory management like Rust does.
  - Tozen 4y ago
    Nim is also not the only language with the combination of optional GC and memory management. Dlang and Vlang are two others, where the GC is optional and are compiled languages. Golang appears to be more seriously experimenting with various forms of manual memory management, so at some point, we might see it offer a choice of memory management options too. In fact, Dlang even has an experimental borrow checker. Care should be taken to not be in so much of a bubble, to not realize that other languages have viable solutions too or are developing alternatives to what's presently available. If our choice for one or the other, is more a matter of personal preference, it would arguably be better to acknowledge such.
  - 4y ago