20 ms·
As someone casually following Rust and haven't touched it or C++ in probably 5+ years (but keeping tabs in hope of coming back to that world), I feel like a lot
by moonchrome 3y ago
As someone casually following Rust and haven't touched it or C++ in probably 5+ years (but keeping tabs in hope of coming back to that world), I feel like a lot of decisions he mentions are what made me optimistic about Rust adoption/positioning itself as a modern C++ replacement. So I kind of agree with his conclusion - his version of Rust would be much less interesting to me, and I think a lot of it's current users. eg. I only started playing with Rust once they removed green threads. Zero cost abstractions are a major selling point.
- kzrdude 3y agoI was at the sidelines when Rust 1.0 was being made and I think it got into an llvm induced feedback loop. Slowly turning into C or C++ with other features but the same type, object and memory model. Part of the reason was Rust's desire to show itself as a direct competitor w.r.t performance, I think.
- Ygg2 3y agoPerformance, but with sanity. Say you use a vector in C++. You push one element and pop two. In Rust that's a None. In C++ the answer is UB (in my case 43).
- intelVISA 3y agoThe fatal mistake here is using the STL...
- tialaramex 3y agoThe safe thing Rust did here is affordable in Rust (Option<T> is the same size as T for many T including all references) so they could afford to do it, whereas it's expensive in C++. Could it have been made cheaper in C++? Sure, but safety wasn't their priority so who cares? That prioritisation applies to the whole ISO language, not only to the standard library.
- pjmlp 3y agoTalking about C? https://godbolt.org/z/vYcMhE9h7 https://godbolt.org/z/vYcMhE9h7
- tialaramex 3y agoYou turned on a feature which helps diagnose this type of mistake at runtime, and it helped you by diagnosing the mistake at runtime. What does that prove? What I'm talking about is that Rust's Option is very cheap in all the cases where it can be very cheap, which makes this whole design feature more affordable. C++ eventually grew std::optional which is not powerful enough for this work and yet is also bigger and slower. They could have done better, but safety wasn't a priority.
- pjmlp 3y agoIt proves that there is a way to diagnose this type of mistake, that is what matters. Unlike C, which the only way to be safe is not to touch it at all. As for performance, ISO doesn't implement compilers, there are many ways to improve performance while keeping the semantics in line with the standard. If the compiler vendors decide to focus elsewhere is another matter, a bit like there are languages as complex as Rust and compile faster, because that has been a concern, whereas rustc developers have their concerns elsewhere.
- pjmlp 3y agoThe fatal mistake is not enabling bounds checking, which most STL implementations support.
- intelVISA 3y ago-Wabsolutely-everything I haven't written the Language of Kings in a while: does GCC -Wall truly enable all warnings yet?
- staunton 3y agoObviously not. It would be an instant scandal if they tried that.
- astrange 3y agoIt doesn't, and that would be a bad thing, because warnings aren't magic and bug-free themselves. Nor is there any reason to comply with every single warning every person in the world has come up with. clang has a -Weverything and it isn't supported.
- FpUser 3y agoAnd what should be defined behavior? There are quite a few choices that depend on particular situations. Feature designers have no knowledge about what would you want so they left it up to application programmer to check the situation upfront and act accordingly to their wishes. If you want same behavior across the whole application you can always write generic function doing just that.
- Ygg2 3y agoReturn either value or an EMPTY placeholder. Look Java did it. It returns a nullable value or Optional.
- FpUser 3y agoThen I have to check the result anyways. Same thing
- mughinn 3y agoYou should always check The argument is that Rust forces you and in C++ you can forget/the compiler can do what it wants
- Ygg2 3y agoNo. In Rust check is there by default, with optional unchecked access. In C++ the safety is off by default and you have to remember to check. It's like Yaml parsers, they had "load_yaml" which is unsafe and "safe_load_yaml" which is the secure option. Imagine no surprise when Rubyists went for shorter safe looking method and got their servers pwned.
- FpUser 3y agoI think you are wrong. I looked and in Rust doc it says that: "Removes the last element from a vector and returns it, or None if it is empty". You better be doing check for "None".
- 3y ago
- pjmlp 3y agoIn C++ it is an error, if one bothers to enable bounds checking. https://godbolt.org/z/vYcMhE9h7 https://godbolt.org/z/vYcMhE9h7 > Error: attempt to access an element in an empty container.
- dmm 3y agoSomeone much more insightful than me pointed out that most of the safety advantages of Rust are really a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day but when building systems and libraries with Rust, people value safety and Rust enables that as a priority.
- pjmlp 3y agoYes, that is kind of true. It is also what attracted me into C++ coming from Turbo Pascal and Turbo Basic, back in the early 1990's. Although C++ culture could be much better towards safety, it is definitely better than whatever WG14 is doing, or C has brought into the picture for the last 50 years. Also anyone that just copy pastes C like code into C++, is the kind of developer that will be using unsafe{} all over the place, on the languages that have them.
- imtringued 3y agoTelling people to stop using unsafe is much easier than telling people to not have undefined behaviour. C developers like telling themselves that only people with bounded rationality make security critical mistakes. All the skilled C developers have ascended beyond the mortal realm and would never let themselves be chained up with crutches for the weak like affine types or overflow/bounds checking.
- worik 3y ago> a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day Yes you could. But I do not think " cultural" is the right term for not putting all your code in an `unsafe` block
- rob74 3y agoI think this quote also applies more generally: > It's easier to work with than C++, but that's fairly faint praise. So, while Rust positions itself as a C++ alternative with all the complexities that C++ developers love, it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust...
- smabie 3y agoThere's tons of existing languages that are mostly okay that you can develop a webapp in. Rust as a C++ replacement serves a real unmet need in the marketplace.
- deleted 3y ago[deleted]
- devjab 3y agoWe build a proof-of-concept backend replacement for what is essentially “SharePoint being used as a DB with a frontend by people who don’t know how to use SharePoint” and was a nice experience. We also build it in a few other languages, C#, Go, Python and TypeScript and Rust was probably the best experience of them all. We ended up going with C# because we needed Odata, and at the time we hadn’t yet run into the many “joys” of working with Odata, ASP and Entity Framework and how their model builders, really, really, really, won’t play together nicely. Knowing what we know now, we should’ve gone with TypeScript and just written our own Odata filter on top of it, but live and learn. If I was in a position where I could pick and chose languages, and not worry about how not having TypeScript in most things will mean our best front-end developer can never go on vacation because he’s sort of our only front-end developer, I wouldn’t mind using Rust for web-backends. Rust GUI is obviously not a great experience. At least not yet. But it’s not that bad either. I think it’s mostly the case of how JavaScript is just so good at it and seeing such a fast pace of improvements because the entire world uses it for most GUIs these days, that it’s just hard for anything else to compete. I mean, look at stuff like Flutter or Blazor, they are backed by Microsoft and Google and they’re vastly inferior choices for most use cases compared to simply building things in React, ReactNative or even electron, and that’s not because I have some wild love for JavaScript, it’s because it’s seeing rapid improvements they dwarf it’s competition simply by being used by a lot of people. I wish Rust would have someone like Facebook pick it up and build a frontend framework for it, but I think that is just too unlikely for you to bet on, and you certainly wouldn’t want to do it yourself, even as open source because then that would probably be your entire job. On the flip-side, the packages that handle basic back-end web stuff for Enterprise use are rock solid in Rust. Which is impressive, at least to me, considering it’s young age. I have no idea why, but maybe some serious players are contributing to it because they use it themselves. There isn’t a “Django” or Ruby+Rails for Rust, but if what you’re building is a lot of smaller APIs with various transport methods and data access in an federated authentication scenario then Rust is surprisingly mature for the web. It’s primary disadvantage being that your TypeScript and Rust developers won’t be able to cover for each other (which is why we didn’t poc with Java).
- sph 3y agoIt makes me smile that my top-level comment says I would have preferred the ML-version of Rust, while you say you prefer the zero-cost-abstraction version of Rust that's more C++-like. Indeed in software engineering there is no silver bullet nor a perfect language for everybody :-)
- kaba0 3y agoML-version of Rust would not have been a uniquely interesting language. It targeting the C++-niche is what made it into quite the big name it has become.
- unrealhoang 3y agoThere’s already a ML-version of Rust, it’s Ocaml