5 ms·

C has also been relatively stable for the last 25 years or so. Rust changes every 6 weeks. Yes, the language is supposedly not undergoing breaking changes with

C has also been relatively stable for the last 25 years or so. Rust changes every 6 weeks. Yes, the language is supposedly not undergoing breaking changes without strict deprecation and feature-gating. However, as new features are added to the language, libraries are usually updated to leverage them, and suddenly you are also forced to keep up with that rapid release cadence to ensure your project still builds. Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates. Don't get me wrong. I like Rust and what the project is trying to do. But I see two major problems that are preventing me from using it for anything major at the moment: 1) the extremely rapid rate of change, and 2) difficulty of implementation (both of which, taken together, lead me to expect no serious alternative implementations any time soon). Before I will be willing to adopt Rust as a C replacement in full, there needs to be a solid, stable language definition that compiler writers can target and programmers can rely on for a good chunk of time. I have a feeling we'll get there eventually once the number of new, useful features that are missing from the language starts to dwindle and it begins to stabilize naturally. In the meantime, I'd settle for an "LTS" release or something. That could work.

steveklabnik 10y ago
There's at least two alternate compilers I know of in the works. We'll see when they're in a workable state, or at least, enough to compile rustc. > In the meantime, I'd settle for an "LTS" release or something. That could work. This is something we've discussed. I imagine it will happen. At first, I would expect six month LTSes, then longer ones as time goes on.
- groovy2shoes 10y ago
  I could definitely live with such a solution, but even six months might be too quick. So, as long as the plan is to lengthen the LTS window, I think that could work. The company that employs me just upgraded to a C++11-capable version of GCC three months ago. Even C++'s three year cadence seems like it might be too fast! Thing is, the company wants to vet our entire platform, which itself only changes yearly. They want to know they can get bug fixes, and vetting/upgrading the compiler is a lot of work regardless, so they tend to do one and stick with it for a while. OpenBSD does the same thing for security reasons. If Rust wants to replace C and/or C++, these are things that will need consideration eventually. I don't see my company allowing Rust any time soon, unfortunately. As a compiler-writer, I'm more concerned that Rust is a quickly-moving target at the moment. I think that as Rust becomes more mature, it will naturally begin to stabilize feature-wise, in which case something akin to the Haskell model would work well, with innovation happening in the flagship compiler and "snapshots" of the language being taken as standards periodically. That's just a matter of time, though.
  - blub 10y ago
    Completely agree, C++'s three year cadence is probably the fastest more conservative industries are willing to go. And why should one invest time for such a low-level component in their toolkit every 6 months?! I want to build software and solve problems, not spend my time keeping up with programming languages and library updates.
    - tatterdemalion 10y ago
      I have upgraded Rust every six weeks. I run `rustup update stable` and wait a minute. Its not a time investment! Rust puts so much work into guaranteeing backwards compatibility so that updating every 6 weeks is an effortless process. You seem to come from an experience where software updates are kinda sorta mostly backwards compatible. Rust works very hard to actually be backwards compatible. There is infrastructure to check for regressions across the entire package ecosystem, which is run regularly on HEAD and on any commit we think might potentially be breaking before we even land it.
tatterdemalion 10y ago
I don't understand. Rust 1.0 code will compile on Rust 1.14, in the same way that C code from the 80s will compile on modern C compilers. That's what "backwards compatible" means! Your dependencies don't upgrade themselves. Its true that if you upgrade your dependencies, they may depend on a more recent verison of rustc, in which case you need to upgrade rustc as a part of upgrading that dependency. But if you are using rustup this is not harder than upgrading those dependencies - probably easier in fact. In exchange for downloading a tarball at most every six weeks, you get a language that is developing new features.
naasking 10y ago
> Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates. You say that like it's a good thing that with C, you can ignore 30 years of progress in software development. Colour me unconvinced.
- grzm 10y ago
  If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing. At the end of the day, it's what the software does that's important.
  - naasking 10y ago
    > If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing That's not a responsible metric. 30 year old software was written against 30 year old APIs vulnerable to known attack vectors, and with 30 year old notions about security. The belief that this software is suitable for modern use is absurd IMO. And if the types of programs you're talking about are small UNIX-like utilities, well then they're small and easily updated aren't they?
    - grzm 10y ago
      If the software does what you want includes all of those criteria. If you find that there are deficiencies in any of those areas, that would qualify as a reason to make changes, weighed against the cost of doing so.
      - naasking 10y ago
        > If the software does what you want includes all of those criteria. Except most people don't consider those as criteria at all. The only criteria considered are "does it run and produce the output I want".
    - groovy2shoes 10y ago
mmstick 10y ago
The problem with your concept is that C does not offer an official standard library and compiler suite, so you're trying to compare the C spec to the Rust standard library + compiler. The actual Rust API has changed very little since the 1.0 release. All the changes that have occurred have been mere additions to the language -- nothing breaking. Hence why the 1.0 release was termed as a 1.0 release. There won't be anything happening that causes breakage until a 2.0 release. You'll find that C compiler and library development is also rapid like Rust. There's new versions of LLVM/Clang and GCC being released on a regular basis. There are constant updates to musl and glibc. These changes tend to break far more often than Rust, which is developed in Rust and can be guaranteed to be much safer. That Rust is being openly developed on GitHub with a significant number of developers, with an official compiler + library + doc + comprehensive suite of resources collectively being maintained, that's a significant incentive to work with Rust. There's a solid RFC process to prevent anything silly from entering the language. No random decisions by random people -- it takes a lot of convincing to add a new feature to Rust.
- groovy2shoes 10y ago
  C does have a standard library. It's described in full in the ANSI/ISO/IEC standard for the C programming language, and it's on your system, likely called libc or something along those lines. Anyway, I don't think that's a problem with my concept at all. What I want for Rust, and what I think will eventually be feasible for Rust as the language matures, is a standard that can be shared by compiler writers and Rust programmers. A standard is worthless if it's inadequate (see ISO Pascal or ISO Basic, for example), so it's a good thing that right now Rust is iterating quickly and improving rapidly. But eventually, there's going to need to be a stationary target for compiler writers to aim for, and for Rust programmers to be confident that the code they write today won't be littered with deprecated features, anti-patterns, and worst practices tomorrow. Frankly, I don't see wide adoption happening in the corporate world until there's an LTS compiler at the very least.
  - blub 10y ago
    When Rust (or Swift or golang) gets ISO standardized we'll know that it's mature and left the "move fast and break things" phase. This won't happen, because it's still growing now, so it doesn't make sense to standardize. They might even always want to be able to move fast. I don't see golang ever being standardized. The fact that someone says on HN "we're backwards compatible" doesn't quite offer the same level of trust as an ISO standard. Especially when there are some conflicting reports out there i.e. there are many super-awesome libraries that only work with nightly (I think it's called), because many of those maintainers are early adopters that love to try out new features. Programming languages and libraries are building blocks, I don't want them to change under me in the middle of a project. This is why I dropped Swift, the 1.0 -> 2.0 migration was a very painful, and from what I hear recent major version changes aren't running smooth either.
erikpukinskis 10y ago
This is my same problem with JavaScript. Yes it's wonderful that changes are backwards compatible. But if the entire community is updating libraries you rely on to use new language features then you have no choice but to use those features too. Or stop using other peoples' code and just use core language features and build everything from scratch. Which is what I end up doing, and it has some benefits. But it definitely slows you down.

steveklabnik 10y ago

There's at least two alternate compilers I know of in the works. We'll see when they're in a workable state, or at least, enough to compile rustc. > In the meantime, I'd settle for an "LTS" release or something. That could work. This is something we've discussed. I imagine it will happen. At first, I would expect six month LTSes, then longer ones as time goes on.

groovy2shoes 10y ago
I could definitely live with such a solution, but even six months might be too quick. So, as long as the plan is to lengthen the LTS window, I think that could work. The company that employs me just upgraded to a C++11-capable version of GCC three months ago. Even C++'s three year cadence seems like it might be too fast! Thing is, the company wants to vet our entire platform, which itself only changes yearly. They want to know they can get bug fixes, and vetting/upgrading the compiler is a lot of work regardless, so they tend to do one and stick with it for a while. OpenBSD does the same thing for security reasons. If Rust wants to replace C and/or C++, these are things that will need consideration eventually. I don't see my company allowing Rust any time soon, unfortunately. As a compiler-writer, I'm more concerned that Rust is a quickly-moving target at the moment. I think that as Rust becomes more mature, it will naturally begin to stabilize feature-wise, in which case something akin to the Haskell model would work well, with innovation happening in the flagship compiler and "snapshots" of the language being taken as standards periodically. That's just a matter of time, though.
- blub 10y ago
  Completely agree, C++'s three year cadence is probably the fastest more conservative industries are willing to go. And why should one invest time for such a low-level component in their toolkit every 6 months?! I want to build software and solve problems, not spend my time keeping up with programming languages and library updates.
  - tatterdemalion 10y ago
    I have upgraded Rust every six weeks. I run `rustup update stable` and wait a minute. Its not a time investment! Rust puts so much work into guaranteeing backwards compatibility so that updating every 6 weeks is an effortless process. You seem to come from an experience where software updates are kinda sorta mostly backwards compatible. Rust works very hard to actually be backwards compatible. There is infrastructure to check for regressions across the entire package ecosystem, which is run regularly on HEAD and on any commit we think might potentially be breaking before we even land it.

tatterdemalion 10y ago

I don't understand. Rust 1.0 code will compile on Rust 1.14, in the same way that C code from the 80s will compile on modern C compilers. That's what "backwards compatible" means! Your dependencies don't upgrade themselves. Its true that if you upgrade your dependencies, they may depend on a more recent verison of rustc, in which case you need to upgrade rustc as a part of upgrading that dependency. But if you are using rustup this is not harder than upgrading those dependencies - probably easier in fact. In exchange for downloading a tarball at most every six weeks, you get a language that is developing new features.

naasking 10y ago

> Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates. You say that like it's a good thing that with C, you can ignore 30 years of progress in software development. Colour me unconvinced.

grzm 10y ago
If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing. At the end of the day, it's what the software does that's important.
- naasking 10y ago
  > If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing That's not a responsible metric. 30 year old software was written against 30 year old APIs vulnerable to known attack vectors, and with 30 year old notions about security. The belief that this software is suitable for modern use is absurd IMO. And if the types of programs you're talking about are small UNIX-like utilities, well then they're small and easily updated aren't they?
  - grzm 10y ago
    If the software does what you want includes all of those criteria. If you find that there are deficiencies in any of those areas, that would qualify as a reason to make changes, weighed against the cost of doing so.
    - naasking 10y ago
      > If the software does what you want includes all of those criteria. Except most people don't consider those as criteria at all. The only criteria considered are "does it run and produce the output I want".
  - groovy2shoes 10y ago

mmstick 10y ago

The problem with your concept is that C does not offer an official standard library and compiler suite, so you're trying to compare the C spec to the Rust standard library + compiler. The actual Rust API has changed very little since the 1.0 release. All the changes that have occurred have been mere additions to the language -- nothing breaking. Hence why the 1.0 release was termed as a 1.0 release. There won't be anything happening that causes breakage until a 2.0 release. You'll find that C compiler and library development is also rapid like Rust. There's new versions of LLVM/Clang and GCC being released on a regular basis. There are constant updates to musl and glibc. These changes tend to break far more often than Rust, which is developed in Rust and can be guaranteed to be much safer. That Rust is being openly developed on GitHub with a significant number of developers, with an official compiler + library + doc + comprehensive suite of resources collectively being maintained, that's a significant incentive to work with Rust. There's a solid RFC process to prevent anything silly from entering the language. No random decisions by random people -- it takes a lot of convincing to add a new feature to Rust.

groovy2shoes 10y ago
C does have a standard library. It's described in full in the ANSI/ISO/IEC standard for the C programming language, and it's on your system, likely called libc or something along those lines. Anyway, I don't think that's a problem with my concept at all. What I want for Rust, and what I think will eventually be feasible for Rust as the language matures, is a standard that can be shared by compiler writers and Rust programmers. A standard is worthless if it's inadequate (see ISO Pascal or ISO Basic, for example), so it's a good thing that right now Rust is iterating quickly and improving rapidly. But eventually, there's going to need to be a stationary target for compiler writers to aim for, and for Rust programmers to be confident that the code they write today won't be littered with deprecated features, anti-patterns, and worst practices tomorrow. Frankly, I don't see wide adoption happening in the corporate world until there's an LTS compiler at the very least.
- blub 10y ago
  When Rust (or Swift or golang) gets ISO standardized we'll know that it's mature and left the "move fast and break things" phase. This won't happen, because it's still growing now, so it doesn't make sense to standardize. They might even always want to be able to move fast. I don't see golang ever being standardized. The fact that someone says on HN "we're backwards compatible" doesn't quite offer the same level of trust as an ISO standard. Especially when there are some conflicting reports out there i.e. there are many super-awesome libraries that only work with nightly (I think it's called), because many of those maintainers are early adopters that love to try out new features. Programming languages and libraries are building blocks, I don't want them to change under me in the middle of a project. This is why I dropped Swift, the 1.0 -> 2.0 migration was a very painful, and from what I hear recent major version changes aren't running smooth either.

erikpukinskis 10y ago

This is my same problem with JavaScript. Yes it's wonderful that changes are backwards compatible. But if the entire community is updating libraries you rely on to use new language features then you have no choice but to use those features too. Or stop using other peoples' code and just use core language features and build everything from scratch. Which is what I end up doing, and it has some benefits. But it definitely slows you down.