4 ms·

Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects. Rust is a great language, but right now I can start a project in Go

by stryan 6y ago

Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects. Rust is a great language, but right now I can start a project in Go and have someone else start a project in Go and have something up and working in a week. Rust still takes significantly longer to learn and/or find skilled developers for. Go is up there with Python in terms of "Get something out now".

thefounder 6y ago
>> Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects. I guess that time will never come...unless Go somehow looses its way
rosywoozlechan 6y ago
Rust isn't that difficult to prototype or start projects with? What trouble do you run into? I think the hardest parts to understand are the concepts of borrowing, lifetimes, and ownership, but you don't have to know all the subtleties of that to prototype. A basic understanding is fine to get started with. Just like a developer doesn't have to understand all the subtleties of generics to get started with either, lots of devs don't know what covariant or contravariant means and use generics.
- plerpin 6y ago
  Understanding the concepts is one thing, applying them is another thing entirely. The Rust compiler is an incredibly difficult beast to placate.
  - hobofan 6y ago
    Especially in prototyping you can mostly .clone() everything, and stop worrying about any lifetime problems.
    - plerpin 6y ago
      Lots of deferred pain for when you productionize.
      - hobofan 6y ago
        Yes, but this was on the topic of "is Rust suited for prototyping?", and I would say that cloning makes it much more suited, as it sidesteps a lot of the lifetime pains. You will have similar deferred pain if you e.g. prototype something in JS and then when it's time to move to production gradually move it to Typescript. From personal experience of Rust projects in production, you can get by with cloning for a long time, and optimizing later is not too big of a pain in most cases. Performance problems due to excessive cloning are also very obvious in code and easy to profile for.
- StreamBright 6y ago
  Just a minor example. https://github.com/awslabs/aws-lambda-rust-runtime/blob/master/lambda/examples/hello-without-macro.rs https://github.com/awslabs/aws-lambda-rust-runtime/blob/mast... Could you explain to a junior what Box<dyn std::error::Error + Send + Sync + 'static> does and how should a person who is starting to learn Rust come up with something like this? Second minor example. I have a configuration string like let's say timeout for a certain type of connection. What is the recommended way to have that as a string that is accessible to all functions without fighting with the borrow checker? In Elixir, I would use @timeout in the module for example. In Rust, I am not sure. Cloning the value to every place it needs it as a workaround.
  - viraptor 6y ago
    I get what you're trying to say, but disagree with the examples. If you want to prototype and start a project, you don't care what exactly that box type means. You can use it and things will not break. It's part of that particular boilerplate. It's like people using `std::string` and not necessarily caring for years what `template<class CharT, class Traits = std::char_traits<CharT>, class Allocator = std::allocator<CharT>> class basic_string;` means or does. For the second example: environment variable. Once you need more, you can start researching static cells and use a ready crate for configuration loading / processing. If you want more, googling "rust mutable global configuration" brought me https://stackoverflow.com/questions/27791532/how-do-i-create-a-global-mutable-singleton https://stackoverflow.com/questions/27791532/how-do-i-create... which gives a pretty good solution.
    - StreamBright 6y ago
      >> If you want to prototype and start a project, you don't care what exactly that box type means. I disagree. The whole point is to get to know a language. What do you how many things can you have in your code that you do not understand? Now you put it in production and it breaks. Who is going to fix it? I do not have a particulary positive experience with Rust on Stackoverflow. As a tech decision maker I put Rust in the risky category because it is hard to understand and many of the language features are implemented in a way that it is not easy to work with. Don't get me wrong, I like what Rust could bring to the table but with this upfront complexity it is not worth it. I know many companies who will be ok to take on Rust and they are ok with the way things are. Your answer is funny to the second one. From SO: Non-answer answer Avoid global state in general. Instead, construct the object somewhere early (perhaps in main), then pass mutable references to that object into the places that need it. This will usually make your code easier to reason about and doesn't require as much bending over backwards. Why would I pass in a mutable reference when all I need is a global static immutable value? You see this get ugly very quickly. We went with the lazy_static! way, but still. I would rather avoid these things entirely.
- simonebrunozzi 6y ago
  A good related question is: what will be the "future" of software development? I would bet that WASM and Rust will become more and more dominant in a 5-10 years timeframe. But it's so hard to come up with an informed opinion, as many developers tend to become "religious" about their language of choice.
StreamBright 6y ago
Not to mention the learning curve. For junior developers to be productive it takes forever. I can teach F# to a junior in a week, Rust maybe a month. Even for senior devs, it is hard to decipher what is the actual meaning of the code sometimes. There is a lot of noise in Rust that makes it harder to grasp what is happening. Before downvoting, this is our experience.
jhoechtl 6y ago
And therefore Rust will never outcompete Go in this regard in as much as Haskell, Ocaml, ... never overtook C. Rust might draw from the better principles and get things right C, C++, D, Go, ... failed to incorporate. But in order to get things done a company has to source developers from a market and consider that developers get replaced by another, taking over. Even in a globalized developer market a smaller developer force is a risk. In German we have a saying "to die in beauty" (in Schönheit sterben), does that translate? Your boss wants to get things done in due time and I see Go outcompete Rust in this respect.
- StavrosK 6y ago
  > does that translate? It does, and it's very evocative.

by stryan 6y ago

thefounder 6y ago

>> Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects. I guess that time will never come...unless Go somehow looses its way

rosywoozlechan 6y ago

Rust isn't that difficult to prototype or start projects with? What trouble do you run into? I think the hardest parts to understand are the concepts of borrowing, lifetimes, and ownership, but you don't have to know all the subtleties of that to prototype. A basic understanding is fine to get started with. Just like a developer doesn't have to understand all the subtleties of generics to get started with either, lots of devs don't know what covariant or contravariant means and use generics.

plerpin 6y ago
Understanding the concepts is one thing, applying them is another thing entirely. The Rust compiler is an incredibly difficult beast to placate.
- hobofan 6y ago
  Especially in prototyping you can mostly .clone() everything, and stop worrying about any lifetime problems.
  - plerpin 6y ago
    Lots of deferred pain for when you productionize.
    - hobofan 6y ago
      Yes, but this was on the topic of "is Rust suited for prototyping?", and I would say that cloning makes it much more suited, as it sidesteps a lot of the lifetime pains. You will have similar deferred pain if you e.g. prototype something in JS and then when it's time to move to production gradually move it to Typescript. From personal experience of Rust projects in production, you can get by with cloning for a long time, and optimizing later is not too big of a pain in most cases. Performance problems due to excessive cloning are also very obvious in code and easy to profile for.
StreamBright 6y ago
Just a minor example. https://github.com/awslabs/aws-lambda-rust-runtime/blob/master/lambda/examples/hello-without-macro.rs https://github.com/awslabs/aws-lambda-rust-runtime/blob/mast... Could you explain to a junior what Box<dyn std::error::Error + Send + Sync + 'static> does and how should a person who is starting to learn Rust come up with something like this? Second minor example. I have a configuration string like let's say timeout for a certain type of connection. What is the recommended way to have that as a string that is accessible to all functions without fighting with the borrow checker? In Elixir, I would use @timeout in the module for example. In Rust, I am not sure. Cloning the value to every place it needs it as a workaround.
- viraptor 6y ago
  I get what you're trying to say, but disagree with the examples. If you want to prototype and start a project, you don't care what exactly that box type means. You can use it and things will not break. It's part of that particular boilerplate. It's like people using `std::string` and not necessarily caring for years what `template<class CharT, class Traits = std::char_traits<CharT>, class Allocator = std::allocator<CharT>> class basic_string;` means or does. For the second example: environment variable. Once you need more, you can start researching static cells and use a ready crate for configuration loading / processing. If you want more, googling "rust mutable global configuration" brought me https://stackoverflow.com/questions/27791532/how-do-i-create-a-global-mutable-singleton https://stackoverflow.com/questions/27791532/how-do-i-create... which gives a pretty good solution.
  - StreamBright 6y ago
    >> If you want to prototype and start a project, you don't care what exactly that box type means. I disagree. The whole point is to get to know a language. What do you how many things can you have in your code that you do not understand? Now you put it in production and it breaks. Who is going to fix it? I do not have a particulary positive experience with Rust on Stackoverflow. As a tech decision maker I put Rust in the risky category because it is hard to understand and many of the language features are implemented in a way that it is not easy to work with. Don't get me wrong, I like what Rust could bring to the table but with this upfront complexity it is not worth it. I know many companies who will be ok to take on Rust and they are ok with the way things are. Your answer is funny to the second one. From SO: Non-answer answer Avoid global state in general. Instead, construct the object somewhere early (perhaps in main), then pass mutable references to that object into the places that need it. This will usually make your code easier to reason about and doesn't require as much bending over backwards. Why would I pass in a mutable reference when all I need is a global static immutable value? You see this get ugly very quickly. We went with the lazy_static! way, but still. I would rather avoid these things entirely.
simonebrunozzi 6y ago
A good related question is: what will be the "future" of software development? I would bet that WASM and Rust will become more and more dominant in a 5-10 years timeframe. But it's so hard to come up with an informed opinion, as many developers tend to become "religious" about their language of choice.

StreamBright 6y ago

Not to mention the learning curve. For junior developers to be productive it takes forever. I can teach F# to a junior in a week, Rust maybe a month. Even for senior devs, it is hard to decipher what is the actual meaning of the code sometimes. There is a lot of noise in Rust that makes it harder to grasp what is happening. Before downvoting, this is our experience.

jhoechtl 6y ago

And therefore Rust will never outcompete Go in this regard in as much as Haskell, Ocaml, ... never overtook C. Rust might draw from the better principles and get things right C, C++, D, Go, ... failed to incorporate. But in order to get things done a company has to source developers from a market and consider that developers get replaced by another, taking over. Even in a globalized developer market a smaller developer force is a risk. In German we have a saying "to die in beauty" (in Schönheit sterben), does that translate? Your boss wants to get things done in due time and I see Go outcompete Rust in this respect.

StavrosK 6y ago
> does that translate? It does, and it's very evocative.