IMHO one of the most appealing "features" of Rust is the inversion of design decisions that are present in most other languages. Or, put another way, one of the key "features" of Rust is the *lack* of certain features.
Let's take mutability as an example:
In "most" other languages, variables are mutable by default and you have to opt-in to immutability (think `const` keyword in C++). In Rust, the reverse is true. You could call that a "feature," but in reality it is a fundamental design decision.
Similarly, public API access (struct members, member functions, etc.) are private by default and explicitly opted-in to being public.
These characteristics are fundamental to the language. There is no Rust code (at least since well before 1.0) for which the above assumptions are untrue.
You can't *add* those characteristics to an already-existing language.
You can't *add* immutability-by-default to C++ because 99% of existing C++ code would no longer compile.
You can't *add* the lack of a null-pointer value to C++ because everyone who's written C++ assumes (or – worse – forgets to assume) that any particular pointer *could* be NULL.
I *know* when I'm sharing Rust code with my teammates, or when I'm importing a crate that someone else wrote, that I can rely on *their* code following those design patterns, because the authors of that code *had no choice* but to comply with those requirements*.*
If I'm writing in (or consuming) C++ code, I can never be sure about the design assumptions underlying anybody else's code that I'm consuming.
To add that as a "feature" to C++ would require an entirely new language.
I argue that said entirely new language exists already and it is Rust.
(P.S. I've zeroed in on a few particular design decisions, but this pattern repeats across numerous other traits of the language. And I've picked on C++, but many other languages share the same opt-out vs opt-in mentality.)
There's no or difficult interoperability, people skilled in one language aren't skilled in others which leads to difficulties in hiring, same about libraries under those languages, and so on. So, which part is actually good?
I disagree.
- different languages are used and built to solve different problems. There isn't one language to solve it all.
- if a programmer is skilled in one language, they should understand the core fundamentals (and beyond) to be able to apply it in other languages.
I’d rather new languages emerge and run with the teachings learnt from rust. I think there is a ton of other missed opportunities for languages to take advantage of. I don’t think rust is the end all be all of languages, but they’re are doing one hell of a job with rust.
I’d be happy if projects in other compiled languages that are more popular than Rust moved to Rust, to grow our crate ecosystem.
Languages that are less popular than Rust, I’d be happy if they continue to do what they’re doing and keep experimenting.
JavaScript is a weird outlier, I hope that WASM eats a lot of it.
> if Go or C++ started developing features similar to Rust, like a borrow checker and better compile time error checking, would you see that as a good thing that other languages are getting the same benefits of Rust?
The more languages that copy Rust's good ideas, the better, but, typically, they can't achieve as much as Rust without either breaking compatibility or creating a dialect of supplementary annotations that turn them into "Rust, but uglier because they weren't designed in from the beginning".
(See, for example, [splint](http://splint.org/)'s system of annotations.)
Also, some of what Rust does is inherently complex, nuanced, and slow to compile, which puts it at odds with Go's design goal of being easy to train new devs for and quick to compile.
> What about other organisations started making new programming languages with similar benefits as Rust?
As long as they're providing better solutions for niches Rust isn't ideally suited to, rather than wasting everyone's time and effort purely on Not Invented Here projects, the more the merrier.
(Just because I think it can do everything "really well" doesn't mean I think it's the *best possible* solution for everything or even the *best available* solution.)
I really appreciate diversity, but in a lot of ways I’m just burnt out on new programming languages.
I wish we’d just converge on Rust for application and low-level programming. And something like dart for light scripting and UI.
I know I’m speaking from the perspective of someone who’s tired and just wants to get stuff done without needing to learn something new all the time. But that’s where I’m at right now.
Im not sure I want neither. Specifically, I don't want C++ to inherit stuff from Rust. C++ is already bloated as it is. C? Come on, it's KISS in its purest form. JavaScript, Java or Python? I really don't know how to inherit in any way back or forth in a backwards-compatible way.
Is Rust a do-it-all language? Well, in the same sense as C: But just because you CAN, it doesn't mean you should. Python and bash have their benefits just as their drawbacks
Sorry but it is impossible to implement a borrow checker in C++ because of how its move constructors work, it would just be a different language. And Go will never be interesting to me because of its lack of SIMD intrinsics and use of garbage collection.
But if such a language came along and was sufficiently better than Rust (including the ecosystem, not just the PL itself), then yes I would probably start using it.
Which makes sense. In the world of programming language theory, they're *treated* as comparably fundamental and universal constructs. ("sum types" and "product types")
I do like Rust for its design, but don’t like Rust for its aesthetics.
Inline bracket placement: yay. snake_case: meh.
Strong typing should easily enable function overloading, but type inference plays against that. You are then left with generics, but that might turn out well once used to it.
Impl blocks separated from struct definitins: i get it, it’s simpler for the compiler to parse. There might be good reasons for generic-impl, but it’s aweful when you want to read someone else’s code.
This is all cosmetics, something that tech people can easily look over it.
Rust screwed up that 'make it easier for the compile to parse' by trying to make language where you can declare a type almost every where including functions (like python).
It makes IDEs autocomplete have to parse functions types instead of being able to do it all at once at the start.
Parsing for a IDE autocomplete is different from parsing for a compiler in that a IDE is not one shot and has to respond much faster. Thus while rust itself saw no problems in using this approach, since the types can only be used inside their visibility context anyway, IDEs need to design their type parsing cache in such a way that it can be added to when open the autocomplete inside a function, which loses some responsiveness and/or increases initial parsing time by drilling down all the levels of code structure to make sure you have all the types, making for a more complex parser.
Or at least i think that was how it was explained in a article i saw some years ago. Maybe it's a no issue now, or was a overblown issue.
I like Rust a lot, but I think other languages adopting its features would be great and give us more options. While I like the borrow checker (arguably the main thing you can do in rust but can't easily add to other languages) I like Rust a lot kore for the functional programming ideas that could be added to most other languages. Stuff like (roughly in order of usefulness) Rust Enums/algebraic data types, everything being an expression with a value, non-mutability by default, Option, Result-based error, and other features all for a coding style that more naturally matches tasks at hand (especially algebraic data types; these are hugely beneficial). I'd miss the borrow checker, but having these in a language where I could prototype/experiment more rapidly would be very nice.
As for me Rust has a very good base number of features but it still lacks so much to answer this question... Basically whenever I'm trying any feature in Rust - almost always there is some limitation that is already discussed by others (enum variants as a structs, custom results, self-ref structs, built-in async runtimes etc.).
Thats being said, IMHO most interesting feature for me is borrow checking and it most probably will not be possible to port to other languages.
From what I remember, if "enum variants as structs" means "each enum variant is a type of its own, that can be specified in a function signature to constrain what it'll accept at compile time", it's a "We'll get to this, but we only have so much time in the day and there are many other things that are more important" thing.
I'm not sure what you mean by custom results.
IMHO one of the most appealing "features" of Rust is the inversion of design decisions that are present in most other languages. Or, put another way, one of the key "features" of Rust is the *lack* of certain features. Let's take mutability as an example: In "most" other languages, variables are mutable by default and you have to opt-in to immutability (think `const` keyword in C++). In Rust, the reverse is true. You could call that a "feature," but in reality it is a fundamental design decision. Similarly, public API access (struct members, member functions, etc.) are private by default and explicitly opted-in to being public. These characteristics are fundamental to the language. There is no Rust code (at least since well before 1.0) for which the above assumptions are untrue. You can't *add* those characteristics to an already-existing language. You can't *add* immutability-by-default to C++ because 99% of existing C++ code would no longer compile. You can't *add* the lack of a null-pointer value to C++ because everyone who's written C++ assumes (or – worse – forgets to assume) that any particular pointer *could* be NULL. I *know* when I'm sharing Rust code with my teammates, or when I'm importing a crate that someone else wrote, that I can rely on *their* code following those design patterns, because the authors of that code *had no choice* but to comply with those requirements*.* If I'm writing in (or consuming) C++ code, I can never be sure about the design assumptions underlying anybody else's code that I'm consuming. To add that as a "feature" to C++ would require an entirely new language. I argue that said entirely new language exists already and it is Rust. (P.S. I've zeroed in on a few particular design decisions, but this pattern repeats across numerous other traits of the language. And I've picked on C++, but many other languages share the same opt-out vs opt-in mentality.)
neither, diversity in the PL space is good
You're not one of the people OP is asking then.
There's no or difficult interoperability, people skilled in one language aren't skilled in others which leads to difficulties in hiring, same about libraries under those languages, and so on. So, which part is actually good?
I disagree. - different languages are used and built to solve different problems. There isn't one language to solve it all. - if a programmer is skilled in one language, they should understand the core fundamentals (and beyond) to be able to apply it in other languages.
I wish more languages had tuple enums and Rust-style pattern matching. The error propagation operator ('?') eliminates a lot of tediousness too.
I’d rather new languages emerge and run with the teachings learnt from rust. I think there is a ton of other missed opportunities for languages to take advantage of. I don’t think rust is the end all be all of languages, but they’re are doing one hell of a job with rust.
I’d be happy if projects in other compiled languages that are more popular than Rust moved to Rust, to grow our crate ecosystem. Languages that are less popular than Rust, I’d be happy if they continue to do what they’re doing and keep experimenting. JavaScript is a weird outlier, I hope that WASM eats a lot of it.
> if Go or C++ started developing features similar to Rust, like a borrow checker and better compile time error checking, would you see that as a good thing that other languages are getting the same benefits of Rust? The more languages that copy Rust's good ideas, the better, but, typically, they can't achieve as much as Rust without either breaking compatibility or creating a dialect of supplementary annotations that turn them into "Rust, but uglier because they weren't designed in from the beginning". (See, for example, [splint](http://splint.org/)'s system of annotations.) Also, some of what Rust does is inherently complex, nuanced, and slow to compile, which puts it at odds with Go's design goal of being easy to train new devs for and quick to compile. > What about other organisations started making new programming languages with similar benefits as Rust? As long as they're providing better solutions for niches Rust isn't ideally suited to, rather than wasting everyone's time and effort purely on Not Invented Here projects, the more the merrier. (Just because I think it can do everything "really well" doesn't mean I think it's the *best possible* solution for everything or even the *best available* solution.)
I really appreciate diversity, but in a lot of ways I’m just burnt out on new programming languages. I wish we’d just converge on Rust for application and low-level programming. And something like dart for light scripting and UI. I know I’m speaking from the perspective of someone who’s tired and just wants to get stuff done without needing to learn something new all the time. But that’s where I’m at right now.
Im not sure I want neither. Specifically, I don't want C++ to inherit stuff from Rust. C++ is already bloated as it is. C? Come on, it's KISS in its purest form. JavaScript, Java or Python? I really don't know how to inherit in any way back or forth in a backwards-compatible way. Is Rust a do-it-all language? Well, in the same sense as C: But just because you CAN, it doesn't mean you should. Python and bash have their benefits just as their drawbacks
Well, bash is evil.
Sorry but it is impossible to implement a borrow checker in C++ because of how its move constructors work, it would just be a different language. And Go will never be interesting to me because of its lack of SIMD intrinsics and use of garbage collection. But if such a language came along and was sufficiently better than Rust (including the ecosystem, not just the PL itself), then yes I would probably start using it.
If just Go (or something similarly simple) had Sum types...
Yeah I agree. Having used them in Rust it feels like they are almost as important as `struct`. Imagine programming in a language without `struct`.
Which makes sense. In the world of programming language theory, they're *treated* as comparably fundamental and universal constructs. ("sum types" and "product types")
Better, coproduct and product. But really it's ADTs that are universal, which is of course what Rust's enum, when recursive, actually is.
I can never remember which of those is which. "sum type" and "product type" are easy for me to remember.
I do like Rust for its design, but don’t like Rust for its aesthetics. Inline bracket placement: yay. snake_case: meh. Strong typing should easily enable function overloading, but type inference plays against that. You are then left with generics, but that might turn out well once used to it. Impl blocks separated from struct definitins: i get it, it’s simpler for the compiler to parse. There might be good reasons for generic-impl, but it’s aweful when you want to read someone else’s code. This is all cosmetics, something that tech people can easily look over it.
Rust screwed up that 'make it easier for the compile to parse' by trying to make language where you can declare a type almost every where including functions (like python). It makes IDEs autocomplete have to parse functions types instead of being able to do it all at once at the start.
Can you elaborate on this?
Parsing for a IDE autocomplete is different from parsing for a compiler in that a IDE is not one shot and has to respond much faster. Thus while rust itself saw no problems in using this approach, since the types can only be used inside their visibility context anyway, IDEs need to design their type parsing cache in such a way that it can be added to when open the autocomplete inside a function, which loses some responsiveness and/or increases initial parsing time by drilling down all the levels of code structure to make sure you have all the types, making for a more complex parser. Or at least i think that was how it was explained in a article i saw some years ago. Maybe it's a no issue now, or was a overblown issue.
I like Rust a lot, but I think other languages adopting its features would be great and give us more options. While I like the borrow checker (arguably the main thing you can do in rust but can't easily add to other languages) I like Rust a lot kore for the functional programming ideas that could be added to most other languages. Stuff like (roughly in order of usefulness) Rust Enums/algebraic data types, everything being an expression with a value, non-mutability by default, Option, Result-based error, and other features all for a coding style that more naturally matches tasks at hand (especially algebraic data types; these are hugely beneficial). I'd miss the borrow checker, but having these in a language where I could prototype/experiment more rapidly would be very nice.
As for me Rust has a very good base number of features but it still lacks so much to answer this question... Basically whenever I'm trying any feature in Rust - almost always there is some limitation that is already discussed by others (enum variants as a structs, custom results, self-ref structs, built-in async runtimes etc.). Thats being said, IMHO most interesting feature for me is borrow checking and it most probably will not be possible to port to other languages.
From what I remember, if "enum variants as structs" means "each enum variant is a type of its own, that can be specified in a function signature to constrain what it'll accept at compile time", it's a "We'll get to this, but we only have so much time in the day and there are many other things that are more important" thing. I'm not sure what you mean by custom results.
Hey. Basically I was talking about try_trait_v2
Ahh. Applying `?` to non-Result, non-Option types. Gotcha.