4 ms·
That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of d
by blub 8y ago
That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting.
If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. It's also moved heavily in the direction of some FP concepts which have zero overlap with C and arguably little to do with C++.
The big assumption Rust is based on is that people will recognise the benefits of memory safety and be willing to pay the price for it. Many outside the early adopter group won't be, that's how the mainstream works.
- baq 8y agoi'd say game developers aren't really the target audience, because they expect to move fast and not necessarily correct, just correct enough most of the time. other developers don't have issues with the compiler being more picky; compile times are more of a problem in adoption than language strictness.
- viraptor 8y ago> the friction is coming from the fact that Rust can't be changed any more The basic language as such doesn't change much, but what the compiler infers and accepts gets extended with almost every release. rustc from 2 years ago is a lot more strict than rustc now. And lots of lifetime annotations you had to do before, you can omit today. The experience is much nicer and the friction definitely goes down.
- duneroadrunner 8y agoRust's usability is advancing, but I'll note that so are C++'s memory safety facilities. Arguably, modern C++ programming is becoming intrinsically more safe than more traditional coding styles (though arguably the use of string_views and spans outside of function parameters is a step backwards), but progress is also being made on the lifetime profile checker (C++'s borrow checker analogue), and there are libraries[1] that allow you avoid potentially unsafe C++ elements, to the degree that (memory and data race) safety is a priority. At present, C++ is significantly lacking in safety enforcement tooling and "community enthusiasm" for memory safety compared to Rust. But to me, it is not obvious that that will be the case indefinitely. It's even plausible that Rust and C++ will sufficiently converge in flexibility and safety that at some point automated translation between the two languages will be a thing. At the moment, I think the main relevant difference in fundamental (as opposed to not-yet-available tooling or whatever) capability between the two languages is Rust's lack of support for move constructors/destructors. I think it prevents the safe, efficient, unintrusive, robust implementation of a small but significant set of algorithms / data structures. But I guess my point is that I think that C++, and its existing codebases, are not necessarily condemned indefinitely to be memory unsafe in the way they have been historically. And that could be a factor that contributes to the justification of deciding to continue to use C++ in some cases. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
- nicoburns 8y agoC/C++ developers can't use Rust without learning new concepts. That's not a failure. If there were no new concepts, then there wouldn't be any point in the langauge in the first place.
- dzdt 8y agoContrariwise there is huge demand for a language with a trimmed-down set of concepts from C++ and a much improved syntax.
- kevin_thibedeau 8y agoD, Nim, Go.
- deleted 8y ago[deleted]
- gonzus 8y agoI am putting my money and hopes on Zig.
- kazinator 8y ago> If there were no new concepts, then there wouldn't be any point in the langauge in the first place. Not so; the same concepts can be clarified and captured in a better set of requirements, leading to better implementations of the concepts. There can be a point in fewer concepts that are simpler.
- pcwalton 8y ago> the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. What is your proposal, specifically? It's not that we weren't listening to C++ programmers 10 years ago. We put a ton of effort into making Rust as easy to use as possible. Rather, it's that the problem of memory safety without GC is fundamentally hard. If I could wave a magic wand and release an incompatible Rust 2.0 with memory safety and no new concepts to learn over C++, I'd do it. But it's easy to just say you want a new language. It's a lot harder to actually design such a thing. I generally think that if you want memory safety, you must either have a garbage collector or the mutability rules and borrow check. There is no other option.
- dan-robertson 8y agoDo you think it was obvious that such mutability rules and borrow checks were sufficient before languages like rust were invented? What about a more impractical approach like e.g. ATS?
- tombert 8y agoSpeaking out of genuine ignorance here...if the only ways to get memory safety without GC, how does Swift or Objective C do it with ARC?
- deleted 8y ago[deleted]
- littlestymaar 8y agoArc is a kind of automatic memory management that's included when people talk about GC in general.
- pcwalton 8y agoReference counting is a form of garbage collection.
- tombert 8y ago