5 ms·

I think a lot of us with experience in "system languages" would acknowledge where Rust fits in. But there are a lot of people in IT with experience in other fi

I think a lot of us with experience in "system languages" would acknowledge where Rust fits in. But there are a lot of people in IT with experience in other fields that gets on into the marketing sales pitch that is trendy since the Java days, and i'm not blaming the community of doing anything wrong here, giving its the expected behavior of tech communities nowadays. But there is this noise into how Rust is sugared that i dont think its true, in that its the first system language that is as productive as a mid-level normally GCed language like Java or Go while giving more control and performance. I think there is no language into that spot yet, but i think that something that follows Rust could achieve this (Its something in the middle of Rust and Swift). The control and performance are there, as happens to C++, but the productivity is basically the same, which is not very good as compared to other languages that target more of being productive than being in control. The control level pay out in the end in the quality of the final product, but it s not the best option for things that dont require the amount of control that C++ and Rust gives you. But the thing with Rust, C++, Zig, etc.. is that, when you need it, you need it. There are things that can only be done with those kind of languages, and often are very complex and high-performant piece of software. Its not for everyone, and you need a sort of commitment that you would only pay if you really need. So writing things like 'web services' on them is not optimal, and you should use languages like Go, Java et al. for this. Tech people should be able to navigate hype and marketing lingo and see the things for what they are, i think is the same that is happening with 'web3' right now.

zozbot234 5y ago
> The control and performance are there, as happens to C++, but the productivity is basically the same This is not very fair to Rust. It's absolutely more productive than C++ when you account for the productivity benefits of "not shooting yourself in the foot" with pesky memory-safety bugs. Let's not even talk about scripting tools like Python, Ruby or JS that were never designed for "programming in the large" yet have somehow become popular in that role (with predictable consequences wrt. technical debt and lack of long-term maintainability). The proper, challenging comparison is with correctness-oriented GC languages like Haskell, OCaml, possibly F#. And Rust might nonetheless have the better community, since it can address systems-level and performance concerns out of the box unlike those.
- Serow225 5y ago
  I work at a place that has started using Rust for backend services lately and I enjoy it, but IMO using F# instead would have given many of the benefits with a lower on-ramp time for new devs and generally higher dev velocity…
- berkut 5y ago
  I don't agree it is at the prototyping level... I think C++ is quite far ahead there than Rust IMO... For a 'stable' production implementation after prototyping, I agree that the benefits Rust provides (if it compiles, it will either panic or work) are well worth it, and so longer-term, I buy that you probably will spend less time, but in my experience, things like not being able to specify default field values inline (you need to provide a 'new' function, or 'default' impl, meaning you then have very tightly-coupled parts in different places in the code) compared to C++11's member variable inline initialisation is very fustrating when in the early stages of prototyping, when things are changing a lot. Similarly, as mentioned above - string handling, with as_str(), to_string(), String::new(), from(), etc, I think make some sense at a full production level when you might care about ownership / copies / allocations, and want them to be explicit, but when you're just prototyping stuff to work out data structures and relationships, it's increadibly annoying IMO when you're refactoring.
  - zozbot234 5y ago
    > things like not being able to specify default field values inline Rust's "struct update syntax" can be reused to do this. `MyStruct { my_field: 42, ..my_local_defaults }`, where my_local_defaults is an instance of MyStruct that's in scope.
    - berkut 5y ago
      That's not what I meant by inline. In C++, you can set the default at the same time as you declare the member variable, meaning the three things (variable type, variable name and variable default) are in exactly the same place in the code on the same line. In Rust, you can't do this, you need to implement new() or default() (or manually specify all field items when declaring the struct), which is normally in another place in the code, so you have tightly-coupled code in two places, which is as bad as C++ headers and implementation files which is what a lot of Rust evangelists seem to complain about on here about C++ (it's a valid complaint, but I don't think Rust completely gets it right, as is complicates / makes things more verbose in other ways like this one).

zozbot234 5y ago

> The control and performance are there, as happens to C++, but the productivity is basically the same This is not very fair to Rust. It's absolutely more productive than C++ when you account for the productivity benefits of "not shooting yourself in the foot" with pesky memory-safety bugs. Let's not even talk about scripting tools like Python, Ruby or JS that were never designed for "programming in the large" yet have somehow become popular in that role (with predictable consequences wrt. technical debt and lack of long-term maintainability). The proper, challenging comparison is with correctness-oriented GC languages like Haskell, OCaml, possibly F#. And Rust might nonetheless have the better community, since it can address systems-level and performance concerns out of the box unlike those.

Serow225 5y ago
I work at a place that has started using Rust for backend services lately and I enjoy it, but IMO using F# instead would have given many of the benefits with a lower on-ramp time for new devs and generally higher dev velocity…
berkut 5y ago
I don't agree it is at the prototyping level... I think C++ is quite far ahead there than Rust IMO... For a 'stable' production implementation after prototyping, I agree that the benefits Rust provides (if it compiles, it will either panic or work) are well worth it, and so longer-term, I buy that you probably will spend less time, but in my experience, things like not being able to specify default field values inline (you need to provide a 'new' function, or 'default' impl, meaning you then have very tightly-coupled parts in different places in the code) compared to C++11's member variable inline initialisation is very fustrating when in the early stages of prototyping, when things are changing a lot. Similarly, as mentioned above - string handling, with as_str(), to_string(), String::new(), from(), etc, I think make some sense at a full production level when you might care about ownership / copies / allocations, and want them to be explicit, but when you're just prototyping stuff to work out data structures and relationships, it's increadibly annoying IMO when you're refactoring.
- zozbot234 5y ago
  > things like not being able to specify default field values inline Rust's "struct update syntax" can be reused to do this. `MyStruct { my_field: 42, ..my_local_defaults }`, where my_local_defaults is an instance of MyStruct that's in scope.
  - berkut 5y ago
    That's not what I meant by inline. In C++, you can set the default at the same time as you declare the member variable, meaning the three things (variable type, variable name and variable default) are in exactly the same place in the code on the same line. In Rust, you can't do this, you need to implement new() or default() (or manually specify all field items when declaring the struct), which is normally in another place in the code, so you have tightly-coupled code in two places, which is as bad as C++ headers and implementation files which is what a lot of Rust evangelists seem to complain about on here about C++ (it's a valid complaint, but I don't think Rust completely gets it right, as is complicates / makes things more verbose in other ways like this one).