6 ms·

On the plus side, String makes a really good example to explain ownership, moving, stack vs heap, etc. All of which you need at least a basic understanding of t

On the plus side, String makes a really good example to explain ownership, moving, stack vs heap, etc. All of which you need at least a basic understanding of to do anything non-trivial in Rust. I kind of feel like it goes without saying that Rust isn't ideal for beginners. For developers who already have a good knowledge of other languages I feel like learning about these things shouldn't be a problem, as becoming familiar with these concepts is one of the main benefits of learning Rust.

smaddox 4y ago
> I kind of feel like it goes without saying that Rust isn't ideal for beginners. I think that depends on, first, what the goal is, and second, what you're comparing to. It think Rust is easier on beginners, in many ways, than C. And C is easier on beginners, in many ways, than assembly or machine code. But if you want to really understand computer programming, starting at machine code or at least assembly isn't a crazy way to start.
- tialaramex 4y ago
  Beginning with machine code for some simple architecture (maybe RISC-V these days?) might be one good route in. I can also see (having experienced it myself, albeit I already knew C etc. these were not requirements and many of my classmates did not) beginning with a pure functional language where all the practicalities are abstracted entirely. Today the University where I learned this begins with Java, which I am confident is the wrong choice, but the person who part-designed their curriculum, and is a friend, disagrees with me and he's the one getting paid to teach them.
- nicoburns 4y ago
  > It think Rust is easier on beginners, in many ways, than C. And C is easier on beginners, in many ways, than assembly or machine code. But if you want to really understand computer programming, starting at machine code or at least assembly isn't a crazy way to start. I mean sure. But equally, starting with Python isn't a crazy way to start. And Python is much easier language to learn than any of those (esp. if you want to actually create something practical with it).
  - hgomersall 4y ago
    Sure, but if your objective is systems programming, you'll probably quickly get to the point of realising python is not the right choice.
    - pjmlp 4y ago
      Depends, if writing a compiler is still considered systems programming in modern times. https://www.amazon.com/Writing-Interpreters-Compilers-Raspberry-Python/dp/1977509207 https://www.amazon.com/Writing-Interpreters-Compilers-Raspbe...
      - less_less 4y ago
        Compilers are their own beast — I wouldn't put them with systems code. They're pretty different from an OS, BLAS, machine learning kernel, game engine, network stack, database or what have you. There's not as much buffer management, speed and memory aren't usually as critical, you don't make direct syscalls, many structures are graphs rather than arrays, etc. They often aren't even multithreaded. It's also popular to write compilers in distinctly non-"systems-y" languages, most notably Standard ML but also eg Haskell, and lots of languages are self-hosted.
        travisgriggs 4y ago
        I think compilers are a strong sub field of meta programming. I see meta programming as anything that deals directly or indirectly with ASTs. Compilers (er parsers and linkers) make ASTs and transform them. Refactoring engines (should) work with them. Sadly, I’m not sure what language I’d recommend as ideal for this (meta programming) now days. I think it’s zen cool when a language like Lisp or Zig or Elixir slides sideways in and out of meta programming, but that doesn’t mean they have good ASTs to work with, or that they’re ideal as a pseudo language to manipulate them. It should be something that is both not too complex, but also not so zen abstract that you have to bootstrap meaningful things endlessly. I personally liked the Smalltalk AST. But I couldn’t speak to its pedagogical or industry value as a meta programming environment.
- msla 4y ago
  > But if you want to really understand computer programming, starting at machine code or at least assembly isn't a crazy way to start. I've long suspected that the CS field was founded on two approaches: The people who started from EE and worked their way up, and the people who started from Math and worked their way down. The former people think assembly is the "real" way to approach software, and probably view C++ as "very high-level", whereas the latter people think everyone should start with a course on the lambda calculus and type systems and gradually ease into Haskell, work down to Lisp, and then maybe deign to learn Python for *shudder* numerical work.
  - nicoburns 4y ago
    I'd argue there's also a 3rd foundation of CS: language. Programming languages really are languages in the general sense of the word, and their purpose is to allow humans to effectively communicate with machines. Focussing on optimising that communication is the 3rd approach.
    - eru 4y ago
      Oh, that's just a subtype of mathematician. Basically in computing, there's mathematicians who want to deal with languages and those who want to deal with numbers. Math itself is all about communication. Finding a new theorem is neat, but it's only proper math once you found a proof for it that you can communicate to other people.
  - kenward 4y ago
    Your comment reminded me of this article[1] that has probably been posted plenty of times on HN. You've described both the "hacker" and the "mathematician" tribes. [1] https://josephg.com/blog/3-tribes/ https://josephg.com/blog/3-tribes/
bsder 4y ago
> I kind of feel like it goes without saying that Rust isn't ideal for beginners. I agree if you mean: "Beginners should be using Python, Ruby, Java, etc." People who suggest that "Beginners should be using C." have blocked out from their memory the trauma that is "Segmentation Fault (core dumped)."
- dralley 4y ago
  Counterpoint: Beginners should use C just long enough to be traumatized by "Segmentation Fault (core dumped).", so that they can appreciate the affordances that higher level languages offer (but hopefully not long enough that they run away from the whole subject)
jollybean 4y ago
'Becoming familiar with Rust, is one of the main benefits of learning Rust' The problem is that we seem to believe there is something 'inherent' about the way Rust solves these problems, and that by doing so with Rust lifetimes, we solve some kind of inherent issue in software. This makes us believe that Rust = Value in some ways which I believe is wrong. Rust is only 'one way' - and it may be far more complicated than it needs to be and in many cases more complicated than it is worth. I feel that Rust may be an experiment, our 'first attempt' at advanced compile time safety, like it's a kind of C++ whereas the Java/C# of memory safety will happen once we've ingested all of these lessons. Funny I feel that with Rust 'There's a much smaller and clearer language struggling to come out' like what Stroustrup said about C++.
- hedora 4y ago
  Coming from a C++ background makes me think Rust is the smaller and clearer language that came out of C++. The only successful C++ code bases I've worked on were multithreaded, and most were also asynchronous. If you assume those design decisions are required, then you'll find that programmers have to reinvent the borrow checker in their head and manually apply it to code in whatever language they're using. That's incredibly boring and tedious, and people are demonstrably terrible at doing it. Rust automates away all that stuff. I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it.
  - eru 4y ago
    > I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it. Erlang's message passing style is interesting here. And so is eg Software Transaction Memory that you can try in Haskell. Have a look at deterministic parallelism, too.
    - jcelerier 4y ago
      > Erlang's message passing style is interesting here. it just hides who owns the message data object though, no ? The problem is still here. e.g. for instance I work on a C++ software where there is a lot of message passing across threads, but the OS thread on which "malloc" and "free" are called for the messages and any data they may contain really, really matters - some threads must never call "malloc" or "free" under any circumstance. Would I be able to manage this with Erlang, knowing that every thread should be able to send message to pretty much any other ? Also, looking at that code... https://www.erlang.org/blog/message-passing/ https://www.erlang.org/blog/message-passing/ I don't really see what this gains me over the trivial C++ solution: processing_thread.message_queue.send([=] (Context& ctx) { int x = ... some computation ... ctx.ui_thread.message_queue.send([x] { ... show some info ... }); }); which can become even simpler with coroutines in C++20 if one does not like callback style
thejosh 4y ago
Rust is a hard language to learn, but once I got over the initial hump of learning all the things that don't exist in higher languages/that I've forgotten about it's a great language. The best thing I did was start doing minor contributions to opensource Rust libraries, I did a small PR for arrow2 and polars which taught me a lot, and also the maintainers and contributors there are incredibly friendly and helpful.

smaddox 4y ago

> I kind of feel like it goes without saying that Rust isn't ideal for beginners. I think that depends on, first, what the goal is, and second, what you're comparing to. It think Rust is easier on beginners, in many ways, than C. And C is easier on beginners, in many ways, than assembly or machine code. But if you want to really understand computer programming, starting at machine code or at least assembly isn't a crazy way to start.

tialaramex 4y ago
Beginning with machine code for some simple architecture (maybe RISC-V these days?) might be one good route in. I can also see (having experienced it myself, albeit I already knew C etc. these were not requirements and many of my classmates did not) beginning with a pure functional language where all the practicalities are abstracted entirely. Today the University where I learned this begins with Java, which I am confident is the wrong choice, but the person who part-designed their curriculum, and is a friend, disagrees with me and he's the one getting paid to teach them.
nicoburns 4y ago
> It think Rust is easier on beginners, in many ways, than C. And C is easier on beginners, in many ways, than assembly or machine code. But if you want to really understand computer programming, starting at machine code or at least assembly isn't a crazy way to start. I mean sure. But equally, starting with Python isn't a crazy way to start. And Python is much easier language to learn than any of those (esp. if you want to actually create something practical with it).
- hgomersall 4y ago
  Sure, but if your objective is systems programming, you'll probably quickly get to the point of realising python is not the right choice.
  - pjmlp 4y ago
    Depends, if writing a compiler is still considered systems programming in modern times. https://www.amazon.com/Writing-Interpreters-Compilers-Raspberry-Python/dp/1977509207 https://www.amazon.com/Writing-Interpreters-Compilers-Raspbe...
    - less_less 4y ago
      Compilers are their own beast — I wouldn't put them with systems code. They're pretty different from an OS, BLAS, machine learning kernel, game engine, network stack, database or what have you. There's not as much buffer management, speed and memory aren't usually as critical, you don't make direct syscalls, many structures are graphs rather than arrays, etc. They often aren't even multithreaded. It's also popular to write compilers in distinctly non-"systems-y" languages, most notably Standard ML but also eg Haskell, and lots of languages are self-hosted.
      - travisgriggs 4y ago
        I think compilers are a strong sub field of meta programming. I see meta programming as anything that deals directly or indirectly with ASTs. Compilers (er parsers and linkers) make ASTs and transform them. Refactoring engines (should) work with them. Sadly, I’m not sure what language I’d recommend as ideal for this (meta programming) now days. I think it’s zen cool when a language like Lisp or Zig or Elixir slides sideways in and out of meta programming, but that doesn’t mean they have good ASTs to work with, or that they’re ideal as a pseudo language to manipulate them. It should be something that is both not too complex, but also not so zen abstract that you have to bootstrap meaningful things endlessly. I personally liked the Smalltalk AST. But I couldn’t speak to its pedagogical or industry value as a meta programming environment.
msla 4y ago
> But if you want to really understand computer programming, starting at machine code or at least assembly isn't a crazy way to start. I've long suspected that the CS field was founded on two approaches: The people who started from EE and worked their way up, and the people who started from Math and worked their way down. The former people think assembly is the "real" way to approach software, and probably view C++ as "very high-level", whereas the latter people think everyone should start with a course on the lambda calculus and type systems and gradually ease into Haskell, work down to Lisp, and then maybe deign to learn Python for *shudder* numerical work.
- nicoburns 4y ago
  I'd argue there's also a 3rd foundation of CS: language. Programming languages really are languages in the general sense of the word, and their purpose is to allow humans to effectively communicate with machines. Focussing on optimising that communication is the 3rd approach.
  - eru 4y ago
    Oh, that's just a subtype of mathematician. Basically in computing, there's mathematicians who want to deal with languages and those who want to deal with numbers. Math itself is all about communication. Finding a new theorem is neat, but it's only proper math once you found a proof for it that you can communicate to other people.
- kenward 4y ago
  Your comment reminded me of this article[1] that has probably been posted plenty of times on HN. You've described both the "hacker" and the "mathematician" tribes. [1] https://josephg.com/blog/3-tribes/ https://josephg.com/blog/3-tribes/

bsder 4y ago

> I kind of feel like it goes without saying that Rust isn't ideal for beginners. I agree if you mean: "Beginners should be using Python, Ruby, Java, etc." People who suggest that "Beginners should be using C." have blocked out from their memory the trauma that is "Segmentation Fault (core dumped)."

dralley 4y ago
Counterpoint: Beginners should use C just long enough to be traumatized by "Segmentation Fault (core dumped).", so that they can appreciate the affordances that higher level languages offer (but hopefully not long enough that they run away from the whole subject)

jollybean 4y ago

'Becoming familiar with Rust, is one of the main benefits of learning Rust' The problem is that we seem to believe there is something 'inherent' about the way Rust solves these problems, and that by doing so with Rust lifetimes, we solve some kind of inherent issue in software. This makes us believe that Rust = Value in some ways which I believe is wrong. Rust is only 'one way' - and it may be far more complicated than it needs to be and in many cases more complicated than it is worth. I feel that Rust may be an experiment, our 'first attempt' at advanced compile time safety, like it's a kind of C++ whereas the Java/C# of memory safety will happen once we've ingested all of these lessons. Funny I feel that with Rust 'There's a much smaller and clearer language struggling to come out' like what Stroustrup said about C++.

hedora 4y ago
Coming from a C++ background makes me think Rust is the smaller and clearer language that came out of C++. The only successful C++ code bases I've worked on were multithreaded, and most were also asynchronous. If you assume those design decisions are required, then you'll find that programmers have to reinvent the borrow checker in their head and manually apply it to code in whatever language they're using. That's incredibly boring and tedious, and people are demonstrably terrible at doing it. Rust automates away all that stuff. I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it.
- eru 4y ago
  > I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it. Erlang's message passing style is interesting here. And so is eg Software Transaction Memory that you can try in Haskell. Have a look at deterministic parallelism, too.
  - jcelerier 4y ago
    > Erlang's message passing style is interesting here. it just hides who owns the message data object though, no ? The problem is still here. e.g. for instance I work on a C++ software where there is a lot of message passing across threads, but the OS thread on which "malloc" and "free" are called for the messages and any data they may contain really, really matters - some threads must never call "malloc" or "free" under any circumstance. Would I be able to manage this with Erlang, knowing that every thread should be able to send message to pretty much any other ? Also, looking at that code... https://www.erlang.org/blog/message-passing/ https://www.erlang.org/blog/message-passing/ I don't really see what this gains me over the trivial C++ solution: processing_thread.message_queue.send([=] (Context& ctx) { int x = ... some computation ... ctx.ui_thread.message_queue.send([x] { ... show some info ... }); }); which can become even simpler with coroutines in C++20 if one does not like callback style

thejosh 4y ago

Rust is a hard language to learn, but once I got over the initial hump of learning all the things that don't exist in higher languages/that I've forgotten about it's a great language. The best thing I did was start doing minor contributions to opensource Rust libraries, I did a small PR for arrow2 and polars which taught me a lot, and also the maintainers and contributors there are incredibly friendly and helpful.