51–60 of 110 posts
Rust is not competing against a stale competitor. C++ has evolved quite significantly. Competition is good and things are improving for everyone. That said, it’s not challenging to write modern c++ without coming across raw pointers or buffers.
That being said, porting existing codebases from "old C++" (say And I know that I've jumped ship from C++ to Rust a while ago. Right now, I don't see any compelling reason to go back.
I'd much rather have a language that just "does the right thing" and or at least prevents me from doing the wrong thing. Not just leaves it as an exercise to the user to pray and hope they get it right.
I haven't had the opportunity to use rust yet but one thing I think I look forward to is a more standard way to deal with dependencies and standard built tools. languages that have a popular package manager have their issues with people using too many dependencies and possibly easier supply chain attacks but dang it's night to just get shit done and not have to futs with makefiles, CMake, Ninja, Scons, auto-config, XCode projects, Visual Studio projects, etc...
Yeah, that's a no from me. I'm a full time C++ dev and every time I code in Rust it is harder for me to switch back. The author has pointed to some issues regarding performance. In the end, you can always rewrite your code to generate other/better assembly, if you really need the speed. I would argue Rust is so much more that just Rust itself. Like many others after noted, it is not only the language, but the whole e…
rustup target add wasm32-unknown-unknown
cargo build --target wasm32-unknown-unknown
rustup target add x86_64-unknown-linux-musl
cargo build --target x86_64-unknown-linux-musl
rustup target add x86_64-pc-windows-gnu
cargo build --target x86_64-pc-windows-gnu
But given their high frequency trading industry, I secretly hope a competitor abuse his code base with a 2^30 priced bid or something and his company go bust.
I've done some C++ but no Rust. I'd like to learn a few things from people who have done both. 1. How many years of C++ programming do you have under your belt? How many years of Rust? 2. For new work projects, do you choose C++ or Rust? Why? 3. For new hobby projects, do you choose C++ or Rust? Why? 4. Is there something about C++ that you wish Rust had? 5. Is there something nice about Rust (apart from the borrow c…
2. I would definitely choose Rust. For better or for worse, the teams I work with tend to consider developer velocity as their highest metric. Between cargo, clippy, crates and the type system, I'm orders of magnitude more productive in Rust.
3. Same thing. My life is too short to spend it debugging memory or concurrency errors.
4. There are a number of C++ libraries that have no equivalent or good bindings in Rust yet. But if you're talking of the language, no. There are C++ features that do not have an equivalent in Rust but I don't miss them.
5. From the top of my head, affine types (e.g. after a `std::move`, the type system ensures that you can't use the value anymore), proper enums, proper pattern-matching, better concurrency operations in the standard library (which pretty much requires affine types), a linter as good as clippy, built-in support for writing new linters/gradual type systems, derive macros (that have access to the AST).
And yet, C++ remains an undesirable coding platform, for the reason alone that there is no package manager. It's difficult to take this blog seriously when there is not even a faint mention of Cargo.
But even beyond that, I have other gripes with other fundamental points of the author's case:
> But is that an apples-to-apples comparison? Well, yes, if you are going to list the “safety” of Rust compared to C++ as a pro, then it’s just fair to list the performance hit of such safety in regards to execution speed.
Making this claim without any numbers to back it up is a very bold move. In fact, looking at benchmarks you can see that Rust can be faster in a fair number of cases: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Sorry, but it strikes me that the people arguing against Rust are C++ die-hards are married so strongly to status-quo that they couldn't possibly imagine a better future. Which is of course no different than die-hards in other languages.
Yeah, that's a no from me. I'm a full time C++ dev and every time I code in Rust it is harder for me to switch back. The author has pointed to some issues regarding performance. In the end, you can always rewrite your code to generate other/better assembly, if you really need the speed. I would argue Rust is so much more that just Rust itself. Like many others after noted, it is not only the language, but the whole e…
rustup target add wasm32-unknown-unknown cargo build --target wasm32-unknown-unknown rustup target add x86_64-unknown-linux-musl cargo build --target x86_64-unknown-linux-musl rustup target add x86_64-pc-windows-gnu cargo build --target x86_64-pc-windows-gnu Boom, killer feature right there.
Earlier quoted context omitted.
1. About 15 years of experience in C++, 2-3 years in Rust. 2. I'm retired now, but I would have considered Rust for any greenfield project that didn't have a compelling reason to pick C++ (e.g. mandatory interop with an existing big C++ library). 3. Rust nearly every time. I sometimes use a layer of C++ as an FFI shim, such as when writing a gRPC client/server (the Rust libs there aren't mature). 4. The library ecosy…
somewhat OT, but what happened to haskell? a few years ago it was all over HN - now you hardly see any mention of it. surely this won't happen to rust?
Earlier quoted context omitted.
1. About 15 years of experience in C++, 2-3 years in Rust. 2. I'm retired now, but I would have considered Rust for any greenfield project that didn't have a compelling reason to pick C++ (e.g. mandatory interop with an existing big C++ library). 3. Rust nearly every time. I sometimes use a layer of C++ as an FFI shim, such as when writing a gRPC client/server (the Rust libs there aren't mature). 4. The library ecosy…
Your thoughts about crates.io mirrors mine exactly. I'm becoming more and more interested in just ditching it entirely and using vendored checked-in (or submoduled) dependencies and managing the transitive dependency tree myself. Cargo&crates.io seems to have been inspired too much by npm. Lots of half-baked, abandoned libs that wantonly pull-in piles of other 3rd party deps and create a sprawling graph of dependenci…
Earlier quoted context omitted.
1. About 15 years of experience in C++, 2-3 years in Rust. 2. I'm retired now, but I would have considered Rust for any greenfield project that didn't have a compelling reason to pick C++ (e.g. mandatory interop with an existing big C++ library). 3. Rust nearly every time. I sometimes use a layer of C++ as an FFI shim, such as when writing a gRPC client/server (the Rust libs there aren't mature). 4. The library ecosy…
somewhat OT, but what happened to haskell? a few years ago it was all over HN - now you hardly see any mention of it. surely this won't happen to rust?
Rust is not nearly so "brainy." It's a much more pragmatic and conservative language.
And it's targeted in an entirely different domain -- systems programming. Haskell is a garbage collected pure functional programming language. Rust is not anything like that.