61–70 of 110 posts
> Are we talking about safety against hackers? The large majority of C++ applications are non-public facing.
Total nonsense. Even a PHP application will be running behind various webservers written in C/C++, the runtime is written in C, and there are plugins/libraries like libcurl also written in C/C++.
Earlier quoted context omitted.
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…
FWIW, that's what Mozilla is doing.
If CLion/RustRover support was there, I'd probably switch my personal project over to Bazel+vendored deps.
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?
There was an era of stability in the Haskell project during which it was possible to write code for industrial purposes. A lot of people were attracted to the idea of a memory-safe language that compiled to native binaries, and there wasn't much competition in that area at the time.
Then the research-oriented nature of the language and community re-asserted itself with Haskell 2010, and there was a lot of churn in both the base libraries and Hackage. Around this time was when Swift, Go, and Rust had their first releases, all of which offered memory safety and varying levels of ML/Haskell inspiration. So Haskell was suddenly less appealing, and there were other options -- why file another perf-regression GHC ticket into the void when Go has an HTTP server built right into the stdlib?
Earlier quoted context omitted.
I'd wager that any highly qualified C++ engineer worth working with can pick up Rust and become a highly qualified Rust engineer in And honestly, I'd rather work with those people than with people who came to Rust from languages like Python, Java, TypeScript, etc.
Yeah, I've seen C++ engineers pick up Rust in a few weeks. And one JavaScript engineer, too, defying my prejudice :)
If the codebase that the eng is being brought into is established with good conventions, I could see it happening quickly though.
I agree. I'm using it both in the game server, the client and for scripting! So far I haven't really had any serious problems that would be related to unsafety. You just have to be disciplined. Source: https://medium.com/@fwsgonzo/using-c-as-a-scripting-language... I do see that peoples experience with C++ varies wildly, because shops either don't understand why modern C++ exists or they don't care. Either way, predi…
That's the reason for which Mozilla (and now some of the developments at Google, Facebook, Microsoft, Amazon) has started moving to Rust a while ago.
Also, I've written it somewhere else, but I'm going to repeat it:
> which practically never crashes because of memory problems
When you have memory issues, crashes are the lucky case. The common case is random memory corruption.
Earlier quoted context omitted.
1. Hard to count. Started as a youth on game modding, but in terms of serious projects, probably 5-7 years. 2. Rust. It's a Rust shop, and the only C++ we have is in dependencies that we wrap with Rust interfaces. 3. Rust. I've probably shaved a not-inconsiderable amount of time off my life in debugging C++ issues at both compile-time and runtime (inscrutable behaviours, memory safety, broken / unstandardized tooling…
> ADTs C++ is already a very complex beast as it is. ADTs (and pattern matching) make it concise to express many different programming things. But I'd imagine that adding it to C++ would be horrendous.
That beings aid, I don't disagree with your general point. C++ is already incredibly complex and impossible to understand as a single individual; I don't think that can be fixed without removing things from the language.
My gut feeling is that the future of C++ is not C++, it's cpp2 or Carbon.
Earlier quoted context omitted.
Speak for yourself: I'm not returning to the world of "discipline" (aka lost productivity) without a damn good reason to carry on existing codebases. It's just a waste of a good coder and certainly of good time.
In C++ discipline is optional. In Rust it's mandatory.
Earlier quoted context omitted.
Even brilliant developers on the Linux kernel teams and Postgres teams make memory mistakes that lead to security problems. Maybe you are at a higher level than them though.
My point is that I am acknowledging that C and C++ needs more discipline. I'm not saying we eliminated this class of bugs!
I don't know C++, but being freed from making effort to avoid a class of bugs was easily enough for me to learn Rust instead (not that this was the only reason).
Earlier quoted context omitted.
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?
Entirely different snack bracket. Haskell is great stuff, but not something you'll be able to practically staff a team and build with. 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.
> And it's targeted in an entirely different domain -- systems programming.
> Haskell is a garbage collected pure functional programming language.
You can see the Haskell influence in Rust today, for example the popular benchmarking library https://crates.io/crates/criterion> is directly inspired by https://hackage.haskell.org/package/criterion>. I've seen a lot of the same names in the Git logs and chat rooms.
In retrospect, starting with a low-level systems language and adding safety turned out to be a better idea than using `ST a` to implement borrow-checking in a high-level GC'd hosted language. I can only say "it seemed like a good idea at the time...".
all my new projects are in c17 and c++20,no rust for me. I agree they need a build system like cargo, though cmake kind of works for me. with carbon and cppfront in the works,c++ will keep evolving
I actually think Cargo & crates.io are the weakest and shittiest part of Rust right now. They're a bit amateur. But yes, CMake is something I do not miss. Though I miss the alternatives even less. Though C++ with Bazel is actually quite attractive.