That's right, "the Future". Because as of right now the vast majority of devs using Rust are the type that use $latest features and Rust adds $latest features at a blinding rate compared to established languages. This makes forwards compatibility so bad that Debian 11, which isn't even released yet and has rustc 1.48, is already out of date and unable to compile most rust programs written for the rust spec just 3 months later.
It's not that Rust is bad, it's great. But right now the dev culture is all about $latest and there aren't many Rust devs that care if you can compile and run it on your 2 year old distro. This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date.
> Debian 11, which isn't even released yet and has rustc 1.48, is already out of date and unable to compile most rust programs written for the rust spec just 3 months later.
This comes up with Java as well. Lots of distros ship with "java X" and ignore the version march. Ultimately you end up going around package management if you want to stay up to date.
I'm not sure the best way to fix this. A lot of distros want to treat everything like they treat GCC and C++. C++ which releases new versions every 3 years or so which means that having a version of GCC 1 or 2 years out of date doesn't generally matter.
> the vast majority of devs using Rust are the type that use $latest features and Rust adds $latest features at a blinding rate compared to established languages.
A major complaint I have about rust devs is so many libs require nightly rust. That, IMO, is inexcusable. Sure, it's ok to try out those features, but why are you publishing libraries that REQUIRE those features to work? That seems like just a generally bad idea.
> This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date.
With browser and Java that's already the case so I don't see this as an issue with rust. I'm not sure the best way to solve this, but I hardly think it's a rust issue so much as it's a problem with how dependency management works today.
Not sure about others but those are the two I think of. It's usually something that comes up when I start playing with rust and want to do X. Last few times I've done that the nightly requirement hits.
Rocket publishes a library that requires nightly features to work because the alternative is not publishing the library that requires nightly features to work. I'm not sure what you think you're losing by the library existing on crates.io, but there really isn't a way of doing what rocket does without nightly. If there were, Rocket would be doing it (and stabilization for its features is fast approaching).
I get the distinct impression that the existing Linux package management ecosystem has evolved so thoroughly around C/C++'s complete lack of sane build tooling or package management, and it's ironically difficult for some reason to embrace languages like Go or Rust which make package management trivial. I don't know if it's a tooling issue or what, but this seems to be a common problem. I'd be really interested in opinions from people who know more about Linux package management from the maintainer side.
I think Linus really hits the nail on the head here. It's the fact that core libs, like glibc, are CONSTANTLY changing their ABI making it damn near impossible to ship a binary from one version of the platform to the next https://www.youtube.com/watch?v=Pzl1B7nB9Kc .
You can still run windows 95 apps in windows 10. But running a ubuntu 12.04 binary in ubuntu 21.04? No way.
It is so hilariously bad that Linux has an easier time running Windows applications than it does Linux applications from an older (or newer, or sideways) distro. It's been like this for decades, it has been complained about for decades, but there seems to be very little desire to fix it.
glibc is perfectly backwards compatible.
We still build software on Debian 7 (glibc 2.13 from 2011) and the binaries works just fine on Debian 11 (and also on most other glibc-based distributions). But you need to be careful to only use libraries that provide long-term binary compatibility. Most libraries you can find in the system package manager don't do this.
Also, on Linux it's weirdly difficult to do it the other way around: use the current distribution to build binaries that also run on older distributions.
On Windows this is trivial: I can develop on Windows 10, with the current VS2019 and the current Windows 10 SDK, and a simple "#define _WIN32_WINNT 0x600" is sufficient to make my binary work all the way to Windows Vista (2006).
On Windows it's normal to ship libraries in the application directory instead of depending on a global /usr/lib/ installation; so non-Microsoft libraries that don't maintain a stable ABI are much less problematic.
Also, good luck if you're on Linux and want to use an up-to-date gcc (e.g. gcc-8 for C++17 support) on an older distribution. Building gcc from source is easy, but the resulting gcc-8 will produce binaries that require symbols from libgcc-8, which the system libgcc won't have.
We actually ended up patching gcc to disable the optimizations that introduce uses of new symbols not yet present in deb7 libgcc.
This is a common misconception. LTS versions of Java are strictly a JDK vendor thing. There is no "LTS" for openjdk.
So, while Oracle, AdoptOpenJDK, Azul, and other might have LTS releases of their JDKs, you get no support from the OpenJDK source. That means, Linux Distros would be in charge of backporting security fixes/support for their distributions of the JDK if they want LTS.
Rust 1.48 was released in November 2020. Rust 1.49 was released six weeks later. Rust is backwards compatible but not forward compatible, so programs that use features released in 1.49 would not compile with 1.48.
It isn't about the language, although Rust being new and adding new features makes it worse. It is about the developer culture.
So, do I know a language with a developer culture that is forwards compatible? Yes. Bash. It regularly gets new features added (surprising, I know). But Bash devs know that their users won't always have the bleeding edge and don't use $latest stuff as soon as it's released.
Right, and add on top of this the hubris has towards the topic of an official specification. Simply asking the question if one is being considered or worked on gets you scoffed at, as if you were some unenlightened simpleton. "Look at all of these other languages without one!" they remark. How does this help the discourse?
I think what describes rust perfectly to me, at least at this time, is the red box here https://doc.rust-lang.org/reference/ -- something that no matter how many times undergoes a release, still feels incomplete.
And for the record, I am someone very interested in using rust at work. Just can't until it stops feeling like an experiment.
I am sorry you’ve had that experience. The position of the project has been “we would like one, but we want to do one right, and that will take time.” Millions of Euros and years of work have been poured into this. It is something we care about.
I think you can measure what a project cares about by the priorities they give to different pieces of work.
Empirically, since 1.0 the project as a whole has prioritised adding new features over documenting (and agreeing the intended behaviour of) existing ones.
In early 2019, the roadmap said the language team would make updating the reference a priority that year. But as far as I can tell nothing happened, and it hasn't appeared on the roadmap since then.
Yes, as it turns out, open source projects cannot dictate what people work on to the same degree as companies, and there are far more people willing to do non-spec work. Those efforts aren't fungible though; progress has been made on both fronts, the spec work is just far less visible.
I wouldn't hold your breath, but I appreciate it. :)
It's kind of funny given that often Rust is thought of as changing too much, but when it comes to some things, we often take a very, very, very long time because we want to get them right. The spec is like, the largest example of this.
I agree as well, but Rust first appeared some time in 2010. To contrast it with another popular language that rust is ironically pitted against for some reason, Go, which was released in November 2009, managed to be released with a formal specification that they validate against multiple implementations (thanks to Ian Lance Taylor, primarily), and a 1.0 compatibility promise.
Having to be stuck on an OS-version of a language should be an old-fashioned issue. Rust, PHP, NodeJS, are a few of the languages I never use from the OS repos, exactly because they are always behind.
> This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date.
I don't see the problem. This seems like further evidence that distro package managers aren't the way forward. They can't keep up, they rarely have a sufficiently broad or up-to-date collection of packages, and when you integrate third party channels it can break other software ("run 'apt-get -f' to fix your dependencies" has never ever worked for me). Generally language-specific package managers work just fine.
That really has nothing to do with language-specific versus distro packaging. If you replaced a bunch of rust crates with random modified builds from a third party, you would probably see the same types of breakage.
> If you replaced a bunch of rust crates with random modified builds from a third party, you would probably see the same types of breakage.
I wouldn't need to do that in Rust because Rust programs are typically statically compiled. If I install some third-party program, it doesn't break a bunch of software that I installed via `cargo install`, nor does it prevent me from `cargo install`ing new packages (whether or not I can install a given package doesn't depend on the state of the packages that are already installed on my system).
Maybe the real reason that distro package managers are unpleasant is that they opt to dynamically link everything by default?
> This seems like further evidence that distro package managers aren't the way forward
On the contrary, distributions are here to stay and they are growing their adoption on many platforms including hi-end "IoT" and cars.
No sensible organization runs bleeding edge OSes on their airplanes, power plants, payment processors, industrial plants and so on...
This also applies to not pulling random packages from random github repos using some language-specific package manager hoping they don't contain backdoors.
Case in point: the CIP project https://www.cip-project.org/ aims to backport security fixes to Linux for 25 years after each CIP-approved release. This is because people expect to run the same kernel/OS for 30+ years.
Seems like you misunderstood me. I said distro package managers, not distros. You even quoted me...
> No sensible organization runs bleeding edge OSes on their airplanes, power plants, payment processors, industrial plants and so on...
Most organizations don't run all of those things, and you don't need a bleeding edge distro to install up-to-date software.
> This also applies to not pulling random packages from random github repos using some language-specific package manager hoping they don't contain backdoors.
The obvious false dichotomy being that you either have to pull ancient software from a distro package repo or you depend on random packages. As though it's impossible to install vetted software with a language package manager.
> This is because people expect to run the same kernel/OS for 30+ years.
Right, but we're not talking about kernels, we're talking about the packages in repos.
I would not consider the contents of crates.io to be “vetted software”. If the burden is on the developer to carefully evaluate literally hundreds of dependencies, which may each be written in their own package-specific micro language of macros and present in several versions, then I think that’s a pretty substantial cost to bear. More likely, that expensive, unglamorous work will be papered over and ignored.
25 years is nothing. Auto parts dealers stock parts for cars that are more than 40 years old. Not even special order, the parts are on the shelf. Kernels should have support lifetimes of hundreds of years. (not every one, but some of them)
I love the convenience package managers provide, but I have to agree that they often include terribly out-of-date packages e.g. for Clang, LaTeX, Rust, so serious users often need to resort to using other sources or special package repositories (and these are often down, discontinued etc).
This is in no way meant to diminish package managers or maintainers, which have brought great positive change to Linux. Just saying there is still a lot of work ahead, too.
Are you talking about an actual issue you faced or are you complaining about something that might have happened hypothetically? Was there some dependency of your code that changed its minimum supported rust version (MSRV) to 1.51?
What puzzles me is whether this affects people at all. Let’s say a developer depends on crate foo, version 0.6, MSRV 1.39. Their Cargo.lock file specifies that they depend on version 0.6. Their code will now compile correctly and continue to do so between now and the heat death of the universe.
Of course it’s possible that they want to keep manually upgrading their version of foo to the latest and greatest. They have the option of doing so. But here’s what puzzles me - they seem to be very conservative with upgrading their compiler but carefree about upgrading dependencies. Why not stay on the foo version that was working well? Who is this hypothetical developer who is desperate to upgrade their dep and equally desperate not to run a single command to upgrade their compiler?
More broadly, I find it surprising that package managers have no trouble keeping up with the release cycles of Firefox and Chromium (6 week releases) but can’t keep up with Rust.
About three years ago, it really was that bad. Now, the language is reasonably stable. There's far less that "only works in nightly".
Crates, though, still show quite a bit of churn.
Recently I ran into an effort to make all types fit the Rust capitalization form. Like changing "DNS" to "Dns", breaking various things along the way.
Also, the Cargo and crate system encourages version pinning to the minor version level, which can lead to the modern equivalent of DLL hell. Many important crates are still at the 0.x.x level, which, if you take semantic versioning seriously, means no guarantee that the API will not change if the minor version does.
I have some theoretical arguments about the language, but overall, Rust is way ahead of anything else in this space. I didn't think you could push the ownership model this hard and still have a usable language. But you can. I'm 30,000 lines into a project and have not had to write "unsafe" once.
> All of this means that dealing with Rust is going to become increasingly necessary for me and a lot of people. We may not write it, but we need to be able to deal with programs that use it and are written in it.
I hadn't thought about this, but Rust seems like it's going to become truly inescapable. You can write both high and low level code in Rust, and because of that it's finding its way into every nook and cranny of our industry.
I already see it in server/CRUD stuff. CLI tools. And it's almost viable as a frontend language via WASM...
You're going to bump into it at some point in your career.
Meh, the future is higher and higher abstraction layers and higher level business logic with more and more details managed for you by the runtime. If you thought managed memory was good, wait until languages start managing access control, authentication, concurrency and persistence layers for you. The language that boosts productivity for 90% of use cases is going to win over the language that gives you more fine grained control to allow you to handle the remaining 10%.
In that sense, Rust is a good evolution of C down this path, but it remains a systems language, which is an ever-shrinking percentage of the software ecosystem, even if Rust itself is growing as more C programmers try to switch over to a language with more high level features.
> If you thought managed memory was good, wait until languages start managing access control, authentication, concurrency and persistence layers for you.
I heard that pre-Unix mainframe operating systems had a baked-in database rather than a filesystem, Lisp/Smalltalk had persistent images, etc. So I don't know if these abstractions are new, or just going mainstream. Capability-based security systems have been written about in academia for decades (according to https://en.wikipedia.org/wiki/Capability-based_security#Refe...).
> The language that boosts productivity for 90% of use cases is going to win over the language that gives you more fine grained control to allow you to handle the remaining 10%.
Actually no. The most important qualities for a language to quickly gain popularity are:
* Low barrier to entry
* Who is backing it (Go, Java, C#)
* What platforms it opens up (Swift,ObjC,Kotlin/Java) that require that language.
Rust has #3 going for it? Which major platforms are Rust-native or Rust-first, as with Java/Kotlin on Android, Javascript on the Web, ObjC/Swift on iOS, et c.?
Opening native development to a big number of people who would have otherwise never touched it.
This may not be obvious at first, but AFAIK the majority of Rust users come from web languages (mostly JavaScript, Ruby and Python) and the fraction of programmers doing native/low-level stuff had been declining for decades and Rust is bringing a lot of new people to it.
(Also webassembly, but it's a much smaller niche at the moment)
I took rapsey's item #3 to mean that languages tend to grow well when they're required—or at the very least considered the first-class option—for accessing a desirable ecosystem or platform, which does seem to be one major way language adoption grows. Not just that they let developers do things they maybe weren't before (but could have been, in another language).
Yes, I think it's literally what was meant in the original comment, but I've given it a slightly broader definition because I think this aspect is a huge factor in Rust's popularity.
Rust can be "native" on any platform that supports C/C++, provided only that the necessary pieces on the LLVM side are in place. There are even folks who will help you deploy Rust on console hardware where no publicly-available support can ever exist because the official C/C++ API's are kept secret and only made available to those who sign highly-restrictive NDA's.
Right, it's portable, but that's not what 3 was about. It's about being required for first-class access to a desirable platform. It's why Objective-C gained strong, renewed interest when iPhone apps in that language were announced. It's why anyone cares about Javascript. It's why Kotlin adoption grew very fast when Google announced support for it on Android, or why Swift went from nothing to fairly high levels of use practically overnight. That kind of thing.
Python was popular way before machine learning went mainstream.
> 1 is the most important.
1. is super important, but keep in mind that Python having a much higher barrier to entry than PHP on the web didn't stop it from becoming popular in that field.
Also 1. is really context dependent, and even if Rust has a bigger barrier to entry than Python, it has a much smaller one that its direct competitors (C and C++) because of its documentation, learning material, compiler error messages and dependency management.
Regarding 2. you must have missed the news: Rust is now officially pushed by Microsoft, AWS, Google and Facebook. In fact you'd have difficulties to find languages with stronger corporate backing than Rust today apart from C# and Java.
It's never winner takes all. There is space enough for a whole lot of languages. Keep in mind in the early days of Python it was pushed by Google. They specifically looked and advertised for python developers. That is more of a push than any company ever did for Rust.
Rust barrier to entry compared to C/C++ is debatable. Lots of universities for instance have courses in them. They have a whole lot of books and a large community out there.
I disagree about 2 and Rust. Those companies have projects in them and they are a part of rust foundation. They are however not mass employing Rust developers and only AWS has components for core stuff in Rust. Of course it is debatable for what is a core component.
> Keep in mind in the early days of Python it was pushed by Google.
You know Python is older than Google by several years right? ;) When this happened, Python was older than Rust today.
> That is more of a push than any company ever did for Rust.
Microsoft recently made Rust a officially language for developing Windows Native apps[1] and they've advertised the use of the language quite a bit during the past year. Google just released its new operating system developed with as much Rust as C and C++ combined[2]. Also, Facebook and AWS have hired members of the Rust development team after Mozilla's layoff last year to continue their work on Rust.
Sure, but what abstractions? If you look at flattening cpu speeds, we're in a period (probably not forever tho) in which advances in computing will happen at the software level, which raises the priority of concurrency and runtime efficiency. It's those primitives that Rust's abstractions model well. In addition, software has become weaponized and nobody can trust anyone, and Rust's emphasis on safety and security meets that need as well.
> If you thought managed memory was good, wait until languages start managing access control, authentication, concurrency and persistence layers for you.
Rust has a niche, and it is a big one, where a lot of C++ used to be. If you cannot afford GC pauses (all sorts of servers) and need fine control, rust could very well be for you. It will win in that space.
System programming is not a "ever-shrinking percentage of the software ecosystem". It is a constant percentage. As we develop systems we need languages like Rust.
> Meh, the future is higher and higher abstraction layers and higher level business logic with more and more details managed for you by the runtime.
Historically this doesn't seem entirely true. We haven't gotten much higher level than Java, outside of non-eng niches where we haven't gotten much higher level than Python (which is arguably lower level than R, which has been unseated).
So I don't think it holds true that we'll continue to chase a higher abstraction layer. We recognize the cost of doing so, and it hasn't been worth paying so far.
Besides that, Rust is quite capable of providing high level abstractions. I myself am building a sandboxing mechanism in Rust that will be entirely managed for you but with no runtime cost (it's generated statically) - it is Rust's low level power that lets me build such high level abstractions.
In special because the way rust do things now is THE optimal way to work:
Rust is GROWING.
In this step (let's call it the adolescent) is NOT THE TIME to stop for the needs of C, C++, Debian, or anything else that is glacially slow to change, generate BILLONS of losses in this industry, and is arcane as hell...
In fact, I wish it not be that conservative moving forward.
But where is genius all of this? Is that despite the forward momentum it NOT fell "broken by design" at all. Is one of the few tools in my +20 years on the trade that I can update with confidence and that actually NOT DEMAND to change all my code as often as it look like.
So this is the real experience with Rust: All stuff is very carefully considered as much as possible, not major big mistakes, cargo si GOOD!, and because that, update is painless, and still: You don't need to refactor code in each update, you get benefits without major costs (more performance! better internals!), and still can profit for the work of everyone in the community.
P.D: Rust is certainly made with CI-oriented deployment as the preferred way to work. If wanna move forward glacially, I don't see how is that impossible. In fact I bet you can stop updating, wait 2-3 years, do a big refactoring and move along. This is how ACTUALLY was in the past with tools like C# and others, and I pretty sure Rust will make that thing much easier to shallow...
I don't think Rust is the evolution of C. Its a nice thought, just like I like to think im the evolution of [famous well known person].
C++ was the evolution of C and so was Java, but they both turned out to be their own things and C kept on chugging. Rust is a big complicated language, there is nothing C like about it. I see more parallels between Rust and C++ than I do Rust and C.
Rust to me makes difficult things that are trivial in C. For example one thing that I don't like about Rust is the fact, that at least with the standard library, memory allocations are hidden in things like calling the constructor of a string. And what if a memory allocation fails?
What's the point of a memory safe language if your whole program could fail for a simple out of memory condition? With C I can allocate all the memory that I need upfront, as a static variable either global (yes, they are not the devil) or inside a single function. That way the compiler can tell me if my program will fit in memory or not.
And yes, I know that in Rust you can avoid using the standard library and you can manage the memory yourself in unsafe blocks. But... what's the point on fighting the language when you can just use C?
All the things that are said about C, it's unsafe, nowadays you have tooling, every decent compiler will warn you if you try to do stupid things.
> What's the point of a memory safe language if your whole program could fail for a simple out of memory condition?
The point is to be able to do more complex things more easily and performantly, while also not introducing trivial security vulnerabilities like buffer overflows.
> But... what's the point on fighting the language when you can just use C?
The point is to learn not to fight it. At that point, the language becomes much more effective to use than C.
Proper C, which is not full of holes and undefined behaviour, also feels like fighting in the beginning. Empirically, it is also a fight that is won much more rarely.
The Rust hype machine continues unabated. Silicon Valley is just as vulnerable to tech hype as the general public is to political hype. Indeed, Silicon Valley thrives on and depends on hype of all kinds. Hype is used to generate interest among venture capital firms and keep the cash flowing. The best example is Theranos, but there are many others. The Rust language may be as wonderful as its proponents claim. Regardless, I really wish they would shut up.
I'm gonna assume you've never learned it. A provably safe C replacement is pretty useful and its adoption could do away with a ton of common bugs and security vulnerabilities.
The Theranos comparison is asinine. Rust works, Theranos did not.
Dude. It's the internet. There's going to be a lot of people saying things that you don't like. What I'm trying to say is that your wish that people saying things you dont like would just "shut up" is probably not going to come true.
[Also, the article basically talks about how the person doesn't want to learn rust but doesn't think they have a choice not because rust is somehow "right" but because there are a lot of people who want to continue to use rust. This is about as far as you can get from a Rust Hype Machine as you can get without actually attacking the language.]
HN rules say we shouldn’t imply a person hasn’t read the article. But I’m finding it difficult to reason how a person could have read the article and then written that comment.
Some times something comes along that lives up to the hype.
I think Rust does that. It has taken thirty plus years of experience system programming and used it to create a masterpiece. A real triumph of design by committee.
Somewhat off-topic but I recently learned that people in the rust community call themselves rustaceans. I don't know the origin of that, but seems like a missed opportunity to call themselves rustlers: the old name for people who steal cattle, or rather - borrow cows :)
As I remember it, the name "rustacean" came first, and then Karen created Ferris in response. I could be wrong though, my memory is poor, and I don't have a citation either way.
One thing about this time was that some folks wanted "Rustafarian" but there were good arguments to not do that, and people moved away from it.
For Rust to become the go-to systems programming language, it has to beat C. But Rust lacks C's biggest advantage: portability.
Pretty much every architecture and OS out there has a C compiler. Rust only works well on the most mainstream systems: Linux, macOS, Windows; x86(_64), ARMv8. Building nontrivial Rust programs on the BSDs and other architectures is really difficult. Python recently broke the CI for many distros after depending on a Rust package for this reason.
There are three overlapping reasons for Rust's lack of portability:
1. Language complexity makes it hard to develop a new target or compiler.
2. Language development speed is high, so maintainers of other implementations need to keep up their pace.
3. The language is implementation-driven rather than spec-driven. rustc is the source of truth rather than a specification.
Developing and maintaining a new Rust target/compiler is a ton of work compared to doing the same for C, Go, or even D. The OpenBSD, Plan 9 (!!), and initial Windows targets for Go were all community efforts without Google funding.
Alternative platforms are less used partly because they lack some popular software. We don't need to make it harder than it already is to use them. As long as the aforementioned three issues exist, Rust won't (and shouldn't) be a C replacement.
I do see a place for Rust on the server, for performance-sensitive bits of software that's written mostly in higher-level langs. My side of the "keep other architectures alive" battle has pretty much lost there. Making alternatives to ubiquitous tools like grep (ripgrep) or sed (sd) is also fine, since these alternatives won't replace their predecessors. But I hope it doesn't become a de-facto for desktop/end-user software. PowerPC computers shouldn't become e-waste if they aren't broken, and switching to different architectures shouldn't be as big a deal as it currently is.
Rust developers seems to assume that the only compilation target is x86 or ARM with POSIX API or Windows, or less often whatever architecture is supported by LLVM. And the rest?
There are a ton of architectures that are not ARM, one example is the popular chip ESP32 that uses a proprietary architecture called Xtensa.
Another thing is ABI, even if something is ARM, it doesn't mean that its build process is straight forward and you can just compile with LLVM and it works. Try to integrate the SDK of some microcontrollers based on proprietary compilers like IAR, Keil, etc. It's not trivial. Possible in the end, if you want to rewrite all the linker scripts and make sure to build the executable file in the same way, just not practical.
Then there are 8 bit microcontrollers, and yes you can buy an ESP32 for a ridiculous price, but what if you need to do something low power?
C is universal. Nowadays you can assume that everything that has some sort of processor has a C compiler. With Rust is not like that, and probably never will, since the language is too complex to implement on low cost/low power hardware, and too high level for things that needs a low level access to the hardware.
Portability doesn't matter anymore. I don't know why C people press this issue so much. The world runs on x86 and ARM, with a smattering of PowerPC. Rust is already being used in embedded applications quite a bit in many companies as well.
The fact that C works on IBM System 360 doesn't help anyone.
(But, to be fair - s360 is quite dead at this point, and Rust supports s390x fine, even if not as a tier-1 platform. Anyone who claims that C compilers support every platform equally is a liar anyway, Rust just makes the support tiers explicit).
Sure they do, but those are places where new development is not happening, only sustaining. Rust wouldn't go into those places even if it did support those hardware.
Approximately nobody is using Plan 9 or Itanium. Apart from nerd cred, they don't matter for Rust's future.
People can keep using C for the weird DSPs that don't have 8-bit bytes. Besides, there's already a compile-to-C implementation of Rust (mrustc), and a GCC-based implementations in progress (both front-end and back-end).
OTOH Rust and its tooling are way better than the C ecosystem in supporting both Windows and Unix flavors in the same codebase, in a practical manner. C prides itself in theoretical support for obsolete and niche platforms, but requires a mess of ifdefs for basic things like opening a file with non-ASCII characters (and when C programs don't work on Windows, this is dismissed as Windows' problem, not C failing to actually have the standardization and portability it claims).
For a lot of programs "cargo build" just works out of the box on every Rust-supported platform. That's smoother than battling autotools, or cmake build scripts that can't find packages for inexplicable reasons, and random breakages due to C compilers/OSes having functions defined in slightly different headers, with their own quirks.
Rust is really good at abstracting these pains away, so while it can't support Plan 9, it can easily support Windows. Can you imagine opening a TCP socket without needing to know about winsock idiosyncrasies?
You seem really fixated on Plan 9. I merely used it as an example to show how even ultra-niche operating systems have support, demonstrating how adding a target need not be a monumental task.
Other operating systems like FreeBSD, NetBSD, Solaris, OpenBSD, and DragonflyBSD also exist. FreeBSD is quite relevant and NetBSD and OpenBSD fill almost-empty yet significant niches.
The big reason why Rust is getting hype is that it's hitting the niche of C++ but doesn't suck to integrate. Ever wonder why so many C++ "libraries" are "header-only"? Yeah.
Even if you declare your lib API 'extern "C"', when you call into C++ code you need a C++ runtime that is exactly what you compiled the C++ code with and it has to speak exceptions, templates, name-mangling, etc., exactly like the compiler you compiled that C++ library with. So, you always need the exact compiler to integrate C++.
With Rust, it's a library just like if you compiled it with a C compiler.
The fact that Rust fixes that long-standing C++ suckage, in my opinion, is THE killer feature that's making Rust "popular".
I think the hype has a lot more to do with paid content marketers. You may recognize a few from when Rails was the new shiny. If you look at surveys of actual usage, such as by Jetbrains or Stack Overflow, the number of actual Rust users is very small. Small enough that I’m skeptical of anyone who states that they have written anything other than side projects. Product names and businesses are usually omitted in testimonials here on HN. The activity on GitHub is also not growing with respect to other popular languages (and has not for years). C++ is actually growing modestly, if GitHut2.0 is to be believed.
That makes sense to me given the impressive features that have come to C++17 and 20.
108 comments
[ 0.19 ms ] story [ 171 ms ] threadIt's not that Rust is bad, it's great. But right now the dev culture is all about $latest and there aren't many Rust devs that care if you can compile and run it on your 2 year old distro. This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date.
This comes up with Java as well. Lots of distros ship with "java X" and ignore the version march. Ultimately you end up going around package management if you want to stay up to date.
I'm not sure the best way to fix this. A lot of distros want to treat everything like they treat GCC and C++. C++ which releases new versions every 3 years or so which means that having a version of GCC 1 or 2 years out of date doesn't generally matter.
> the vast majority of devs using Rust are the type that use $latest features and Rust adds $latest features at a blinding rate compared to established languages.
A major complaint I have about rust devs is so many libs require nightly rust. That, IMO, is inexcusable. Sure, it's ok to try out those features, but why are you publishing libraries that REQUIRE those features to work? That seems like just a generally bad idea.
> This is also why 99% of rust documentation starts with telling you to install rust-up from out of repo third party sources: your local repository rust, no matter how new, is already out of date.
With browser and Java that's already the case so I don't see this as an issue with rust. I'm not sure the best way to solve this, but I hardly think it's a rust issue so much as it's a problem with how dependency management works today.
Rocket still uses nightly https://rocket.rs/v0.4/guide/getting-started/
Not sure about others but those are the two I think of. It's usually something that comes up when I start playing with rust and want to do X. Last few times I've done that the nightly requirement hits.
(Rocket’s master branch doesn’t require nightly but they haven’t released yet, incidentally.)
[1] https://github.com/rust-lang/packed_simd/blob/master/rust-to...
[2] https://crates.io/crates/packed_simd_2/reverse_dependencies
You can still run windows 95 apps in windows 10. But running a ubuntu 12.04 binary in ubuntu 21.04? No way.
Also, on Linux it's weirdly difficult to do it the other way around: use the current distribution to build binaries that also run on older distributions. On Windows this is trivial: I can develop on Windows 10, with the current VS2019 and the current Windows 10 SDK, and a simple "#define _WIN32_WINNT 0x600" is sufficient to make my binary work all the way to Windows Vista (2006).
On Windows it's normal to ship libraries in the application directory instead of depending on a global /usr/lib/ installation; so non-Microsoft libraries that don't maintain a stable ABI are much less problematic.
Also, good luck if you're on Linux and want to use an up-to-date gcc (e.g. gcc-8 for C++17 support) on an older distribution. Building gcc from source is easy, but the resulting gcc-8 will produce binaries that require symbols from libgcc-8, which the system libgcc won't have. We actually ended up patching gcc to disable the optimizations that introduce uses of new symbols not yet present in deb7 libgcc.
So, while Oracle, AdoptOpenJDK, Azul, and other might have LTS releases of their JDKs, you get no support from the OpenJDK source. That means, Linux Distros would be in charge of backporting security fixes/support for their distributions of the JDK if they want LTS.
Why is that an issue? Several languages now have fast releases, including Java and golang at twice a year, and C# at once a year.
It's best practice to always use the latest version of the compiler.
It isn't. It is an issue only linux zealots care about. They are of course a vocal minority online as always.
What are you talking about?
(The current release is 1.52.1)
So, do I know a language with a developer culture that is forwards compatible? Yes. Bash. It regularly gets new features added (surprising, I know). But Bash devs know that their users won't always have the bleeding edge and don't use $latest stuff as soon as it's released.
Frankly, it's more that we have no idea which shell (nevermind the version) the code will run onto and keep on relying on old api and luck...
I think what describes rust perfectly to me, at least at this time, is the red box here https://doc.rust-lang.org/reference/ -- something that no matter how many times undergoes a release, still feels incomplete.
And for the record, I am someone very interested in using rust at work. Just can't until it stops feeling like an experiment.
Empirically, since 1.0 the project as a whole has prioritised adding new features over documenting (and agreeing the intended behaviour of) existing ones.
In early 2019, the roadmap said the language team would make updating the reference a priority that year. But as far as I can tell nothing happened, and it hasn't appeared on the roadmap since then.
"is important" != "the most important thing"
It's kind of funny given that often Rust is thought of as changing too much, but when it comes to some things, we often take a very, very, very long time because we want to get them right. The spec is like, the largest example of this.
But it cannot mature without a long period immature. It is the nature of reality.
I don't see the problem. This seems like further evidence that distro package managers aren't the way forward. They can't keep up, they rarely have a sufficiently broad or up-to-date collection of packages, and when you integrate third party channels it can break other software ("run 'apt-get -f' to fix your dependencies" has never ever worked for me). Generally language-specific package managers work just fine.
I wouldn't need to do that in Rust because Rust programs are typically statically compiled. If I install some third-party program, it doesn't break a bunch of software that I installed via `cargo install`, nor does it prevent me from `cargo install`ing new packages (whether or not I can install a given package doesn't depend on the state of the packages that are already installed on my system).
Maybe the real reason that distro package managers are unpleasant is that they opt to dynamically link everything by default?
This. Seriously if things weren't such a tangled mess. I could just do `apt install potato@v2.1` and life would just be so good and simple.
This is crucial for security. Otherwise backporting security fixes and/or rebuilding would become impossible.
On the contrary, distributions are here to stay and they are growing their adoption on many platforms including hi-end "IoT" and cars.
No sensible organization runs bleeding edge OSes on their airplanes, power plants, payment processors, industrial plants and so on...
This also applies to not pulling random packages from random github repos using some language-specific package manager hoping they don't contain backdoors.
Case in point: the CIP project https://www.cip-project.org/ aims to backport security fixes to Linux for 25 years after each CIP-approved release. This is because people expect to run the same kernel/OS for 30+ years.
Seems like you misunderstood me. I said distro package managers, not distros. You even quoted me...
> No sensible organization runs bleeding edge OSes on their airplanes, power plants, payment processors, industrial plants and so on...
Most organizations don't run all of those things, and you don't need a bleeding edge distro to install up-to-date software.
> This also applies to not pulling random packages from random github repos using some language-specific package manager hoping they don't contain backdoors.
The obvious false dichotomy being that you either have to pull ancient software from a distro package repo or you depend on random packages. As though it's impossible to install vetted software with a language package manager.
> This is because people expect to run the same kernel/OS for 30+ years.
Right, but we're not talking about kernels, we're talking about the packages in repos.
This is in no way meant to diminish package managers or maintainers, which have brought great positive change to Linux. Just saying there is still a lot of work ahead, too.
Rust is still very new.
As a Rust fan I want a Rust 2.0. Smaller, specified, and stable. But it is not, quite, time yet.
If you want a Rust that’s easier to learn - work is constantly happening to make that a reality.
It is what I desire.
https://without.boats/blog/notes-on-a-smaller-rust/
What puzzles me is whether this affects people at all. Let’s say a developer depends on crate foo, version 0.6, MSRV 1.39. Their Cargo.lock file specifies that they depend on version 0.6. Their code will now compile correctly and continue to do so between now and the heat death of the universe.
Of course it’s possible that they want to keep manually upgrading their version of foo to the latest and greatest. They have the option of doing so. But here’s what puzzles me - they seem to be very conservative with upgrading their compiler but carefree about upgrading dependencies. Why not stay on the foo version that was working well? Who is this hypothetical developer who is desperate to upgrade their dep and equally desperate not to run a single command to upgrade their compiler?
More broadly, I find it surprising that package managers have no trouble keeping up with the release cycles of Firefox and Chromium (6 week releases) but can’t keep up with Rust.
Also, the Cargo and crate system encourages version pinning to the minor version level, which can lead to the modern equivalent of DLL hell. Many important crates are still at the 0.x.x level, which, if you take semantic versioning seriously, means no guarantee that the API will not change if the minor version does.
I have some theoretical arguments about the language, but overall, Rust is way ahead of anything else in this space. I didn't think you could push the ownership model this hard and still have a usable language. But you can. I'm 30,000 lines into a project and have not had to write "unsafe" once.
Please don't repeat misinformation you only heard in a hacker news comment.
I hadn't thought about this, but Rust seems like it's going to become truly inescapable. You can write both high and low level code in Rust, and because of that it's finding its way into every nook and cranny of our industry.
I already see it in server/CRUD stuff. CLI tools. And it's almost viable as a frontend language via WASM...
You're going to bump into it at some point in your career.
Rust might well become a new lingua franca.
In that sense, Rust is a good evolution of C down this path, but it remains a systems language, which is an ever-shrinking percentage of the software ecosystem, even if Rust itself is growing as more C programmers try to switch over to a language with more high level features.
I heard that pre-Unix mainframe operating systems had a baked-in database rather than a filesystem, Lisp/Smalltalk had persistent images, etc. So I don't know if these abstractions are new, or just going mainstream. Capability-based security systems have been written about in academia for decades (according to https://en.wikipedia.org/wiki/Capability-based_security#Refe...).
Actually no. The most important qualities for a language to quickly gain popularity are:
* Low barrier to entry
* Who is backing it (Go, Java, C#)
* What platforms it opens up (Swift,ObjC,Kotlin/Java) that require that language.
This may not be obvious at first, but AFAIK the majority of Rust users come from web languages (mostly JavaScript, Ruby and Python) and the fraction of programmers doing native/low-level stuff had been declining for decades and Rust is bringing a lot of new people to it.
(Also webassembly, but it's a much smaller niche at the moment)
Rust barely has 2 and 3. Mozilla never pushed it much and it also is not a huge employer. It has 3 if you strech the definition.
Python was popular way before machine learning went mainstream.
> 1 is the most important.
1. is super important, but keep in mind that Python having a much higher barrier to entry than PHP on the web didn't stop it from becoming popular in that field.
Also 1. is really context dependent, and even if Rust has a bigger barrier to entry than Python, it has a much smaller one that its direct competitors (C and C++) because of its documentation, learning material, compiler error messages and dependency management.
Regarding 2. you must have missed the news: Rust is now officially pushed by Microsoft, AWS, Google and Facebook. In fact you'd have difficulties to find languages with stronger corporate backing than Rust today apart from C# and Java.
Rust barrier to entry compared to C/C++ is debatable. Lots of universities for instance have courses in them. They have a whole lot of books and a large community out there.
I disagree about 2 and Rust. Those companies have projects in them and they are a part of rust foundation. They are however not mass employing Rust developers and only AWS has components for core stuff in Rust. Of course it is debatable for what is a core component.
You know Python is older than Google by several years right? ;) When this happened, Python was older than Rust today.
> That is more of a push than any company ever did for Rust.
Microsoft recently made Rust a officially language for developing Windows Native apps[1] and they've advertised the use of the language quite a bit during the past year. Google just released its new operating system developed with as much Rust as C and C++ combined[2]. Also, Facebook and AWS have hired members of the Rust development team after Mozilla's layoff last year to continue their work on Rust.
[1]: https://blogs.windows.com/windowsdeveloper/2021/05/06/announ... [2]: https://news.ycombinator.com/item?id=27274820
This exists in 4GLs (https://en.m.wikipedia.org/wiki/Fourth-generation_programmin...)
Rust has a niche, and it is a big one, where a lot of C++ used to be. If you cannot afford GC pauses (all sorts of servers) and need fine control, rust could very well be for you. It will win in that space.
System programming is not a "ever-shrinking percentage of the software ecosystem". It is a constant percentage. As we develop systems we need languages like Rust.
Historically this doesn't seem entirely true. We haven't gotten much higher level than Java, outside of non-eng niches where we haven't gotten much higher level than Python (which is arguably lower level than R, which has been unseated).
So I don't think it holds true that we'll continue to chase a higher abstraction layer. We recognize the cost of doing so, and it hasn't been worth paying so far.
Besides that, Rust is quite capable of providing high level abstractions. I myself am building a sandboxing mechanism in Rust that will be entirely managed for you but with no runtime cost (it's generated statically) - it is Rust's low level power that lets me build such high level abstractions.
In special because the way rust do things now is THE optimal way to work:
Rust is GROWING.
In this step (let's call it the adolescent) is NOT THE TIME to stop for the needs of C, C++, Debian, or anything else that is glacially slow to change, generate BILLONS of losses in this industry, and is arcane as hell...
In fact, I wish it not be that conservative moving forward.
But where is genius all of this? Is that despite the forward momentum it NOT fell "broken by design" at all. Is one of the few tools in my +20 years on the trade that I can update with confidence and that actually NOT DEMAND to change all my code as often as it look like.
So this is the real experience with Rust: All stuff is very carefully considered as much as possible, not major big mistakes, cargo si GOOD!, and because that, update is painless, and still: You don't need to refactor code in each update, you get benefits without major costs (more performance! better internals!), and still can profit for the work of everyone in the community.
P.D: Rust is certainly made with CI-oriented deployment as the preferred way to work. If wanna move forward glacially, I don't see how is that impossible. In fact I bet you can stop updating, wait 2-3 years, do a big refactoring and move along. This is how ACTUALLY was in the past with tools like C# and others, and I pretty sure Rust will make that thing much easier to shallow...
C++ was the evolution of C and so was Java, but they both turned out to be their own things and C kept on chugging. Rust is a big complicated language, there is nothing C like about it. I see more parallels between Rust and C++ than I do Rust and C.
What's the point of a memory safe language if your whole program could fail for a simple out of memory condition? With C I can allocate all the memory that I need upfront, as a static variable either global (yes, they are not the devil) or inside a single function. That way the compiler can tell me if my program will fit in memory or not.
And yes, I know that in Rust you can avoid using the standard library and you can manage the memory yourself in unsafe blocks. But... what's the point on fighting the language when you can just use C?
All the things that are said about C, it's unsafe, nowadays you have tooling, every decent compiler will warn you if you try to do stupid things.
And yet Microsoft, Mozilla, Google, etc. all peg 70% of the bugs in their C codebases as memory and pointer problems.
Apparently the tooling isn't good enough to stop this.
The point is to be able to do more complex things more easily and performantly, while also not introducing trivial security vulnerabilities like buffer overflows.
> But... what's the point on fighting the language when you can just use C?
The point is to learn not to fight it. At that point, the language becomes much more effective to use than C.
Proper C, which is not full of holes and undefined behaviour, also feels like fighting in the beginning. Empirically, it is also a fight that is won much more rarely.
The Theranos comparison is asinine. Rust works, Theranos did not.
[Also, the article basically talks about how the person doesn't want to learn rust but doesn't think they have a choice not because rust is somehow "right" but because there are a lot of people who want to continue to use rust. This is about as far as you can get from a Rust Hype Machine as you can get without actually attacking the language.]
Some times something comes along that lives up to the hype.
I think Rust does that. It has taken thirty plus years of experience system programming and used it to create a masterpiece. A real triumph of design by committee.
https://en.wikipedia.org/wiki/Cattle_raiding
https://doc.rust-lang.org/std/borrow/enum.Cow.html
https://www.aldeka.net/
One thing about this time was that some folks wanted "Rustafarian" but there were good arguments to not do that, and people moved away from it.
Pretty much every architecture and OS out there has a C compiler. Rust only works well on the most mainstream systems: Linux, macOS, Windows; x86(_64), ARMv8. Building nontrivial Rust programs on the BSDs and other architectures is really difficult. Python recently broke the CI for many distros after depending on a Rust package for this reason.
There are three overlapping reasons for Rust's lack of portability:
1. Language complexity makes it hard to develop a new target or compiler.
2. Language development speed is high, so maintainers of other implementations need to keep up their pace.
3. The language is implementation-driven rather than spec-driven. rustc is the source of truth rather than a specification.
Developing and maintaining a new Rust target/compiler is a ton of work compared to doing the same for C, Go, or even D. The OpenBSD, Plan 9 (!!), and initial Windows targets for Go were all community efforts without Google funding.
Alternative platforms are less used partly because they lack some popular software. We don't need to make it harder than it already is to use them. As long as the aforementioned three issues exist, Rust won't (and shouldn't) be a C replacement.
I do see a place for Rust on the server, for performance-sensitive bits of software that's written mostly in higher-level langs. My side of the "keep other architectures alive" battle has pretty much lost there. Making alternatives to ubiquitous tools like grep (ripgrep) or sed (sd) is also fine, since these alternatives won't replace their predecessors. But I hope it doesn't become a de-facto for desktop/end-user software. PowerPC computers shouldn't become e-waste if they aren't broken, and switching to different architectures shouldn't be as big a deal as it currently is.
There are a ton of architectures that are not ARM, one example is the popular chip ESP32 that uses a proprietary architecture called Xtensa.
Another thing is ABI, even if something is ARM, it doesn't mean that its build process is straight forward and you can just compile with LLVM and it works. Try to integrate the SDK of some microcontrollers based on proprietary compilers like IAR, Keil, etc. It's not trivial. Possible in the end, if you want to rewrite all the linker scripts and make sure to build the executable file in the same way, just not practical.
Then there are 8 bit microcontrollers, and yes you can buy an ESP32 for a ridiculous price, but what if you need to do something low power?
C is universal. Nowadays you can assume that everything that has some sort of processor has a C compiler. With Rust is not like that, and probably never will, since the language is too complex to implement on low cost/low power hardware, and too high level for things that needs a low level access to the hardware.
The fact that C works on IBM System 360 doesn't help anyone.
2. People have PowerPC and ARMv7 devices that work perfectly well. People shouldn't have to buy a new device every N years.
3. I also described how Rust doesn't target many operating systems either; it only targets the three mainstream ones.
Also, from the comment you replied to:
> Alternative platforms are less used partly because they lack some popular software. We don't need to make it harder than it already is to use them.
People can keep using C for the weird DSPs that don't have 8-bit bytes. Besides, there's already a compile-to-C implementation of Rust (mrustc), and a GCC-based implementations in progress (both front-end and back-end).
OTOH Rust and its tooling are way better than the C ecosystem in supporting both Windows and Unix flavors in the same codebase, in a practical manner. C prides itself in theoretical support for obsolete and niche platforms, but requires a mess of ifdefs for basic things like opening a file with non-ASCII characters (and when C programs don't work on Windows, this is dismissed as Windows' problem, not C failing to actually have the standardization and portability it claims).
For a lot of programs "cargo build" just works out of the box on every Rust-supported platform. That's smoother than battling autotools, or cmake build scripts that can't find packages for inexplicable reasons, and random breakages due to C compilers/OSes having functions defined in slightly different headers, with their own quirks.
Rust is really good at abstracting these pains away, so while it can't support Plan 9, it can easily support Windows. Can you imagine opening a TCP socket without needing to know about winsock idiosyncrasies?
Other operating systems like FreeBSD, NetBSD, Solaris, OpenBSD, and DragonflyBSD also exist. FreeBSD is quite relevant and NetBSD and OpenBSD fill almost-empty yet significant niches.
Even if you declare your lib API 'extern "C"', when you call into C++ code you need a C++ runtime that is exactly what you compiled the C++ code with and it has to speak exceptions, templates, name-mangling, etc., exactly like the compiler you compiled that C++ library with. So, you always need the exact compiler to integrate C++.
With Rust, it's a library just like if you compiled it with a C compiler.
The fact that Rust fixes that long-standing C++ suckage, in my opinion, is THE killer feature that's making Rust "popular".
That makes sense to me given the impressive features that have come to C++17 and 20.