4 ms·
Go and try it. I did it, productivity is much higher than cpp for me. For one, pulling down a package is a one liner. It just works, and I haven't come across
by lordnacho 5y ago
Go and try it. I did it, productivity is much higher than cpp for me.
For one, pulling down a package is a one liner. It just works, and I haven't come across a special one that does its own thing yet. The ecosystem seems pretty complete, too. I've yet to have to write my own component: everything from serialisation to async runtime, queues, config parsers, rate limiters, hmac, logging and so on is there.
The big thing though is debugging. I'm CPP is possible to write bugs that manifest in very strange ways when you run the program. It eats up days to debug, and you're never sure if it's actually solved, because there's a large surface that might contain the bug. With rust it will complain at you at compile time. This can be confusing but you'll figure it out eventually and then it's fixed.
- jerrre 5y agoHow long ago did you change, and what kind if software are you working on?
- lordnacho 5y agoMost of a year intensively, was keeping an eye for a long time before. Real time multiplayer game side project, and a trading application. So stuff that needs at least some performance and garbage collection would be something with a real cost.
- fhd2 5y agoAll those crates are actually the main thing bothering me about Rust. I've seen some fairly trivial code bases that pull down north of 1 GB of barely necessary dependencies (a couple of wrappers and utilities). It's not quite as bad as NPM land where some people add a dependency for left padding a string, but dunno... Probably a fairly unpopular take, but I kinda always liked that about C/C++ code bases (that avoid hidden dependencies): It makes you realise the cost of dependencies :P So while Rust eliminates a lot of foot guns from C/C++, IMHO it introduces a major one.
- berkut 5y agoLikewise... I'm more and more finding myself either either looking for less-popular and more minimal crates (that don't need Async, or tens of other further deps), and even writing my own things for certain simple stuff (the latter often reinforced by wanted to experiment and learn). I'm more concerned about many 'critical' (because there's nothing like them in the standard library, i.e. 'rand', 'chrono') and well-recommended crates are still not at version 1.0.0, so technically they could change the API... (they won't/can't, but seems a very odd situation to me).
- jacobmischka 5y agoWhat makes you say they can't?
- berkut 5y agoWell, I'm assuming it would break a lot of code...
- jacobmischka 5y agoThat's what semantic versioning is for?
- berkut 5y agohttps://semver.org/#how-do-i-know-when-to-release-100 https://semver.org/#how-do-i-know-when-to-release-100 Pretty much everyone's using chrono and rand, as there's not really anything else...
- jacobmischka 5y agoI'm not sure what that link is supposed to mean in this context. Yes, they should have released 1.0 sooner. That doesn't change the fact that they may want to make a breaking change in the future and bump the major version number. Tokio is the de facto async runtime, used by many (though not as many as rand and chrono surely, but still), and they've bumped major versions. Some projects still use old versions, which is actually much more problematic since multiple async runtimes usually can't exist simultaneously, but things are still mostly fine overall.
- mgaunard 5y agoThe reason you typically rewrite all those things in C++ is because they're performance-sensitive, and for performance you need control. There are also correctness concerns; it's easier to ensure code is correct if you write it than if you take it from the Internet.