Rust’s style of borrow checking is a revolutionary idea because it makes practical things that were impossible before, outside of research languages. I don’t think that will go away any time soon.
Whether Rust itself is “the wave of the future” or not is still undecided, and frankly irrelevant. Maybe it is, or maybe it will become a Simula or SNOBOL that is mainly important for the ideas it pioneered and inspired in later languages. If I’m using something else as my main language in ten years it will be because it’s better than Rust. It’s a high bar, but certainly a conceivable one.
I think Rust is way past the infancy stage, and is here to stay.
Rust has a lot of momentum and is gaining popularity quickly. About 3 years ago number of Rust users and projects has surpassed Scala, D, Nim, and Haskell, and it’s way ahead them now, and growing. crates.io is growing faster than rubygems.org, and is already 40% of its size. Because of it’s niche Rust will never be as popular as mainstream GC languages, but it’s not an “alt-lang” anymore either.
Rust has been explicitly designed as a practical language, not an experiment. It’s used in production. I know big companies where Rust is now a hard dependency for critical components, maintained by entire teams (not one dev’s side project any more).
Rust is based on a lot of pre-existing research languages. In terms of rough syntax and post-ALGOL features there’s already some convergence between Rust, Kotlin, Swift, and TypeScript. The latter two are probably here to stay too, so they’ll keep Rust looking normal.
In Rust’s niche of systems programming + safety there’s no competition. There’s lots of competition in easy GC languages, but that’s not Rust’s niche. There are other systems languages, some of which are nice, but without equal safety guarantees they don’t have the same hook that Rust has (e.g. Rust is getting into Linux because it’s safer, not because it’s nicer).
There’s no obvious flaw (known yet) that a potential Rust-killer could address to displace Rust. New Rust users suffer learning the borrow checker, but it’s not a big issue for experienced users. Rust users are very satisfied with the language.
Rust 1.0 has been released 6 years ago. Even if a Rust-killer was released tomorrow, Rust already has a significant head start and a track record. Rust is still being developed and evolving, so it can put up a fight by copying features from potential Rust-killers (and use the editions to delay ending up like C++).
Oops, my comment is longer than the article now :)
Rust can still suffer from feature creep and long compilation times for large projects. These are things that takes a couple of years to see how they pan out.
Did that really end up being wrong? The initial imagined usecase for it (Applets) didn’t pan out, but a quarter of a century later it’s still the #5 programming language on Stackoverflow (really, number #3 if you accept that SQL and HTML/CSS aren’t so much competing with it as working in concert with it) and it’s probably still #1 in corporate circles.
It’s not my idea of a killer programming language, but the prediction that it was going to eat the world does seems to have largely bore out, just differently than the initial expectation.
In Rust’s niche of systems programming + safety there’s no competition
You don’t hear much about it, but Ada has been in this space for 40 years.
There’s no obvious flaw (known yet) that a potential Rust-killer could address to displace Rust
Rust is good, but it has trouble enforcing large scale constraints on programs, which often show up in Real-Time systems, for which Ada was designed. For example, Ada’s Ravenscar profile detects behavior at compile-time in your program which will lead to unpredictable behavior in high-integrity applications.
If your point is open source specific, you should say that, but deliberately ignoring a language because it historically been used for closed source systems is misleading.
EDIT: I realized I probably came off as combative, which wasn’t my intent. I just don’t think those metrics capture really what’s happening since there’s a lot of closed source development. I just know for sure that OCaml is actively used for some companies critical systems but it doesn’t show up well on those metrics.
I mean other langues have public package repositories and online communities, so they’re comparable this way. Ada isn’t, so I didn’t compare it.
Back to the original point: the fact that Ada is used so differently — closer to DoD than GitHub – also means it’s not a direct Rust competitor. Rust’s openness, vendor-neutrality, community, and availability of open-source libraries are its assets too.
means it’s not a direct Rust competitor. Rust’s openness, vendor-neutrality, community, and availability of open-source libraries are its assets too.
Your point was that there was no safe systems programming equivalent to Rust, my point is that there is, it’s just not well known or used publicly. Ada may have originated from the DoD, but the major Ada implementation, GNAT and a lot of tooling and libraries are GPLv3 or a limited form with a runtime exception. I agree that there’s not really a well established Ada community and it’s just now providing a similar solution to Cargo or CPAN. There’s a lot more than you’d expect, but it’s sort of distributed right now (Ada Utility Library, GNATColl, GNAT, etc.) However, if people feel like they missed getting in on the ground floor of a major programming language and open source library development, there’s huge opportunity on a mature language available.
The DoD vs Github thing may have been true a few years ago, but there’s been a major push from the main Ada vendor, AdaCore, to split off and open source as much as possible, in a eerily similar way to what Mozilla has done (disclaimer: I’m not involved with AdaCore, so I don’t know how far this goes, or what their long term plan is).
Just to give a few examples, there’s per-package (module) constraints like the Pure aspect, which ensures a module has no state and depends on none that has state. There’s also a pragma called “Restrictions” which can do various things like prohibit all or various types of dynamic allocation, prohibit floating point, prohibit the use of recursion, ensure no dependence on other specific modules of code, and so on.
Those all sound like things that could be written as rustc lints. If an industry or organization had such requirements they could maintain lints that do exactly that, and enforce them via #[foo] attributes. Of course, there may be points I’m not thinking of that wouldn’t be possible as a lint as well.
It really doesn’t sound like something that can be done with rustc lint. It sounds most similar to Safe Haskell to me. At the very least, cargo will be involved in addition to rustc.
I 100% believe that Rust is the beginning of a new generation of programming languages. I don’t suspect that Rust will be popular in 10 years, but I’d be willing to bet money that there WILL be at least a few statically typed languages in 10 years that will have obvious roots in Rust.
Don’t misunderstand my next sentence- I’m not saying that Rust invented anything. But, look at how many languages are implementing things like enums/ADTs and pattern matching “all of a sudden” (Python?! Are you for real?!). Look at Swift (which came out after Rust) looking to switch to a Rust-like lifetime/borrow mechanism. Look at ranges in C++.
I think it’s likely that many languages will be influenced by Rust, since there are already dozens of such projects over at /r/ProgrammingLanguages and other places.
But if there’s any one that will be popular in 10 years, it already exists now and you might have heard of it! That is, Rust itself took 8-9 years to become 1.0 and it’s existed for close to 15 years now! Languages just take a long time, so I think in 10 years Rust will still be the top choice … for people who want a “Rust-like” language :)
I made a similar argument when someone was asking about alternatives to Matlab that are not Julia. If you haven’t heard of it already, it’s not likely you’ll be using it in production in 10 years!
It is wild how long it takes the average language to gain mainstream popularity. For example, Python is one of the “new” hot languages of the last decade, but it is older than Linux!
Python is a weird story, IMO. I don’t know anything about the language’s actual history, so my perception could be wrong. But I feel like it really just had a huge surge for some reason around 2005-2010-ish. I don’t exactly know what caused it or why it wasn’t very popular before then, but it’s really interesting that people just suddenly “discovered” it many years after it had been around. For a while, it seemed like everything was written in Python: desktop applications, CLI tools, server backends, data science code, etc.
To be fair, the other viable languages for doing apps in 2005-ish were probably C++, Java, and whatever was in Microsoft land - C# I guess? I can see why Python would be appealing in that environment.
I started using Python in 2003, and I agree it had a bump in popularity in the 2005-2010 era (although it still grew enormously in the last decade).
I think it just takes that long to build a useful language – especially the libraries. I don’t think it was just “discovered” – the key is that it gained a lot of critical functionality.
For example Travis Oliphant was beating the drum hard for NumPy and array programming in the 90’s and early 2000’s (writing a ton of code, documentation, explaining it at PyCon, etc.). And 10 or 15 years later that led to Pandas, Torch, Tensorflow, etc. which are a big part of why Python is popular now. (Ruby, JavaScript, PHP, and Perl all pretty much lack this functionality.)
Guido had almost nothing to do with this! (although obviously he had his hand in so many other critical Python features)
And I remember in 2005 or 2006, Python web programming was immature. I used CherryPy, and there was Twisted. It seems like the ecosystem has converged on Flask and Django to some extent. So it just took effort to build all of that. Ruby also seemed to lack web programming until Rails (afaik).
In 2003, the meme was that Python was a cleaner Perl, but it lacked libraries. People said Perl was a better choice because it had CPAN. Fast forward a few years and now everyone talks about how Python has more bindings for libraries than say Go or Rust! It just takes time.
Yup, Python and Ruby are of a similar vintage, and they both took more than a decade before getting popular. I hadn’t heard of Python before 2003, and it started in 1990 or so. I agree it had a big bump in popularity in the 2005-2010 era.
I think it just takes that long to make a useful language.
JavaScript was arguably not very popular before 2005 or so, about a decade after its creation. And it really got popular in 2009 with node.js.
Ditto for R – it started in 1995, and I started using it in 2009 or so, and a lot of people still haven’t heard of it.
PHP and Perl seem to have gotten fairly popular out of the gate. It would be interesting to know why that is. I think one reason is that PHP was basically a bunch of libraries at first, and not a programming language! It was tightly coupled to Apache, which was becoming huge because people wanted an open source web server.
Yes, that’s a good point, of course. The probability of a language surviving increases as it continues to survive. That sounds almost tautological, but it isn’t.
It’s mostly a hunch, but there are a couple of half-baked reasons:
Statistically speaking, it’s just a safe bet, because there are tons of languages at any given time, but only a few that have lived and thrived for 20+ years (probably single-digits: C, C++, Java, Python, PHP, C#, JavaScript… that’s it? Unless you count LISP, Fortran, Haskell, and Perl as “living and thriving” which I don’t).
Error handling. I mostly like Rust’s error handling mechanism, but I suspect that it’s too tedious for most people and I think there’s room for languages to try other things that may end up being better. Tangentially, my controversial opinion is that checked exceptions deserve another attempt besides how they were implemented by Java. Rust’s approach would be improved (ergonomically) by either ad-hoc enum types or actual inheritance.
Async and Futures, etc. I have a feeling that async/await syntax is a fad for this decade-ish and that in 10 years we’ll all think it was sooo stupid and that “concurrency hoobajoobs” is clearly the right way to do concurrency/async. I don’t have any particular complaint about async, colored functions, Futures, etc- I just see that it’s been very cargo-culty across the entire programming language ecosystem- very similar to OOP in the 90s and similar to FP and monad-all-the-things today.
I also have a hunch that structural typing will become more popular for statically typed languages. That may or may not affect Rust depending on how soon that happens and how cemented Rust is in particular niches.
Not GP, but I think other languages could improve upon Rust.
C identified the high-level patterns that assembly programmers were using: if statements, loops… and it gave us constructs to speak in those higher-level terms.
I think a language could identify the common patterns that Rust programmers often use, and then offer those more directly, with less complexity.
Some other promising avenues: https://cone.jondgoodwin.com/ is making borrow checking easier by complementing it with other memory management strategies, and http://strlen.com/lobster/ is pushing static analysis to be near the borrow checker’s speed.
Replacing languages is an infrequent event. Programming languages are very often invented and designed, but mustering the resources to bring a language of the scope of Rust to industry adoption is really hard and needs a lot of dedication and sweat.
Programming languages are very hard to argue for, spending-wise. And given that Rust is one of the only languages currently being adopted by all the major companies, they will think hard about the delta that languages following it will bring.
I could agree with your phrasing of “adopted by all the major companies”, though I might have phrased it like “adopted by some parts of a lot of major companies, for some things”.
I’m probably speaking from my own bubble, but I don’t really see that Rust has taken off yet. In my day to day job, I see these very clear trends: Obj-C to Swift, Java to Kotlin, Javascript to Typescript. For most actively developed projects where I work, that migration is either underway or in the plans. But I’m not seeing the C++ to Rust transition I would have hoped for. It’s not really even considered that seriously.
From experience, I can only guess that, while Rust is perfect on paper, its difficult learning curve and complexity is what’s holding it back. With that in mind, I wouldn’t be surprised if Rust keeps growing but some other systems language surpasses it in a decade or so, probably one that has the safety and speed of Rust but without the complexities.
C didn’t come into a world where everyone was writing in assembly; its creators had already been involved in Multics, which was programmed in PL/1, for instance. Burroughs had been using ALGOL as its systems language, as had many others, etc.
Ada has had accessibility checks since 1995, through it’s system of making its pointer-like types into actual types which depend on the lifetime in which they’re declared.
I really have to check Ada out, even if only for the historical context. I keep hearing all kinds of interesting things about it. The cynic in me feels like there must be a huge catch, like it must have something that just makes it horrible to work with…
The catch is verbosity due to no macros or preprocessor, and then eventually you figure out that verbosity is a signal from the language that you’re going about your problem in the wrong way.
In general it feels like finding a old but super advanced spaceship crashed in your yard that works just fine, but if you tell anyone you’re using it they think you’re just crazy.
(Yes I keep popping up on your comments and no I still haven’t managed to really crack ada open. Maybe I should, and should look at how to link it to other stuff with more active library communities)
Built into the language you have “protected objects” which provide mutual exclusion to shared resources, and “tasks” which provide the ability to spin off work. You coordinate (rendezvous) with a task by calling one of its “entries”, which are sort of like a procedure call version of “await aTask.asyncFunction();” but “protected objects” can also add guards to these to cause a task to wait in a queue until specific conditions are fulfilled.
Queueing is handled by the language, and as part of these features is a construct called “select” which lets a task “accept” one of multiple entries another flow of execution is waiting on. Since this is built into the language, you also get time-outs waiting on conditions for free, as well as a form of select which will execute a different flow if an entry on a task or protected object would block or if one of the flows exceeds a time limit, like it a calculation takes too long.
What’s super helpful is that because Ada features are opt-in rather than opt-out, you can ignore tasks and protected objects until you understand more of the language, and then define tasks within your functions to split work later on.
active library communities
You can get super far with just the standard library defined by Ada itself, and also the freely available GNAT and GNATCOLL libraries.
Just as something that probably should not be written in Go (like Docker) got written in Go due to hype, something that probably should not be written in Rust will be written in Rust.
Hype was a big factor. At that time, Go was even seen as a risky bet (though you’re right that Rust would’ve been entirely untenable.) The “safest” choice would’ve been to continue what the industry as a whole was doing and write something like docker in C/C++. I was at dotCloud pre-docker, and it seemed clear that Solomon in particular was itching to find a way to use Go.
I think Go is fine for higher level codes of Docker. For lower level, Docker uses Linux namespace, Linux namespace is per thread, but Go runtime creates threads behind your back. This is bad and requires workarounds.
The value on RPC was probably too much. Later, Redhat did a compatible rewrite as Podman without RPC and now it’s an advantage (security and otherwise). RPC was really hot for whatever reason when Go started. It’s probably something to do with the author’s worldviews or background at the time. Or another way, why does the Docker daemon exist? Why do you need to start docker and then connect to it with docker run. Why does docker run ever need to say “docker isn’t running”. I just ran it. You are docker, why are you saying you aren’t running? It’s that whole arch decision.
Some of you are predicting rust will spawn languages that replace it, here is one I am interested in: https://vale.dev/
Some comments are speculating on longevity. My prediction is that rust is java. It’s cumbersome, monolithic, “safe”, does the job and industrial in flavor.
By the time the first three points of my enumeration become true (i.e. lighter, clearer things show up) it’ll be so rooted that it’ll take the henchman role from java.
Some comments are speculating on longevity. My prediction is that rust is java. It’s cumbersome, monolithic, “safe”, does the job and industrial in flavor.
I regularly burn a lot of karma on /r/rust with that viewpoint and have absolutely no problem with that :).
Both Rust and Java are deliberately built with large codebases in mind, which might make them see cumbersome on smaller ones.
Hrm. What’s their plan for addressing the iron triangle of fast/cheap/good? It sounds like they want to offer all three even though their core offering - a generational reference memory management system - is still only a hypothetical. Am I missing something?
No, it’s different. I know C++ for a long time and mainly write C++ in my full-time job for years, but with Rust, I’m about 5 times as productive as with C++. Since I learned Rust, I churned out various programs that I would’ve never been able to develop in C++, simply due to time and complexity. I can now write software that I previously couldn’t have developed as a single person. Say about the language what you will, to me personally, Rust is pure empowerment that manifests in real software that is used by real people daily and saves time, money and nerves. And trust me, in the years before I learned Rust, nothing annoyed me more than the Rust evangelists whose posts kept popping up in every forum.
Is there anything you could share that you feel is a particularly good example of something you’ve been able to develop in Rust on your own that you couldn’t have otherwise?
I’m asking because I am learning Rust for fun right now, and I’m hitting the wall a little bit. (By that I mean “the wall” in the same sense that people who run endurance races use the term. You hit a certain point in the race where you suspect you won’t be able to continue. If you can push past that, you can have a good long race. But it’s a challenge.) I can get things done and there’s a lot that I like about it, but I don’t feel very productive yet.
I’ve mainly written C++ and python over the past 20 years, so if it’s something you could show, seeing some of the things you’ve churned out with Rust that you couldn’t previously would be really interesting to me as I’m deciding whether I can afford the energy/aggravation to “push through”.
Is there anything you could share that you feel is a particularly good example of something you’ve been able to develop in Rust on your own that you couldn’t have otherwise?
Of course all the things that can be done with Rust can also be done with C++… It might just take a decade longer to implement and fix until it’s stable ;)
The projects above are of a size that pushes the boundaries of what I as a single individual can create and maintain in my spare time. I can confidently say that Sherlog would have never happened with C++.
Thanks! That’s exactly the kind of thing I wanted to look at.
I’ve learned new languages/libraries/frameworks enough over the years that this part isn’t surprising. I’m at that miserable point where every time I try to do something new, I spot a way to maybe do it, then spend a while looking at documentation to get it right, and in some cases spend time casting around search engines, forums, chat, etc. to find out what’s best/idiomatic.
Some of this feels a little harder with rust than other things, but probably isn’t really. This is just the slow part of learning something.
So it’s helpful to see those projects that you consider the “payoff”. Plus Sherlog looks neat. Thanks for sharing it.
Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren’t sure which way to do something, do it both ways and see which works better.
John Carmack
Also, the Rust Discord is frequented by super nice and helpful people. They helped me more than once when I got stuck. Same thing with the gnome IRC, they also have a dedicated Rust channel.
Personally its: If it compiles, it’s nearly done. I don’t have to think about += vs append - which in python might just change a lot of what is happening (rust won’t just nest two lists without me realizing, because types..). Or that I don’t have to worry about using c dependencies and their quirks that much (if at all with some very good bindings). Other than that: Yes it takes some time to get really productive. Till you acquired your base of crates and “framework” to re-use for most things (in which you can look up some of your specific solutions).
100% agree here. Not a major rust user, but when I do it is both annoying and really nice how the compiler checks what I would usually catch in manual testing and debugging.
I suspect rust will go the way of scala - too big, too slow to compile, and the weirdly implicit borrow checking rules will limit adoption. Or, if it fares slightly better, the way of Ruby. Not really dying, more popular than purely niche, but entirely avoidable.
In Rust’s favor it does seem to have a decent library publishing community.
Most languages are avoidable, it’s not exactly making rust unsuccessful. In the particular niche of lower level programs or high-performance programs, it’s imho likely that rust will be quite popular. I’ve yet to hear a convincing argument that it’s too big or complicated for what it does, after all the niche is currently dominated by C++ which is several times more complex than rust…
Merits and demerits of Rust aside, the actual point of Chris’s post is “I don’t particularly like Rust but I’m going to have to learn it and deal with it to be effective”… and on that we’re entirely in agreement.
To be honest I think that blog post has almost no content, apart from linking to some other peoples content that truly evaluates some pros and cons. (As the author says themself, its just an observation). Same could be said when people started stuff in C over fortran/speedcode/assembler (in that order). Its like the old discussion which language to pick at all and the answer is always “it depends”.
Rust’s style of borrow checking is a revolutionary idea because it makes practical things that were impossible before, outside of research languages. I don’t think that will go away any time soon.
Whether Rust itself is “the wave of the future” or not is still undecided, and frankly irrelevant. Maybe it is, or maybe it will become a Simula or SNOBOL that is mainly important for the ideas it pioneered and inspired in later languages. If I’m using something else as my main language in ten years it will be because it’s better than Rust. It’s a high bar, but certainly a conceivable one.
I think Rust is way past the infancy stage, and is here to stay.
Rust has a lot of momentum and is gaining popularity quickly. About 3 years ago number of Rust users and projects has surpassed Scala, D, Nim, and Haskell, and it’s way ahead them now, and growing. crates.io is growing faster than rubygems.org, and is already 40% of its size. Because of it’s niche Rust will never be as popular as mainstream GC languages, but it’s not an “alt-lang” anymore either.
Rust has been explicitly designed as a practical language, not an experiment. It’s used in production. I know big companies where Rust is now a hard dependency for critical components, maintained by entire teams (not one dev’s side project any more).
Rust is based on a lot of pre-existing research languages. In terms of rough syntax and post-ALGOL features there’s already some convergence between Rust, Kotlin, Swift, and TypeScript. The latter two are probably here to stay too, so they’ll keep Rust looking normal.
In Rust’s niche of systems programming + safety there’s no competition. There’s lots of competition in easy GC languages, but that’s not Rust’s niche. There are other systems languages, some of which are nice, but without equal safety guarantees they don’t have the same hook that Rust has (e.g. Rust is getting into Linux because it’s safer, not because it’s nicer).
There’s no obvious flaw (known yet) that a potential Rust-killer could address to displace Rust. New Rust users suffer learning the borrow checker, but it’s not a big issue for experienced users. Rust users are very satisfied with the language.
Rust 1.0 has been released 6 years ago. Even if a Rust-killer was released tomorrow, Rust already has a significant head start and a track record. Rust is still being developed and evolving, so it can put up a fight by copying features from potential Rust-killers (and use the editions to delay ending up like C++).
Oops, my comment is longer than the article now :)
Rust can still suffer from feature creep and long compilation times for large projects. These are things that takes a couple of years to see how they pan out.
I think you’re probably right, I just also remember when Java was The Next Killer Thing and am not about to jump to any conclusions.
Did that really end up being wrong? The initial imagined usecase for it (Applets) didn’t pan out, but a quarter of a century later it’s still the #5 programming language on Stackoverflow (really, number #3 if you accept that SQL and HTML/CSS aren’t so much competing with it as working in concert with it) and it’s probably still #1 in corporate circles.
It’s not my idea of a killer programming language, but the prediction that it was going to eat the world does seems to have largely bore out, just differently than the initial expectation.
And indeed java was the next big thing, look at how popular it is nowadays :-). It made garbage collection as mainstream as it could be.
You don’t hear much about it, but Ada has been in this space for 40 years.
Rust is good, but it has trouble enforcing large scale constraints on programs, which often show up in Real-Time systems, for which Ada was designed. For example, Ada’s Ravenscar profile detects behavior at compile-time in your program which will lead to unpredictable behavior in high-integrity applications.
I deliberately haven’t mentioned Ada, because the metrics I have are biased towards open-source, and by these metrics Ada is dead.
If your point is open source specific, you should say that, but deliberately ignoring a language because it historically been used for closed source systems is misleading.
EDIT: I realized I probably came off as combative, which wasn’t my intent. I just don’t think those metrics capture really what’s happening since there’s a lot of closed source development. I just know for sure that OCaml is actively used for some companies critical systems but it doesn’t show up well on those metrics.
I mean other langues have public package repositories and online communities, so they’re comparable this way. Ada isn’t, so I didn’t compare it.
Back to the original point: the fact that Ada is used so differently — closer to DoD than GitHub – also means it’s not a direct Rust competitor. Rust’s openness, vendor-neutrality, community, and availability of open-source libraries are its assets too.
Your point was that there was no safe systems programming equivalent to Rust, my point is that there is, it’s just not well known or used publicly. Ada may have originated from the DoD, but the major Ada implementation, GNAT and a lot of tooling and libraries are GPLv3 or a limited form with a runtime exception. I agree that there’s not really a well established Ada community and it’s just now providing a similar solution to Cargo or CPAN. There’s a lot more than you’d expect, but it’s sort of distributed right now (Ada Utility Library, GNATColl, GNAT, etc.) However, if people feel like they missed getting in on the ground floor of a major programming language and open source library development, there’s huge opportunity on a mature language available.
I’m unsure how Rust has vendor-neutrality though when there’s only one main Rust implementation, whereas Ada is an ISO standard and has a full public battery of compiler tests for implementers.
The DoD vs Github thing may have been true a few years ago, but there’s been a major push from the main Ada vendor, AdaCore, to split off and open source as much as possible, in a eerily similar way to what Mozilla has done (disclaimer: I’m not involved with AdaCore, so I don’t know how far this goes, or what their long term plan is).
Can you tell me more about these large scale constraints? Are we talking like, latency/memory constraints?
Just to give a few examples, there’s per-package (module) constraints like the Pure aspect, which ensures a module has no state and depends on none that has state. There’s also a pragma called “Restrictions” which can do various things like prohibit all or various types of dynamic allocation, prohibit floating point, prohibit the use of recursion, ensure no dependence on other specific modules of code, and so on.
Those all sound like things that could be written as
rustclints. If an industry or organization had such requirements they could maintain lints that do exactly that, and enforce them via#[foo]attributes. Of course, there may be points I’m not thinking of that wouldn’t be possible as a lint as well.It really doesn’t sound like something that can be done with rustc lint. It sounds most similar to Safe Haskell to me. At the very least, cargo will be involved in addition to rustc.
I 100% believe that Rust is the beginning of a new generation of programming languages. I don’t suspect that Rust will be popular in 10 years, but I’d be willing to bet money that there WILL be at least a few statically typed languages in 10 years that will have obvious roots in Rust.
Don’t misunderstand my next sentence- I’m not saying that Rust invented anything. But, look at how many languages are implementing things like enums/ADTs and pattern matching “all of a sudden” (Python?! Are you for real?!). Look at Swift (which came out after Rust) looking to switch to a Rust-like lifetime/borrow mechanism. Look at ranges in C++.
I think it’s likely that many languages will be influenced by Rust, since there are already dozens of such projects over at /r/ProgrammingLanguages and other places.
But if there’s any one that will be popular in 10 years, it already exists now and you might have heard of it! That is, Rust itself took 8-9 years to become 1.0 and it’s existed for close to 15 years now! Languages just take a long time, so I think in 10 years Rust will still be the top choice … for people who want a “Rust-like” language :)
I made a similar argument when someone was asking about alternatives to Matlab that are not Julia. If you haven’t heard of it already, it’s not likely you’ll be using it in production in 10 years!
It is wild how long it takes the average language to gain mainstream popularity. For example, Python is one of the “new” hot languages of the last decade, but it is older than Linux!
Python is a weird story, IMO. I don’t know anything about the language’s actual history, so my perception could be wrong. But I feel like it really just had a huge surge for some reason around 2005-2010-ish. I don’t exactly know what caused it or why it wasn’t very popular before then, but it’s really interesting that people just suddenly “discovered” it many years after it had been around. For a while, it seemed like everything was written in Python: desktop applications, CLI tools, server backends, data science code, etc.
To be fair, the other viable languages for doing apps in 2005-ish were probably C++, Java, and whatever was in Microsoft land - C# I guess? I can see why Python would be appealing in that environment.
I started using Python in 2003, and I agree it had a bump in popularity in the 2005-2010 era (although it still grew enormously in the last decade).
I think it just takes that long to build a useful language – especially the libraries. I don’t think it was just “discovered” – the key is that it gained a lot of critical functionality.
For example Travis Oliphant was beating the drum hard for NumPy and array programming in the 90’s and early 2000’s (writing a ton of code, documentation, explaining it at PyCon, etc.). And 10 or 15 years later that led to Pandas, Torch, Tensorflow, etc. which are a big part of why Python is popular now. (Ruby, JavaScript, PHP, and Perl all pretty much lack this functionality.)
Guido had almost nothing to do with this! (although obviously he had his hand in so many other critical Python features)
And I remember in 2005 or 2006, Python web programming was immature. I used CherryPy, and there was Twisted. It seems like the ecosystem has converged on Flask and Django to some extent. So it just took effort to build all of that. Ruby also seemed to lack web programming until Rails (afaik).
In 2003, the meme was that Python was a cleaner Perl, but it lacked libraries. People said Perl was a better choice because it had CPAN. Fast forward a few years and now everyone talks about how Python has more bindings for libraries than say Go or Rust! It just takes time.
Thanks for the insight. As I said, I was kind of passive observer, as I was just barely learning to program in 2007-ish.
Yup, Python and Ruby are of a similar vintage, and they both took more than a decade before getting popular. I hadn’t heard of Python before 2003, and it started in 1990 or so. I agree it had a big bump in popularity in the 2005-2010 era.
I think it just takes that long to make a useful language.
JavaScript was arguably not very popular before 2005 or so, about a decade after its creation. And it really got popular in 2009 with node.js.
Ditto for R – it started in 1995, and I started using it in 2009 or so, and a lot of people still haven’t heard of it.
PHP and Perl seem to have gotten fairly popular out of the gate. It would be interesting to know why that is. I think one reason is that PHP was basically a bunch of libraries at first, and not a programming language! It was tightly coupled to Apache, which was becoming huge because people wanted an open source web server.
Yes, that’s a good point, of course. The probability of a language surviving increases as it continues to survive. That sounds almost tautological, but it isn’t.
Out of interest, why do you say this? Is there a specific reason/reasons why you think its popularity will plateau/wane?
It’s mostly a hunch, but there are a couple of half-baked reasons:
Not GP, but I think other languages could improve upon Rust.
C identified the high-level patterns that assembly programmers were using: if statements, loops… and it gave us constructs to speak in those higher-level terms.
I think a language could identify the common patterns that Rust programmers often use, and then offer those more directly, with less complexity.
Some other promising avenues: https://cone.jondgoodwin.com/ is making borrow checking easier by complementing it with other memory management strategies, and http://strlen.com/lobster/ is pushing static analysis to be near the borrow checker’s speed.
Replacing languages is an infrequent event. Programming languages are very often invented and designed, but mustering the resources to bring a language of the scope of Rust to industry adoption is really hard and needs a lot of dedication and sweat.
Programming languages are very hard to argue for, spending-wise. And given that Rust is one of the only languages currently being adopted by all the major companies, they will think hard about the delta that languages following it will bring.
I could agree with your phrasing of “adopted by all the major companies”, though I might have phrased it like “adopted by some parts of a lot of major companies, for some things”.
I’m probably speaking from my own bubble, but I don’t really see that Rust has taken off yet. In my day to day job, I see these very clear trends: Obj-C to Swift, Java to Kotlin, Javascript to Typescript. For most actively developed projects where I work, that migration is either underway or in the plans. But I’m not seeing the C++ to Rust transition I would have hoped for. It’s not really even considered that seriously.
From experience, I can only guess that, while Rust is perfect on paper, its difficult learning curve and complexity is what’s holding it back. With that in mind, I wouldn’t be surprised if Rust keeps growing but some other systems language surpasses it in a decade or so, probably one that has the safety and speed of Rust but without the complexities.
C didn’t come into a world where everyone was writing in assembly; its creators had already been involved in Multics, which was programmed in PL/1, for instance. Burroughs had been using ALGOL as its systems language, as had many others, etc.
Ada has had accessibility checks since 1995, through it’s system of making its pointer-like types into actual types which depend on the lifetime in which they’re declared.
I really have to check Ada out, even if only for the historical context. I keep hearing all kinds of interesting things about it. The cynic in me feels like there must be a huge catch, like it must have something that just makes it horrible to work with…
The catch is verbosity due to no macros or preprocessor, and then eventually you figure out that verbosity is a signal from the language that you’re going about your problem in the wrong way.
In general it feels like finding a old but super advanced spaceship crashed in your yard that works just fine, but if you tell anyone you’re using it they think you’re just crazy.
What’s the concurrency story like?
(Yes I keep popping up on your comments and no I still haven’t managed to really crack ada open. Maybe I should, and should look at how to link it to other stuff with more active library communities)
Built into the language you have “protected objects” which provide mutual exclusion to shared resources, and “tasks” which provide the ability to spin off work. You coordinate (rendezvous) with a task by calling one of its “entries”, which are sort of like a procedure call version of “await aTask.asyncFunction();” but “protected objects” can also add guards to these to cause a task to wait in a queue until specific conditions are fulfilled.
Queueing is handled by the language, and as part of these features is a construct called “select” which lets a task “accept” one of multiple entries another flow of execution is waiting on. Since this is built into the language, you also get time-outs waiting on conditions for free, as well as a form of select which will execute a different flow if an entry on a task or protected object would block or if one of the flows exceeds a time limit, like it a calculation takes too long.
What’s super helpful is that because Ada features are opt-in rather than opt-out, you can ignore tasks and protected objects until you understand more of the language, and then define tasks within your functions to split work later on.
You can get super far with just the standard library defined by Ada itself, and also the freely available GNAT and GNATCOLL libraries.
That’s cool. It sounds kind of like an actor model, and should be easy to build the necessary functionality on top if one wanted “proper” actors.
Just as something that probably should not be written in Go (like Docker) got written in Go due to hype, something that probably should not be written in Rust will be written in Rust.
Was it really because of hype? I don’t recall the timeline but Rust was still very unstable when dotcould was building whats now called Docker.
Its definitely fair to say it would be better in rust, but back in the days, rust would have been a difficult pick.
Go 1 still hasn’t broken its compatibility promise, which was a huge enabler for many projects.
Hype was a big factor. At that time, Go was even seen as a risky bet (though you’re right that Rust would’ve been entirely untenable.) The “safest” choice would’ve been to continue what the industry as a whole was doing and write something like docker in C/C++. I was at dotCloud pre-docker, and it seemed clear that Solomon in particular was itching to find a way to use Go.
It is inevitable.
What’s the issue with writing something like Docker in Go?
I think Go is fine for higher level codes of Docker. For lower level, Docker uses Linux namespace, Linux namespace is per thread, but Go runtime creates threads behind your back. This is bad and requires workarounds.
The value on RPC was probably too much. Later, Redhat did a compatible rewrite as Podman without RPC and now it’s an advantage (security and otherwise). RPC was really hot for whatever reason when Go started. It’s probably something to do with the author’s worldviews or background at the time. Or another way, why does the Docker daemon exist? Why do you need to start docker and then connect to it with
docker run. Why doesdocker runever need to say “docker isn’t running”. I just ran it. You are docker, why are you saying you aren’t running? It’s that whole arch decision.Some of you are predicting rust will spawn languages that replace it, here is one I am interested in: https://vale.dev/
Some comments are speculating on longevity. My prediction is that rust is java. It’s cumbersome, monolithic, “safe”, does the job and industrial in flavor.
By the time the first three points of my enumeration become true (i.e. lighter, clearer things show up) it’ll be so rooted that it’ll take the henchman role from java.
I regularly burn a lot of karma on /r/rust with that viewpoint and have absolutely no problem with that :).
Both Rust and Java are deliberately built with large codebases in mind, which might make them see cumbersome on smaller ones.
Hrm. What’s their plan for addressing the iron triangle of fast/cheap/good? It sounds like they want to offer all three even though their core offering - a generational reference memory management system - is still only a hypothetical. Am I missing something?
It’s an interesting but incomplete project for these exact reasons. The website is a great resource.
See you in a decade or two.
If Rust is still a thing, maybe it will then be worth consideration.
isn’t this like with c/c++/java/javascript previously ?
No, it’s different. I know C++ for a long time and mainly write C++ in my full-time job for years, but with Rust, I’m about 5 times as productive as with C++. Since I learned Rust, I churned out various programs that I would’ve never been able to develop in C++, simply due to time and complexity. I can now write software that I previously couldn’t have developed as a single person. Say about the language what you will, to me personally, Rust is pure empowerment that manifests in real software that is used by real people daily and saves time, money and nerves. And trust me, in the years before I learned Rust, nothing annoyed me more than the Rust evangelists whose posts kept popping up in every forum.
Is there anything you could share that you feel is a particularly good example of something you’ve been able to develop in Rust on your own that you couldn’t have otherwise?
I’m asking because I am learning Rust for fun right now, and I’m hitting the wall a little bit. (By that I mean “the wall” in the same sense that people who run endurance races use the term. You hit a certain point in the race where you suspect you won’t be able to continue. If you can push past that, you can have a good long race. But it’s a challenge.) I can get things done and there’s a lot that I like about it, but I don’t feel very productive yet.
I’ve mainly written C++ and python over the past 20 years, so if it’s something you could show, seeing some of the things you’ve churned out with Rust that you couldn’t previously would be really interesting to me as I’m deciding whether I can afford the energy/aggravation to “push through”.
Sure, these are some of my spare time projects:
Of course all the things that can be done with Rust can also be done with C++… It might just take a decade longer to implement and fix until it’s stable ;)
The projects above are of a size that pushes the boundaries of what I as a single individual can create and maintain in my spare time. I can confidently say that Sherlog would have never happened with C++.
Thanks! That’s exactly the kind of thing I wanted to look at.
I’ve learned new languages/libraries/frameworks enough over the years that this part isn’t surprising. I’m at that miserable point where every time I try to do something new, I spot a way to maybe do it, then spend a while looking at documentation to get it right, and in some cases spend time casting around search engines, forums, chat, etc. to find out what’s best/idiomatic.
Some of this feels a little harder with rust than other things, but probably isn’t really. This is just the slow part of learning something.
So it’s helpful to see those projects that you consider the “payoff”. Plus Sherlog looks neat. Thanks for sharing it.
Also, the Rust Discord is frequented by super nice and helpful people. They helped me more than once when I got stuck. Same thing with the gnome IRC, they also have a dedicated Rust channel.
Personally its: If it compiles, it’s nearly done. I don’t have to think about
+=vsappend- which in python might just change a lot of what is happening (rust won’t just nest two lists without me realizing, because types..). Or that I don’t have to worry about using c dependencies and their quirks that much (if at all with some very good bindings). Other than that: Yes it takes some time to get really productive. Till you acquired your base of crates and “framework” to re-use for most things (in which you can look up some of your specific solutions).100% agree here. Not a major rust user, but when I do it is both annoying and really nice how the compiler checks what I would usually catch in manual testing and debugging.
Well, it’s a wave, they come and go :)
Hahaha nice one, I’ll chill on a sandy beach of C/Fortran/Python and mine some coins =)
I suspect rust will go the way of scala - too big, too slow to compile, and the weirdly implicit borrow checking rules will limit adoption. Or, if it fares slightly better, the way of Ruby. Not really dying, more popular than purely niche, but entirely avoidable.
In Rust’s favor it does seem to have a decent library publishing community.
Most languages are avoidable, it’s not exactly making rust unsuccessful. In the particular niche of lower level programs or high-performance programs, it’s imho likely that rust will be quite popular. I’ve yet to hear a convincing argument that it’s too big or complicated for what it does, after all the niche is currently dominated by C++ which is several times more complex than rust…
Merits and demerits of Rust aside, the actual point of Chris’s post is “I don’t particularly like Rust but I’m going to have to learn it and deal with it to be effective”… and on that we’re entirely in agreement.
Every Rust submission reminds of this.
To be honest I think that blog post has almost no content, apart from linking to some other peoples content that truly evaluates some pros and cons. (As the author says themself, its just an observation). Same could be said when people started stuff in C over fortran/speedcode/assembler (in that order). Its like the old discussion which language to pick at all and the answer is always “it depends”.