5 ms·

[flagged]

mplanchard 1y ago
I suspect an article like this says more about the author than the language. Note I’m not being critical of the author here. I think it’s lovely to turn your passion into trying to help others learn.
LAC-Tech 1y ago
I have taken the time to learn rust and you're absolutely right. It's a very complex, design-by-committee language. It has brilliant tooling, and is still much less complex than it's design-by-committee competitor C++, but it will never be easy to learn.
- worik 1y ago
  There is a trade off. Rust gave us fast, and safe. It did not give us "easy to learn". I think it is a very good example of why "design by committee" is good. The "Rust Committee" has done a fantastic job Thank you They say a camel is a horse designed by a committee (https://en.wiktionary.org/wiki/a_camel_is_a_horse_designed_by_a_committee https://en.wiktionary.org/wiki/a_camel_is_a_horse_designed_b...) Yes: * Goes twice as far as a horse * On half the food and a quarter the water of a horse * Carries twice as much as a horse Yes, I like design by committee. I have been on some very good, and some very bad committees, but there is nothing like the power of a good committee Thank you Rust!
  - LAC-Tech 1y ago
    It's just a programming language, not a religion.
    - psychoslave 1y ago
      Well, it does look like there is a will to mimic religious social structure in the community, be it as a satiric form of it. I mean, I guess they purposefully named their pancakes cargo, as in "cargo cult", didn't they? Rustacean, rustomicon, and the other few words I saw leak out of the community all seem to go in the same spirit. I'm almost surprised they didn't went with more fancy terms for these core concepts of ownership and borrowing. Perl was also full of religious stuff like blessing your object, though Larry was actually more in the "true devot" side of the line.
      - conorjh 1y ago
        the dogmatic culture would probably be my first suggestion. i always ask why are there any CVEs for rust if its "memory-safe" but never get an answer suprisingly
        psychoslave 1y ago
        CVE is not only for memory leak though, while eliminating (or even drastically reducing) such a class of issue is a fair point to advertise, it should not be confused as a magic safety facility that makes go away any security concern.
        steveklabnik 1y ago
        > i always ask why are there any CVEs for rust if its "memory-safe" but never get an answer suprisingly The answer is straightforward: bugs exist. Even in formally proven software, mistakes can be made. Nothing is perfect. Additionally, memory safety is a property that when people talk about it, they mean by default. All languages contain some amount of non-proven unsafe code in their implementation, or via features like FFI. Issues can arise when these two worlds interact. Yet, real-world usage shows that these cases are quite few compared to languages without these defaults. The exceptions are also a source of the CVEs you’re talking about.
- rat87 1y ago
  its not design by committee its design by Pull request It doesn't have a central https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life like python used to so people suggest and implement features as a group, with code counting for a lot (although theoretical issues with safety/design also matter) as opposed to companies arguing for their pet features endlessly without much difference. Look at how long it takes C++ to get any new features.
  - rafram 1y ago
    > Look at how long it takes C++ to get any new features. I’m not sure “it doesn’t have enough features” has ever been anyone’s complaint about C++.
    - rat87 1y ago
      There are definitely some c++ features that some people have been clamoring for for over a decade Pattern matching for one(although to be fair that's been in rust from the start)
- yodsanklai 1y ago
  > It's a very complex I find it relatively simple. Much simpler than C++ (obviously). For someone who can write C++ and has some experience wth OCaml/Haskell/F#, it's not a hard language.
  - namuol 1y ago
    Sure, C++ has a more complex spec, nobody can argue against that. Complex is the wrong word. Baffling is a better word. Or counterintuitive, or cumbersome. If “easy enough for someone with experience in C++, OCaml, Haskell, and F#” were the same thing as “not hard” then I don’t think this debate would come up so frequently.
    - estebank 1y ago
      What you call "baffling", I call "different". Being different doesn't mean it's "complex" or even "hard" (in isolation), but it can be baffling, in the same way that driving on the other side of the road for the first time can feel baffling (but doesn't mean it's "wrong").
    - yodsanklai 1y ago
      Of course, this is very subjective. For someone who only knows python or javascript at a superficial level, Rust may seem out of reach. But if you're ok with the most common programming paradigms, I don't find Rust baffling. I mean, you can't expect to learn a new language in a few days, it'll always take a bit of work. My feeling is that people complaining of the language being hard aren't putting the effort. My experience is that Rust is a relatively small language which doesn't introduce a lot of new concepts. The syntax is quite intuitive, and the compiler super helpful. The borrower checker was the only new thing for me. I'm not an expert at all, but my experience is that after spending 2 weeks full-time reading books and experimenting, I was able to work professionally with the language without feeling too much friction. On the other hand, after spending much more time on C++, I don't feel really comfortable with the language.
      - icedchai 1y ago
rvz 1y ago
Maybe Rust is so complex, it is even more complex for an LLM to generate correct code (one-shot) without hallucinating non-existent functions. Would rather have that than all the issues that JavaScript or any other weakly typed and dynamically typed language.
- namuol 1y ago
  There _are_ more than two programming languages, though. I feel like most of the debates about Rust devolve into the same false choice between safety and ease. Before Rust I was hearing the same argument from Haskell or Scala developers trying to justify their language of choice. I know Rust is here to stay, but I think it’s mostly because it has a viable ecosystem and quality developer tools. Its popularity is _in spite of_ many of its language features that trade that extra 1% of safety for 90% extra learning curve.
  - NitpickLawyer 1y ago
    > features that trade that extra 1% of safety for 90% extra learning curve. I remember both MS and goog having talks about real-world safety issues in the range of 50% of cases were caused by things that safe rust doesn't allow (use after free, dangling pointers, double free, etc). The fact that even goog uses it, while also developing go (another great language with great practical applications) is telling imo.
remram 1y ago
I don't know how to read your comment other than "nothing hard is worth doing". Some things have benefits and drawbacks, is the existence of drawbacks always a non-starter for you? I'm trying to phrase this as delicately as I can but I am really puzzled. If someone wrote an article about how playing the harp is difficult, just stick with it... would you also say that playing the harp is a terrible hobby?
- etbebl 1y ago
  Maybe people need persuading to learn Rust not just because they think it's hard, but also because they think it's bad? Not everything hard is worth doing. Difficulty is just one of the factors to consider. I started to learn Rust, but I was put off by the heavy restrictions the language imposes and the attitude that this is the only safe way. There's a lack of acknowledgement, at least in beginner materials, that by choosing to write safe Rust you're sacrificing many perfectly good patterns that the compiler can't understand in exchange for safety. Eventually I decided to stop because I didn't like that tradeoff (and I didn't need it for my job or anything)
  - whyever 1y ago
    > by choosing to write safe Rust you're sacrificing many perfectly good patterns that the compiler can't understand in exchange for safety Historically, programmers drastically overestimate their ability to write perfectly safe code, so it's an enormous benefit if the compiler is able to understand whether it's actually safe.
    - Ragnarork 1y ago
      The first part of your statement feels true, although that's... unverified and lacks actual backing up. The second part of your statement is very debatable based on what safe means in this case, and whether it's an enormous benefit for a given situation. There's plenty of stories [0][1] about Rust getting in the way and being very innappropriate for certain tasks and goals, and those "enormous benefits" can become "enormous roadblocks" in different perspectives and use cases. In my personal and very subjective opinion I think Rust can be very good when applied to security applications, realtime with critical safety requirements (in some embedded scenarios for example), that sort of stuff. I think it really gets in the way too much in other scenarios with demanding rules and pattern that prevent from experimenting easily and exploring solutions quickly. [0]https://barretts.club/posts/rust-for-the-engine/ https://barretts.club/posts/rust-for-the-engine/ [1]https://loglog.games/blog/leaving-rust-gamedev/ https://loglog.games/blog/leaving-rust-gamedev/
cheikhcheikh 1y ago
> maybe that's a language design smell why
zaptheimpaler 1y ago
Learning any programming language at all feels 10x as hard to beginners, so you might as well say programming is not worth learning period in this case. Anything new has a learning curve to it.
devjab 1y ago
I think you can have a lot of debate on the design decisions on Rust, but I don't think the need for these articles tell you a lot about the language itself. I'd argue that Python needs articles like this more so than Rust does, but for entirely different reasons. In two decades of more and more programmers who aren't coming from an engineering background, I've yet to see anyone who used a Python generator or slots. Data Classes are less rare, but mainly in the form of pydantics "version". Which doesn't exactly matter for a lot of Python code... This is a world where 4chan can serve 4 million concurrent users an apache server running a 10k line PHP file neither of which have been updated since 2015... so you can be fine doing inefficient and entirely in-memory Python code 95% (or more) of the time. That doesn't mean you should though. Imagine how much energy is being wasted globally on bad Python code... The difference is of course that anyone can write it, and not everyone can write Rust. I'm not personally a big fan of Rust, I'd chose Zig any day of the week... but then I'd also choose C over C++, and I frankly do when I optimise Python code that falls in those last 5%. From that perspective... of someone who really has to understand how Python works under the hood and when to do what, I'd argue that Rust is a much easier langauge to learn with a lot less "design smell". I suppose Python isn't the greatest example as even those of us who love it know that it's a horrible language. But I think it has quite clearly become the language of "everyone" and even more so in the age of LLM. Since our AI friends will not write optimised Python unless you specifically tell them to use things like generators and where to use them, and since you (not you personally) won't because you've never heard about a generator before, then our AI overlords won't actually help.
bsder 1y ago
> If a language needs an article like this, absolutely begging people to bite the bullet to learn it, maybe that's a language design smell. The problem with articles like this is that they don't really get to the heart of the problem: There are programs that Rust will simply not let you write. Rust has good reasons for this. However, this is fundamentally different from practically every programming language that people have likely used before where you can write the most egregious glop and get it to compile and sometimes even kinda-sorta run. You, as a programmer, have to make peace with not being able to write certain types of programs, or Rust is not your huckleberry.
- swiftcoder 1y ago
  > There are programs that Rust will simply not let you write. Can you specify a few of these programs? I can see where Rust might not allow you to write something the way you want to, but I fail to see how a program would not be expressible in rust...
  - steveklabnik 1y ago
    They mean in Safe Rust. Unsafe is included in Rust for this reason.
    - swiftcoder 1y ago
      Is safe rust not Turing complete? I can see the argument that a purist "safe rust only" program might be slow, but it still will be expressible
      - steveklabnik 1y ago
        Turning completeness doesn’t take efficiency into account, nor the reality of things like “call into the operating system so that you can display output” that are necessary when building real systems.
        1y ago
melodyogonna 1y ago
Rust design decisions are pretty hard to understand sometimes, Mojo is another language with a borrow-checker but it is not nearly as hard to learn as Rust due to making a few decisions. First is value semantics, in Rust people are told to always clone when learning, why isn't this semantics built into the language? It is what you have in most static languages - C, C++, Go, etc. This is the mental model many people come to Rust with. Secondary, Mojo's lifetime does not tell the compiler when a value is safe to use but when it is safe to delete, in this way the lifetime is not scope based, references will extend the lifetime of the value they reference, but values will be destroyed immediately after their last use. In Mojo you'll never see "value does not live long enough". Just these two design decisions defines away so many ergonomic issues.
- tcfhgj 1y ago
  > people are told to always clone when learning, why isn't this semantics built into the language? Because cloning as opposed to copying is expensive and it generates a new instance of a type. In C, you don't clone, you simply copy the struct or pointer, which will lead to a pointer to the same memory or a struct with members pointing to the same memory. C++ on the other hand has a copy constructor, and you have to move explicitly, often generating unnecessary copies (in the sense of clone) > Mojo's lifetime does not tell the compiler when a value is safe to use but when it is safe to delete, What happens if you pass the variable mutably to a function?
  - melodyogonna 1y ago
    > What happens if you pass the variable mutably to a function? What happens in what manner? Mojo uses ASAP memory model, values will always be destroyed at the point of its last use. Mojo dataflow analysis will track this. In terms of safety, Mojo will enforce `alias xor mutability` - like in Rust. > C++ on the other hand has a copy constructor, and you have to move explicitly, often generating unnecessary copies (in the sense of clone) Mojo also has copy and move constructors, but unlike in C++ these are not synthesised by default; the type creator has to either explicitly define the constructors or add a synthesiser. In Mojo, you can have types that are not copyable and not movable, these types can only be passed by reference. You can also have types that are copyable but not movable, or movable but not copyable.
jbs789 1y ago
The article focuses on the learning curve rather than the problem Rust is solving, as an observation. Think you need both of those to draw a conclusion as to whether it’s worth doing.
BlackFly 1y ago
The truth is that by the time you are a senior developer, you will have encountered the lessons that make rust worth learning but may not have truly understood all the implications. Many people will think, I have a garbage collected language, rust has nothing to teach me. Even in garbage collected languages, people create immutable types because the possibility of shared references with mutability makes things incredibly chaotic that they look for immutability as a sort panacea. However, once you have immutable types you quickly realize that you also need ergonomic ways of modifying those objects, the methods you create to do so are often more cumbersome than what would be permitted for a mutable object. You wish there was some way to express, "There is a time where this object is mutable and then it becomes immutable." Enter the borrow checker. Once you are borrow checking... why are you garbage collecting? Well, expressing those timelines of mutability and existence is a cost because you need to understand the timeline and most people would rather not spend that energy--maybe mutability or the poor ergonomics of immutable objects wasn't so bad. So, I garbage collect because I do not want to understand the lifetimes of my objects. Not understanding the lifetimes of objects is what makes shared mutability hard. Immutability eliminates that problem without requiring me to understand. Rust can teach this lesson to you so that you make an informed choice. Of course, you can also just listen to me and learn the same lesson but there is value for many people to experience it.
- zahlman 1y ago
  > Not understanding the lifetimes of objects is what makes shared mutability hard. Well, no; in my experience the difficulty overwhelmingly comes from thinking about the semantics. I.e.: these two clients currently share a mutable object; should they observe each others' mutations? Or: if I clone this object, will I regret not propagating the change to other clients?
  - BlackFly 1y ago
    If you understand how it will work then that is just a decision to be made and a decision (although design is not necessarily easy) isn't what I would call hard: it is the ordinary work. By difficulty I mean bugs and bugginess, and bugs happen in this area because there are unintentional race conditions on the mutability. Total immutability is merely one way to force yourself to understand it, if those two clients need to observe the modifications then you have to propagate the changes manually instead of relying on shared memory semantics. But worse than that, even if you decide that they should observe the changes, then you can often end up with tearing if you are changing multiple properties non-atomically. That is a lifetime issue: the mutable reference is allowed to coexist at the same time as an immutable reference. In rust you cannot share an ordinary reference to have runtime observability like that, once shared the object becomes immutable. This forces you to use internal mutability via a RefCell and the exclusive/shared reference is enforced at runtime to eliminate tearing. Lifetimes of these borrows matter and how they matter depends on the choice of semantics, but I wouldn't call the choice the hard part.
atoav 1y ago
As someone who learned Rust, bur mostly uses Python in the day to day, I don't think Rust has a language design smell. It is just a very strict language with some of the strictness out there to ruin your day if you try to program Rust like it isn't Rust. What that means is for example, if you have high aesthetical ideals and try to write object oriented code you will hit a brick wall eventually. Why? Notnbecause Ruwt is a bad language, but because you try to write Rust like it is Java or something. Rust is a very nice language if you respect that there are Rust-ways of doing things that and that these ways are more data oriented than you might be used to. The strictness can be daunting for beginners, but with increasing complexity it becones an absolute godsend. Where in other languages I find errors only when they happen, most Rust code just works (provided you write it in a Rust way), because the errors will caught during compilation. That doesn't prevent logic errors, but these can be addressed with the absolute stellar test integrations. Now Rust is not all roses, but it is certainly a language worth learning even if you never use it. The ways it mitigates certain classes of errors can be turned into good coding practises for other languages as well.
tomhow 1y ago
This comment set off a generic programming language debate, which is the just the kind of geek message board cliché we're hoping to avoid on HN! Eschew flamebait. Avoid generic tangents. Omit internet tropes. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

[flagged]

I suspect an article like this says more about the author than the language. Note I’m not being critical of the author here. I think it’s lovely to turn your passion into trying to help others learn.

LAC-Tech 1y ago

I have taken the time to learn rust and you're absolutely right. It's a very complex, design-by-committee language. It has brilliant tooling, and is still much less complex than it's design-by-committee competitor C++, but it will never be easy to learn.

worik 1y ago
There is a trade off. Rust gave us fast, and safe. It did not give us "easy to learn". I think it is a very good example of why "design by committee" is good. The "Rust Committee" has done a fantastic job Thank you They say a camel is a horse designed by a committee (https://en.wiktionary.org/wiki/a_camel_is_a_horse_designed_by_a_committee https://en.wiktionary.org/wiki/a_camel_is_a_horse_designed_b...) Yes: * Goes twice as far as a horse * On half the food and a quarter the water of a horse * Carries twice as much as a horse Yes, I like design by committee. I have been on some very good, and some very bad committees, but there is nothing like the power of a good committee Thank you Rust!
- LAC-Tech 1y ago
  It's just a programming language, not a religion.
  - psychoslave 1y ago
    Well, it does look like there is a will to mimic religious social structure in the community, be it as a satiric form of it. I mean, I guess they purposefully named their pancakes cargo, as in "cargo cult", didn't they? Rustacean, rustomicon, and the other few words I saw leak out of the community all seem to go in the same spirit. I'm almost surprised they didn't went with more fancy terms for these core concepts of ownership and borrowing. Perl was also full of religious stuff like blessing your object, though Larry was actually more in the "true devot" side of the line.
    - conorjh 1y ago
      the dogmatic culture would probably be my first suggestion. i always ask why are there any CVEs for rust if its "memory-safe" but never get an answer suprisingly
      - psychoslave 1y ago
        CVE is not only for memory leak though, while eliminating (or even drastically reducing) such a class of issue is a fair point to advertise, it should not be confused as a magic safety facility that makes go away any security concern.
      - steveklabnik 1y ago
        > i always ask why are there any CVEs for rust if its "memory-safe" but never get an answer suprisingly The answer is straightforward: bugs exist. Even in formally proven software, mistakes can be made. Nothing is perfect. Additionally, memory safety is a property that when people talk about it, they mean by default. All languages contain some amount of non-proven unsafe code in their implementation, or via features like FFI. Issues can arise when these two worlds interact. Yet, real-world usage shows that these cases are quite few compared to languages without these defaults. The exceptions are also a source of the CVEs you’re talking about.
rat87 1y ago
its not design by committee its design by Pull request It doesn't have a central https://en.wikipedia.org/wiki/Benevolent_dictator_for_life https://en.wikipedia.org/wiki/Benevolent_dictator_for_life like python used to so people suggest and implement features as a group, with code counting for a lot (although theoretical issues with safety/design also matter) as opposed to companies arguing for their pet features endlessly without much difference. Look at how long it takes C++ to get any new features.
- rafram 1y ago
  > Look at how long it takes C++ to get any new features. I’m not sure “it doesn’t have enough features” has ever been anyone’s complaint about C++.
  - rat87 1y ago
    There are definitely some c++ features that some people have been clamoring for for over a decade Pattern matching for one(although to be fair that's been in rust from the start)
yodsanklai 1y ago
> It's a very complex I find it relatively simple. Much simpler than C++ (obviously). For someone who can write C++ and has some experience wth OCaml/Haskell/F#, it's not a hard language.
- namuol 1y ago
  Sure, C++ has a more complex spec, nobody can argue against that. Complex is the wrong word. Baffling is a better word. Or counterintuitive, or cumbersome. If “easy enough for someone with experience in C++, OCaml, Haskell, and F#” were the same thing as “not hard” then I don’t think this debate would come up so frequently.
  - estebank 1y ago
    What you call "baffling", I call "different". Being different doesn't mean it's "complex" or even "hard" (in isolation), but it can be baffling, in the same way that driving on the other side of the road for the first time can feel baffling (but doesn't mean it's "wrong").
  - yodsanklai 1y ago
    Of course, this is very subjective. For someone who only knows python or javascript at a superficial level, Rust may seem out of reach. But if you're ok with the most common programming paradigms, I don't find Rust baffling. I mean, you can't expect to learn a new language in a few days, it'll always take a bit of work. My feeling is that people complaining of the language being hard aren't putting the effort. My experience is that Rust is a relatively small language which doesn't introduce a lot of new concepts. The syntax is quite intuitive, and the compiler super helpful. The borrower checker was the only new thing for me. I'm not an expert at all, but my experience is that after spending 2 weeks full-time reading books and experimenting, I was able to work professionally with the language without feeling too much friction. On the other hand, after spending much more time on C++, I don't feel really comfortable with the language.
    - icedchai 1y ago

rvz 1y ago

Maybe Rust is so complex, it is even more complex for an LLM to generate correct code (one-shot) without hallucinating non-existent functions. Would rather have that than all the issues that JavaScript or any other weakly typed and dynamically typed language.

namuol 1y ago
There _are_ more than two programming languages, though. I feel like most of the debates about Rust devolve into the same false choice between safety and ease. Before Rust I was hearing the same argument from Haskell or Scala developers trying to justify their language of choice. I know Rust is here to stay, but I think it’s mostly because it has a viable ecosystem and quality developer tools. Its popularity is _in spite of_ many of its language features that trade that extra 1% of safety for 90% extra learning curve.
- NitpickLawyer 1y ago
  > features that trade that extra 1% of safety for 90% extra learning curve. I remember both MS and goog having talks about real-world safety issues in the range of 50% of cases were caused by things that safe rust doesn't allow (use after free, dangling pointers, double free, etc). The fact that even goog uses it, while also developing go (another great language with great practical applications) is telling imo.

remram 1y ago

I don't know how to read your comment other than "nothing hard is worth doing". Some things have benefits and drawbacks, is the existence of drawbacks always a non-starter for you? I'm trying to phrase this as delicately as I can but I am really puzzled. If someone wrote an article about how playing the harp is difficult, just stick with it... would you also say that playing the harp is a terrible hobby?

etbebl 1y ago
Maybe people need persuading to learn Rust not just because they think it's hard, but also because they think it's bad? Not everything hard is worth doing. Difficulty is just one of the factors to consider. I started to learn Rust, but I was put off by the heavy restrictions the language imposes and the attitude that this is the only safe way. There's a lack of acknowledgement, at least in beginner materials, that by choosing to write safe Rust you're sacrificing many perfectly good patterns that the compiler can't understand in exchange for safety. Eventually I decided to stop because I didn't like that tradeoff (and I didn't need it for my job or anything)
- whyever 1y ago
  > by choosing to write safe Rust you're sacrificing many perfectly good patterns that the compiler can't understand in exchange for safety Historically, programmers drastically overestimate their ability to write perfectly safe code, so it's an enormous benefit if the compiler is able to understand whether it's actually safe.
  - Ragnarork 1y ago
    The first part of your statement feels true, although that's... unverified and lacks actual backing up. The second part of your statement is very debatable based on what safe means in this case, and whether it's an enormous benefit for a given situation. There's plenty of stories [0][1] about Rust getting in the way and being very innappropriate for certain tasks and goals, and those "enormous benefits" can become "enormous roadblocks" in different perspectives and use cases. In my personal and very subjective opinion I think Rust can be very good when applied to security applications, realtime with critical safety requirements (in some embedded scenarios for example), that sort of stuff. I think it really gets in the way too much in other scenarios with demanding rules and pattern that prevent from experimenting easily and exploring solutions quickly. [0]https://barretts.club/posts/rust-for-the-engine/ https://barretts.club/posts/rust-for-the-engine/ [1]https://loglog.games/blog/leaving-rust-gamedev/ https://loglog.games/blog/leaving-rust-gamedev/

cheikhcheikh 1y ago

> maybe that's a language design smell why

zaptheimpaler 1y ago

Learning any programming language at all feels 10x as hard to beginners, so you might as well say programming is not worth learning period in this case. Anything new has a learning curve to it.

devjab 1y ago

I think you can have a lot of debate on the design decisions on Rust, but I don't think the need for these articles tell you a lot about the language itself. I'd argue that Python needs articles like this more so than Rust does, but for entirely different reasons. In two decades of more and more programmers who aren't coming from an engineering background, I've yet to see anyone who used a Python generator or slots. Data Classes are less rare, but mainly in the form of pydantics "version". Which doesn't exactly matter for a lot of Python code... This is a world where 4chan can serve 4 million concurrent users an apache server running a 10k line PHP file neither of which have been updated since 2015... so you can be fine doing inefficient and entirely in-memory Python code 95% (or more) of the time. That doesn't mean you should though. Imagine how much energy is being wasted globally on bad Python code... The difference is of course that anyone can write it, and not everyone can write Rust. I'm not personally a big fan of Rust, I'd chose Zig any day of the week... but then I'd also choose C over C++, and I frankly do when I optimise Python code that falls in those last 5%. From that perspective... of someone who really has to understand how Python works under the hood and when to do what, I'd argue that Rust is a much easier langauge to learn with a lot less "design smell". I suppose Python isn't the greatest example as even those of us who love it know that it's a horrible language. But I think it has quite clearly become the language of "everyone" and even more so in the age of LLM. Since our AI friends will not write optimised Python unless you specifically tell them to use things like generators and where to use them, and since you (not you personally) won't because you've never heard about a generator before, then our AI overlords won't actually help.

bsder 1y ago

> If a language needs an article like this, absolutely begging people to bite the bullet to learn it, maybe that's a language design smell. The problem with articles like this is that they don't really get to the heart of the problem: There are programs that Rust will simply not let you write. Rust has good reasons for this. However, this is fundamentally different from practically every programming language that people have likely used before where you can write the most egregious glop and get it to compile and sometimes even kinda-sorta run. You, as a programmer, have to make peace with not being able to write certain types of programs, or Rust is not your huckleberry.

swiftcoder 1y ago
> There are programs that Rust will simply not let you write. Can you specify a few of these programs? I can see where Rust might not allow you to write something the way you want to, but I fail to see how a program would not be expressible in rust...
- steveklabnik 1y ago
  They mean in Safe Rust. Unsafe is included in Rust for this reason.
  - swiftcoder 1y ago
    Is safe rust not Turing complete? I can see the argument that a purist "safe rust only" program might be slow, but it still will be expressible
    - steveklabnik 1y ago
      Turning completeness doesn’t take efficiency into account, nor the reality of things like “call into the operating system so that you can display output” that are necessary when building real systems.
      - 1y ago

melodyogonna 1y ago

Rust design decisions are pretty hard to understand sometimes, Mojo is another language with a borrow-checker but it is not nearly as hard to learn as Rust due to making a few decisions. First is value semantics, in Rust people are told to always clone when learning, why isn't this semantics built into the language? It is what you have in most static languages - C, C++, Go, etc. This is the mental model many people come to Rust with. Secondary, Mojo's lifetime does not tell the compiler when a value is safe to use but when it is safe to delete, in this way the lifetime is not scope based, references will extend the lifetime of the value they reference, but values will be destroyed immediately after their last use. In Mojo you'll never see "value does not live long enough". Just these two design decisions defines away so many ergonomic issues.

tcfhgj 1y ago
> people are told to always clone when learning, why isn't this semantics built into the language? Because cloning as opposed to copying is expensive and it generates a new instance of a type. In C, you don't clone, you simply copy the struct or pointer, which will lead to a pointer to the same memory or a struct with members pointing to the same memory. C++ on the other hand has a copy constructor, and you have to move explicitly, often generating unnecessary copies (in the sense of clone) > Mojo's lifetime does not tell the compiler when a value is safe to use but when it is safe to delete, What happens if you pass the variable mutably to a function?
- melodyogonna 1y ago
  > What happens if you pass the variable mutably to a function? What happens in what manner? Mojo uses ASAP memory model, values will always be destroyed at the point of its last use. Mojo dataflow analysis will track this. In terms of safety, Mojo will enforce `alias xor mutability` - like in Rust. > C++ on the other hand has a copy constructor, and you have to move explicitly, often generating unnecessary copies (in the sense of clone) Mojo also has copy and move constructors, but unlike in C++ these are not synthesised by default; the type creator has to either explicitly define the constructors or add a synthesiser. In Mojo, you can have types that are not copyable and not movable, these types can only be passed by reference. You can also have types that are copyable but not movable, or movable but not copyable.

jbs789 1y ago

The article focuses on the learning curve rather than the problem Rust is solving, as an observation. Think you need both of those to draw a conclusion as to whether it’s worth doing.

BlackFly 1y ago

The truth is that by the time you are a senior developer, you will have encountered the lessons that make rust worth learning but may not have truly understood all the implications. Many people will think, I have a garbage collected language, rust has nothing to teach me. Even in garbage collected languages, people create immutable types because the possibility of shared references with mutability makes things incredibly chaotic that they look for immutability as a sort panacea. However, once you have immutable types you quickly realize that you also need ergonomic ways of modifying those objects, the methods you create to do so are often more cumbersome than what would be permitted for a mutable object. You wish there was some way to express, "There is a time where this object is mutable and then it becomes immutable." Enter the borrow checker. Once you are borrow checking... why are you garbage collecting? Well, expressing those timelines of mutability and existence is a cost because you need to understand the timeline and most people would rather not spend that energy--maybe mutability or the poor ergonomics of immutable objects wasn't so bad. So, I garbage collect because I do not want to understand the lifetimes of my objects. Not understanding the lifetimes of objects is what makes shared mutability hard. Immutability eliminates that problem without requiring me to understand. Rust can teach this lesson to you so that you make an informed choice. Of course, you can also just listen to me and learn the same lesson but there is value for many people to experience it.

zahlman 1y ago
> Not understanding the lifetimes of objects is what makes shared mutability hard. Well, no; in my experience the difficulty overwhelmingly comes from thinking about the semantics. I.e.: these two clients currently share a mutable object; should they observe each others' mutations? Or: if I clone this object, will I regret not propagating the change to other clients?
- BlackFly 1y ago
  If you understand how it will work then that is just a decision to be made and a decision (although design is not necessarily easy) isn't what I would call hard: it is the ordinary work. By difficulty I mean bugs and bugginess, and bugs happen in this area because there are unintentional race conditions on the mutability. Total immutability is merely one way to force yourself to understand it, if those two clients need to observe the modifications then you have to propagate the changes manually instead of relying on shared memory semantics. But worse than that, even if you decide that they should observe the changes, then you can often end up with tearing if you are changing multiple properties non-atomically. That is a lifetime issue: the mutable reference is allowed to coexist at the same time as an immutable reference. In rust you cannot share an ordinary reference to have runtime observability like that, once shared the object becomes immutable. This forces you to use internal mutability via a RefCell and the exclusive/shared reference is enforced at runtime to eliminate tearing. Lifetimes of these borrows matter and how they matter depends on the choice of semantics, but I wouldn't call the choice the hard part.

atoav 1y ago

As someone who learned Rust, bur mostly uses Python in the day to day, I don't think Rust has a language design smell. It is just a very strict language with some of the strictness out there to ruin your day if you try to program Rust like it isn't Rust. What that means is for example, if you have high aesthetical ideals and try to write object oriented code you will hit a brick wall eventually. Why? Notnbecause Ruwt is a bad language, but because you try to write Rust like it is Java or something. Rust is a very nice language if you respect that there are Rust-ways of doing things that and that these ways are more data oriented than you might be used to. The strictness can be daunting for beginners, but with increasing complexity it becones an absolute godsend. Where in other languages I find errors only when they happen, most Rust code just works (provided you write it in a Rust way), because the errors will caught during compilation. That doesn't prevent logic errors, but these can be addressed with the absolute stellar test integrations. Now Rust is not all roses, but it is certainly a language worth learning even if you never use it. The ways it mitigates certain classes of errors can be turned into good coding practises for other languages as well.

tomhow 1y ago

This comment set off a generic programming language debate, which is the just the kind of geek message board cliché we're hoping to avoid on HN! Eschew flamebait. Avoid generic tangents. Omit internet tropes. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html