4 ms·

I wish they would stop adding features and just to lock down the language, and focus on more maintainability and use. Adding features is nice but its one of the

I wish they would stop adding features and just to lock down the language, and focus on more maintainability and use. Adding features is nice but its one of the biggest issues that slows down adoption. More people care about learning a language and being able to read code without trying to figure out what some latest feature does rather than some syntactical sugar.

brundolf 4y ago
Most of the features here (and in Rust updates in general these days) are just the loosening of constraints on what you could already do. If anything, these types of changes make the language conceptually simpler. This gets pointed out by somebody in the comment section under every Rust update. The trope that Rust is getting harder to use is tired, and not really based in reality.
- ActorNightly 4y ago
  Different syntax = different ways of doing things = codebases that diverge in implementation. It doesn't matter if the new way doing things is conceptually simpler, you are now creating 2 ways to do things based on what version of the compiler you use, which people will have to know, therefore increasing complexity, not reducing it. I don't understand how people don't get this by now. Saying "oh just learn and use the latest version" is completely unrealistic guidance. And while its fine for high level scripting languages like Python, because the whole idea is to abstract a lot of the functionality into the syntax, the issue with Rust is that its trying to be the next C and be applicable for writing critically important pieces of software like parts of the linux kernel. You absolutely must have a locked down language set for this. The reason C is still used for the kernel isn't because of circumstances, its specifically because there is very few ambiguities in the core language.
  - brundolf 4y ago
    > you are now creating 2 ways to do things based on what version of the compiler you use Which of the features in Rust 1.63 adds a divergent way of doing something you could already do? > The reason C is still used for the kernel isn't because of circumstances, its specifically because there is very few ambiguities in the core language What are some ambiguities in the core Rust language?
  - mbrubeck 4y ago
    Which "different syntax" are you talking about? I don't see any changes in this release that add new syntax to the language.
  - game-of-throws 4y ago
    C was used because it existed 30 years ago, and is full of ambiguities (undefined behavior), and Rust curtails UB quite a bit by defining many semantics that are left unspecified in C. You don't need a "locked down" language to build an OS. In fact Linux just upgraded the version of C they use to C11. Time always marches forward, my friend.
    - sophacles 4y ago
      And C is about to get C23 with additionaly syntax and features.
funklute 4y ago
Rust is a pretty young language though.... if now is not the time to add features, then when is?
game-of-throws 4y ago
Literally every single thing in the post is generalizing a feature that already exists. Don't you think removing these special cases makes the language simpler and easier to use? You might have a point though in a few releases when GATs are stabilized. I'll keep an eye out for your username complaining about that release ;)
Macha 4y ago
There's no new syntax here? The first is a new library function that takes a closure as the parameter. This function has existed for as long as Rust has been 1.0 in the crossbeam library, it's just now also in std. The second change is a new api type. The third change is a library change to increase flexibility of that library. The fourth is arguably a bugfix, where existing syntax could not be used in an edge case. The fifth is unifying the compiler implementations so that some types of patterns now work in code using the oldest compatibility mode that previously only worked in more current modes.
ekidd 4y ago
Almost everything in Rust 1.63.0 appears to be an improvement in the standard library. Scoped threads no longer require a third-party library, some types support "const" better, and a bunch of existing types got some useful new methods. The only real language change here is the "impl / turbofish" one, which allows something that should work, but which wasn't allowed before. I'm not sure it would be realistic to totally stop adding features to the standard library, or to stop making existing syntax work the way a Rust user would expect. I would hope that any actively maintained language does things like these.
oxff 4y ago
I wish they'd break their current backwards compat. promises to fix some accidental complexity that has been introduced. Let legacy langs provide this kind of maintainability
- cercatrova 4y ago
  It's a systems language so they're not gonna break BC. Although if there's a really great feature that comes out that requires BC breaking, then they should do so.
- tialaramex 4y ago
  It's not worth it. For example, it seems as though "Word".contains(char::is_ascii_lowercase) should work, because after all "Word".contains(char::is_lowercase) works and char::is_ascii_lowercase exists and does what you expect, the same but for ASCII only. However, for compatibility reasons char::is_lowercase takes a char, while char::is_ascii_lowercase takes a reference to a char, and so you can't just pass it to contains() and will need to write a closure to pass to contains to do ASCII instead. Writing the closure is ugly, but it's nowhere close to how awful a compatibility break would be so even a million things like this (and so far maybe I can think of a dozen) aren't worth it.
- brundolf 4y ago
  They have the Editions mechanism for unavoidable breaking changes, but their target market is people who care a whole lot about stability and maintainability, so it wouldn't make any sense for them to jettison that design goal.
  - SAI_Peregrinus 4y ago
    Unfortunately the Editions system (as nice as it is) only works for the language, not for the standard or core libraries. It's possible to create such a system (similar to glibc symbol versioning), but AFIAK Rust doesn't currently have one.
pas 4y ago
there are a lot of work-in-progress features that are important so we can write more maintainable code, like GAT. but it's also true that there are quite a few threads that are conceptually simpler than GAT and are just left unfinished. and there is a very serious push (or pushback with regards to GAT) to keep those promises. https://github.com/rust-lang/rust/pull/96709#issuecomment-1181969253 https://github.com/rust-lang/rust/pull/96709#issuecomment-11...

brundolf 4y ago

Most of the features here (and in Rust updates in general these days) are just the loosening of constraints on what you could already do. If anything, these types of changes make the language conceptually simpler. This gets pointed out by somebody in the comment section under every Rust update. The trope that Rust is getting harder to use is tired, and not really based in reality.

ActorNightly 4y ago
Different syntax = different ways of doing things = codebases that diverge in implementation. It doesn't matter if the new way doing things is conceptually simpler, you are now creating 2 ways to do things based on what version of the compiler you use, which people will have to know, therefore increasing complexity, not reducing it. I don't understand how people don't get this by now. Saying "oh just learn and use the latest version" is completely unrealistic guidance. And while its fine for high level scripting languages like Python, because the whole idea is to abstract a lot of the functionality into the syntax, the issue with Rust is that its trying to be the next C and be applicable for writing critically important pieces of software like parts of the linux kernel. You absolutely must have a locked down language set for this. The reason C is still used for the kernel isn't because of circumstances, its specifically because there is very few ambiguities in the core language.
- brundolf 4y ago
  > you are now creating 2 ways to do things based on what version of the compiler you use Which of the features in Rust 1.63 adds a divergent way of doing something you could already do? > The reason C is still used for the kernel isn't because of circumstances, its specifically because there is very few ambiguities in the core language What are some ambiguities in the core Rust language?
- mbrubeck 4y ago
  Which "different syntax" are you talking about? I don't see any changes in this release that add new syntax to the language.
- game-of-throws 4y ago
  C was used because it existed 30 years ago, and is full of ambiguities (undefined behavior), and Rust curtails UB quite a bit by defining many semantics that are left unspecified in C. You don't need a "locked down" language to build an OS. In fact Linux just upgraded the version of C they use to C11. Time always marches forward, my friend.
  - sophacles 4y ago
    And C is about to get C23 with additionaly syntax and features.

funklute 4y ago

Rust is a pretty young language though.... if now is not the time to add features, then when is?

game-of-throws 4y ago

Literally every single thing in the post is generalizing a feature that already exists. Don't you think removing these special cases makes the language simpler and easier to use? You might have a point though in a few releases when GATs are stabilized. I'll keep an eye out for your username complaining about that release ;)

Macha 4y ago

There's no new syntax here? The first is a new library function that takes a closure as the parameter. This function has existed for as long as Rust has been 1.0 in the crossbeam library, it's just now also in std. The second change is a new api type. The third change is a library change to increase flexibility of that library. The fourth is arguably a bugfix, where existing syntax could not be used in an edge case. The fifth is unifying the compiler implementations so that some types of patterns now work in code using the oldest compatibility mode that previously only worked in more current modes.

ekidd 4y ago

Almost everything in Rust 1.63.0 appears to be an improvement in the standard library. Scoped threads no longer require a third-party library, some types support "const" better, and a bunch of existing types got some useful new methods. The only real language change here is the "impl / turbofish" one, which allows something that should work, but which wasn't allowed before. I'm not sure it would be realistic to totally stop adding features to the standard library, or to stop making existing syntax work the way a Rust user would expect. I would hope that any actively maintained language does things like these.

oxff 4y ago

I wish they'd break their current backwards compat. promises to fix some accidental complexity that has been introduced. Let legacy langs provide this kind of maintainability

cercatrova 4y ago
It's a systems language so they're not gonna break BC. Although if there's a really great feature that comes out that requires BC breaking, then they should do so.
tialaramex 4y ago
It's not worth it. For example, it seems as though "Word".contains(char::is_ascii_lowercase) should work, because after all "Word".contains(char::is_lowercase) works and char::is_ascii_lowercase exists and does what you expect, the same but for ASCII only. However, for compatibility reasons char::is_lowercase takes a char, while char::is_ascii_lowercase takes a reference to a char, and so you can't just pass it to contains() and will need to write a closure to pass to contains to do ASCII instead. Writing the closure is ugly, but it's nowhere close to how awful a compatibility break would be so even a million things like this (and so far maybe I can think of a dozen) aren't worth it.
brundolf 4y ago
They have the Editions mechanism for unavoidable breaking changes, but their target market is people who care a whole lot about stability and maintainability, so it wouldn't make any sense for them to jettison that design goal.
- SAI_Peregrinus 4y ago
  Unfortunately the Editions system (as nice as it is) only works for the language, not for the standard or core libraries. It's possible to create such a system (similar to glibc symbol versioning), but AFIAK Rust doesn't currently have one.

pas 4y ago

there are a lot of work-in-progress features that are important so we can write more maintainable code, like GAT. but it's also true that there are quite a few threads that are conceptually simpler than GAT and are just left unfinished. and there is a very serious push (or pushback with regards to GAT) to keep those promises. https://github.com/rust-lang/rust/pull/96709#issuecomment-1181969253 https://github.com/rust-lang/rust/pull/96709#issuecomment-11...