7 ms·

Sorry for asking. But why even add new features in a language every year. Why not make it like once in 5 years? And focus on fixing and improving the language a

Sorry for asking. But why even add new features in a language every year. Why not make it like once in 5 years? And focus on fixing and improving the language and the compiler. Rust is already a huge language. The editions are also 3 years apart. And between them are tons of new features. Strange. EcmaScript/JavaScript kind of adds like 5-6 features every year. Python. C on the other hand is great. What you wrote in 1990 still is understandable today? (not that C is the best language out there)

3a2d29 4y ago
> (not that C is the best language out there) I think there are many people who might actually agree with this. Tbh, I think anyone making the argument the other is making, would rather Rust follow the path of C than the path of C++.
notriddle 4y ago
How are you planning to limit the rate at which new features are added? * Restricting the rate of new releases doesn't necessarily mean you're reducing the average feature development rate. It might instead mean that you're releasing hundreds of new features per release, which is definitely worse than releasing a hundred versions with one feature each, because it can force people to rush things out to meet a release window instead of releasing them when they're actually ready. * Restricting the number of feature bullet points per release doesn't necessarily mean you're reducing the amount of functionality being developed. It might instead mean that people try to develop huge "super-features" that technically count as one bullet point but actually gets used in dozens of different ways. Super-features are an easy way to wind up with a system where everything is possible, but the stuff you do every day is more difficult than it needs to be.
- remram 4y ago
  Yeah in practice the Rust community writes a lot of code that uses experimental features, that need an explicit feature gate and the nightly build of the compiler. This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers. If the Rust team refuses to ship the features in stable releases, people are just going to use unstable releases and that will make the experience worse for everyone. There is no way to artificially restrict features unless you have multiple software in the ecosystem that needs time to update: for C it is the other compilers following the C standard, for Python it is the Python executable on your end- user's machine. The minute rustc updates, Rust developers have little reason not to use the features.
  - estebank 4y ago
    > This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers. How is this a problem? The crate authors targeting nightly features know full well that they are restricting their pool of users, while at the same time driving the testing and design of nightly features forward. If no one is actually using them, then they are unlikely to get quickly stabilized. > If the Rust team refuses to ship the features in stable releases Can you show a case of refusal to ship a needed feature? > Rust developers have little reason not to use the features. Rust developers of end user applications don't. Crate authors do, if they want to gain wide adoption.
    - remram 4y ago
      I feel like you read my entire comment wrong. Like you didn't read what I replied to, stripped all the "ifs" and arguments, and hyper-focused on points I wasn't trying to make. Surely I wasn't as clear as I thought but this feels so strange.
dralley 4y ago
A lot of the "features" - most of them even - being added to Rust nowadays are just filling holes in the language. Things you might easily assume you could do that for arbitrary implementation reasons, you cannot. A lot of them are basically "fixing and improving the language" IMO. In addition, frequent releases do a better job of incentivizing taking the time to get the design right, because the consequence of missing a release window is that it gets delayed a few weeks, or maybe a few months, instead of a few years. You can totally see this happen with C++ for example.
avgcorrection 4y ago
With language editions, the new features that Rust adds will be mostly a liability for the compiler writers, not the users. So sure you could ask that: why are the language implementors creating more maintenance work for themselves? Well maybe they think those features are worth it.
- notriddle 4y ago
  This isn't really true. If you ever need to debug code in a dependency, then you'll probably need to read code that targets a different edition than your home project does. Over a long enough time frame, you're going to need to at least be able to understand all of the editions.
  - avgcorrection 4y ago
    Sure. In that sense.
smitty1e 4y ago
There seems to be a bit of an arms race between some of the languages. The difference between "New Hotness" and "Feature-itis" is subjective, but I do enjoy the new python featues immensely.
jjtheblunt 4y ago
> not that C is the best language out there I've heard a professor say "C is the best assembler out there" ... felt insightful
- deleted 4y ago
  [deleted]
phkahler 4y ago
C++ gets new features regularly because there is a comitte whose job is to do that. The same was true of OpenGL until they moved on to Vulcan, and they seem to be getting the idea that things dont really have to change so much. Or maybe they're just shifting to making other "standards" instead. To me Rust is more of a toolchain development at this point, where language features are added where it makes sense rather than being a goal.
stusmall 4y ago
> C on the other hand is great. What you wrote in 1990 still is understandable today? That's a weird example. In my career I've noticed big stylistic changes over the years in C. I can usually point out C code from the 90s right away. Usually it just has dated style or is missing what are now common libraries or features. C didn't have a standard bool type until C99 which is usually a good sign of code's age. I remember once I came across some mid-90s code written with the pre-ANSI style of function declarations. It was the first time I'd ever seen it and I was confused on how it even compiled. Outside stylistic things, there are a few idioms and features that I've never seen in newer code bases that might be lost on some newer developers. I can't think of many times I've seen longjump used in modern C.
valbaca 4y ago
> Strange. EcmaScript/JavaScript kind of adds like 5-6 features every year. Python. C on the other hand is great. Those languages have also been around long enough for the new language features to "cool down". Rust was also designed from the beginning to have the language be able to move quickly and safely in this manner (just like Rust code itself!). You're also forgetting the HUGE migration pains that resulted from JS. The gigantic gaps between ES3 and ES5 and ES6. Oh, did I forget ES4? Nope. It was cancelled. Not even going to get started on the disaster that was Python 2->3 or how wildly different the original K&R C is to modern C (I have the K&R book handy to prove it). I honestly find it hilarious that those languages you chose each had terrible migrations between versions, where Rust differences between versions barely make a dev bat an eye.

3a2d29 4y ago

> (not that C is the best language out there) I think there are many people who might actually agree with this. Tbh, I think anyone making the argument the other is making, would rather Rust follow the path of C than the path of C++.

notriddle 4y ago

How are you planning to limit the rate at which new features are added? * Restricting the rate of new releases doesn't necessarily mean you're reducing the average feature development rate. It might instead mean that you're releasing hundreds of new features per release, which is definitely worse than releasing a hundred versions with one feature each, because it can force people to rush things out to meet a release window instead of releasing them when they're actually ready. * Restricting the number of feature bullet points per release doesn't necessarily mean you're reducing the amount of functionality being developed. It might instead mean that people try to develop huge "super-features" that technically count as one bullet point but actually gets used in dozens of different ways. Super-features are an easy way to wind up with a system where everything is possible, but the stuff you do every day is more difficult than it needs to be.

remram 4y ago
Yeah in practice the Rust community writes a lot of code that uses experimental features, that need an explicit feature gate and the nightly build of the compiler. This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers. If the Rust team refuses to ship the features in stable releases, people are just going to use unstable releases and that will make the experience worse for everyone. There is no way to artificially restrict features unless you have multiple software in the ecosystem that needs time to update: for C it is the other compilers following the C standard, for Python it is the Python executable on your end- user's machine. The minute rustc updates, Rust developers have little reason not to use the features.
- estebank 4y ago
  > This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers. How is this a problem? The crate authors targeting nightly features know full well that they are restricting their pool of users, while at the same time driving the testing and design of nightly features forward. If no one is actually using them, then they are unlikely to get quickly stabilized. > If the Rust team refuses to ship the features in stable releases Can you show a case of refusal to ship a needed feature? > Rust developers have little reason not to use the features. Rust developers of end user applications don't. Crate authors do, if they want to gain wide adoption.
  - remram 4y ago
    I feel like you read my entire comment wrong. Like you didn't read what I replied to, stripped all the "ifs" and arguments, and hyper-focused on points I wasn't trying to make. Surely I wasn't as clear as I thought but this feels so strange.

dralley 4y ago

A lot of the "features" - most of them even - being added to Rust nowadays are just filling holes in the language. Things you might easily assume you could do that for arbitrary implementation reasons, you cannot. A lot of them are basically "fixing and improving the language" IMO. In addition, frequent releases do a better job of incentivizing taking the time to get the design right, because the consequence of missing a release window is that it gets delayed a few weeks, or maybe a few months, instead of a few years. You can totally see this happen with C++ for example.

avgcorrection 4y ago

With language editions, the new features that Rust adds will be mostly a liability for the compiler writers, not the users. So sure you could ask that: why are the language implementors creating more maintenance work for themselves? Well maybe they think those features are worth it.

notriddle 4y ago
This isn't really true. If you ever need to debug code in a dependency, then you'll probably need to read code that targets a different edition than your home project does. Over a long enough time frame, you're going to need to at least be able to understand all of the editions.
- avgcorrection 4y ago
  Sure. In that sense.

smitty1e 4y ago

There seems to be a bit of an arms race between some of the languages. The difference between "New Hotness" and "Feature-itis" is subjective, but I do enjoy the new python featues immensely.

jjtheblunt 4y ago

> not that C is the best language out there I've heard a professor say "C is the best assembler out there" ... felt insightful

deleted 4y ago
[deleted]

phkahler 4y ago

C++ gets new features regularly because there is a comitte whose job is to do that. The same was true of OpenGL until they moved on to Vulcan, and they seem to be getting the idea that things dont really have to change so much. Or maybe they're just shifting to making other "standards" instead. To me Rust is more of a toolchain development at this point, where language features are added where it makes sense rather than being a goal.

stusmall 4y ago

> C on the other hand is great. What you wrote in 1990 still is understandable today? That's a weird example. In my career I've noticed big stylistic changes over the years in C. I can usually point out C code from the 90s right away. Usually it just has dated style or is missing what are now common libraries or features. C didn't have a standard bool type until C99 which is usually a good sign of code's age. I remember once I came across some mid-90s code written with the pre-ANSI style of function declarations. It was the first time I'd ever seen it and I was confused on how it even compiled. Outside stylistic things, there are a few idioms and features that I've never seen in newer code bases that might be lost on some newer developers. I can't think of many times I've seen longjump used in modern C.

valbaca 4y ago

> Strange. EcmaScript/JavaScript kind of adds like 5-6 features every year. Python. C on the other hand is great. Those languages have also been around long enough for the new language features to "cool down". Rust was also designed from the beginning to have the language be able to move quickly and safely in this manner (just like Rust code itself!). You're also forgetting the HUGE migration pains that resulted from JS. The gigantic gaps between ES3 and ES5 and ES6. Oh, did I forget ES4? Nope. It was cancelled. Not even going to get started on the disaster that was Python 2->3 or how wildly different the original K&R C is to modern C (I have the K&R book handy to prove it). I honestly find it hilarious that those languages you chose each had terrible migrations between versions, where Rust differences between versions barely make a dev bat an eye.