Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it.
It might not have been time four years ago, but it's time now.
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".
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.
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.
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... which gives a pretty good solution.
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.
When you're actually starting up (you set the context to "someone starting to learn rust"), there will be some unknown things in any language. You'll get there, but you don't need to understand it from the beginning. If you do want to understand it, then you should get it from the official guide. Errors, dyn, box, lifetimes and send are covered.
"Value on the heap, which implements the error interface, is available forever, and can be shared between threads" is... not that complicated.
> Now you put it in production and it breaks.
If you're still learning the language and don't understand the boilerplate, you don't put your app in production.
> Why would I pass in a mutable reference when all I need is a global static immutable value?
You missed the context. The fragment was about a mutable global. If you just need an initialised, but immutable config, you pass a non-mutable reference.
I guess that time will never come...unless Go somehow looses its way
Before downvoting, this is our experience.
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.
It does, and it's very evocative.
If we revisit that now, C++ is the wrong language to start Envoy in today.
classic HN obnoxious "citation needed" commentary strikes again. i swear i'm just gonna keep doing this every time i see this... until i get bored and give up, i guess.
The fact is, most opinions about what language somebody else ought to write their next library in are worth about what they cost to post.
Another is that, trendiness notwithstanding, Rust right now is best suited for a library few people will need. That may change in five or ten years. It might well not.
This is useful for p2p systems in which you are connected to thousands of peers multiplexing several p2p protocols with each concurrently. You want to be able to switch threads as fast as possible.
The concurrency model is a bit easier to reason about too.
It would be good to see how Rust and others do. Other languages excel at other things (i.e. embedded devices ).
Honestly I'm not sure why Go was picked specificall, but if you put things in the context of 5 years ago it doesn't seem a crazy choice.
They're very sensible about it, and advocate using the right tool for the job.
https://blog.discord.com/why-discord-is-switching-from-go-to...
A big reason why C is still widely used. A library that's written in C can be used in any other language.
go-ipfs is where the majority of new development happens right now as the desktop/server implementation (compared to js-ipfs=browser & rust-ipfs=IoT) - but if you want to prove that Rust is clearly better/faster _in general_ - have at it: https://github.com/ipfs-rust/rust-ipfs ;)
I think the thing jbenet was selecting for back in 2013 was concurrency support & modularity, and golang is still a decent choice for that. Rust 1.0 didn't happen until 2015 after the go-ipfs alpha was already out - but agree it's made awesome progress since then!
But fair point :)