5 ms·
If you want to convince people that Rust should be thrown away in favour of mbeddr or something else, you need to make an argument based on specific design flaw
by roca 6y ago
If you want to convince people that Rust should be thrown away in favour of mbeddr or something else, you need to make an argument based on specific design flaws of Rust, not just tar it by association with C++.
That argument would have to not just explain why an improved language is needed, but also why Rust can't evolve into that language via the edition system. It would also have to convince people that whatever benefits the improved language brings justify moving away from the existing crate ecosystem, tool ecosystem, and developer pool, and building new ones (or how you would reuse/extend/coopt them).
(In reality I think the influence of Haskell and even node.js were as important to Rust as C++.)
- cxr 6y agoFunny, before your comment showed up, I was actually going to edit in an addendum to link to https://robert.ocallahan.org/2018/10/the-costs-of-programming-language.html https://robert.ocallahan.org/2018/10/the-costs-of-programmin... ... to pair with the mbeddr link. You seem to be at a place where you think of Rust as already entrenched, but I'm at a place where I still see Rust as a proposition—one that could lead to that place, or not if we think better and nix it (following the reasoning above).
- loeg 6y agoI don't think Rust is going away. You may not like it; it may not be adopted by the Linux kernel. But it is widely used in real codebases (including, say, Firefox). It's not brand new. And the article linked above discourages creating new languages; valid or not, that horse is well out of the barn.
- cxr 6y agoThe post as written, and whether intended or not (admittedly by current signs, I guess it'd be foolish to wager anything other than "not"), ends with an observation that's still highly relevant here but that you're neglecting to account for. > I hope people consider carefully the social costs of creating a new programming language especially if it becomes popular, and understand that in some cases creating a popular new language could actually be irresponsible. And being widely used is not the same thing as being entrenched, not the same thing as being unable to say, "nice prototype; let's wrap this up now and do it for real this time".
- loeg 6y ago> ends with an observation that's still highly relevant here but that you're neglecting to account for. No, that's kind of the sentence I was responding to. Rust is already popular; that horse is out of the barn. > And being widely used is not the same thing as being entrenched, not the same thing as being unable to say, "nice prototype; let's wrap this up now and do it for real this time". I don't care to argue about the first clause, but I don't understand how you can argue the latter. Who is going to say "nice prototype; let's discard this?" Do you expect the Rust-using projects to just fold? Do you expect Rust developers to just disappear? Again, it sounds like you don't like Rust, which is fine, but as someone external to the community, why do you think anyone would listen to you about spinning down Rust?
- roca 6y agoAs someone who's spent the last few years writing a 170K line Rust project ... I consider it entrenched! I stand by that blog post, though I recognise it's controversial. I think Rust clearly qualifies as "worth the cost of a new language". There simply wasn't, and still isn't, any other serious contender for safe GC-free systems programming. New contenders will arise but in the meantime lots of projects are doing safe systems programming that without Rust would have been done in C or C++ and would have had to be unsafe.
- cxr 6y agoEven if the benefits are "worth the cost of a new language", is using the new language worth the cost of it being Rust?
- roca 6y agoYou have not made your argument clear. Are you questioning whether Rust is simply not good enough to be worth using by anyone? Lots of people, including me, have judged that is worth using for us, both before we tried it and after we've put Rust projects into production. (BTW once again you have implied there is something deeply wrong with Rust that cancels out its benefits, without saying what that might be. That is annoying.)
- cxr 6y agoYou're not seeking answers; in place of anything that would lead to a better understanding, you're asking the questions that make it easier to defend the position you've staked out. (Great job, Brendan!) If someone released a memory-safe, highly concurrent, systems-oriented version of INTERCAL, you recognize that someone might look at that and say, "Gee, I don't think that's really worth using", and the comment's lack of detail doesn't nullify the substance of what makes the comment true or not? And an opponent could approach in the same way you are now, with the primary goal of "beating" the other participant—by making it burdensome to respond—and by all appearances do so? It's not my job to painstakingly prepare a perfect, incontrovertible response for a hostile adversary, particularly since absolutely nothing would come of that time investment. If your idea of success is the sound of all your colleagues telling yourselves that you won the conversation and you're on the right track and nothing needs to change because there really aren't any issues... then, hey, that's just fine.
- verandaguy 6y ago>not just tar it by association with C++. To build on this and your last paragraph: I think it's arguably a feature of Rust that it combines: - A syntax that's highly familiar to the legions of C++ programmers already out there - A bunch of features C++ has had in the works but that aren't quite there yet (specifically, a proper module system comes to mind) - Features from ML/OCaml/Haskell, like a first-class option type, first-class (powerful) pattern matching, and an emphasis on immutable-by-default variables Having this without the cruft of the decades of backwards-compatibility that C++ has had (not without good reason, granted) makes Rust the hard refresh of C++ that I and hopefully others have been waiting for for a while.
- Const-me 6y ago.NET has these features for decades. It compiles really fast, much easier to use than C++, and has awesome IDEs. C interop is pretty much same as in Rust. GC is not an issue in modern .NET even for resource-demanding apps running on slow ARM CPUs. Here's an example: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo BTW it consumes non-trivial amount of C APIs like V4L2, ALSA, and audio decoders.
- verandaguy 6y agoThe reasons .NET never really competed with C# for the longest time were a handful: - First-party support for .NET only existed on Windows systems until 2015ish with the release of Rosetta - Third party support across platforms via Mono never really picked up steam for a number of reasons - Early on, .NET code, much like JVM code, wasn't in the same league as C++ in terms of performance - I'd like to be proven wrong on this one, but .NET remains a poor framework to do systems programming in. GC is IMO still a factor because even though modern M&S GCs are impressively performant they still add a degree of unpredictability to your runtime, and sometimes that's not acceptable — so reference counting or something even more basic is preferred, if only for the consistency.
- Const-me 6y ago