Perhaps I'm a minority, but I still don't believe that Rust will ever become successful. I have several reasons to think that way, but the main reason IMO is that it's too complex to be a...
Perhaps I'm a minority, but I still don't believe that Rust will ever become successful. I have several reasons to think that way, but the main reason IMO is that it's too complex to be a successful application-level language and too unstable to be a successful low-level language. By unstable I don't mean that the code will break (although IIRC ~7% of respondents of the recent Rust survey have indicated that a Rust update broke their code), but that stuff needs to be rewritten constantly to make use of the newest “best way” to do things. A 6 week release cycle is madness if you want to appeal to people who get grumpy when a new, mostly non-breaking standard comes out every 3-7 years.
Define "successful"? Rust is already responsible for many aspects of Mozilla's software, such as the Servo CSS engine. I'm not a low level developer. I spend most of my time writing extremely high...
Define "successful"? Rust is already responsible for many aspects of Mozilla's software, such as the Servo CSS engine.
I'm not a low level developer. I spend most of my time writing extremely high level code—PHP, JS, C#. I've written two applications in Rust now and I really enjoyed it. Sure, you have to navigate its borrowing system at first, but if you don't fight it, it'll reward you. I can't say I've ever felt a desire to learn C or C++, but Rust makes the experience pleasant end-to-end across the platform. From dependencies to compilation to documentation.
I think the definition of successful for Rust is to eat some of the market share of C++ and maybe C. It's obviously got the potential (Firefox is a good example for it replacing C++, and there's...
I think the definition of successful for Rust is to eat some of the market share of C++ and maybe C. It's obviously got the potential (Firefox is a good example for it replacing C++, and there's RedoxOS which is in C's league), but we'll see. I think the tendency to rewrite stuff that's present in the community is a bit problematic, say if Redox just ported over GNU Coreutils, GCC and Vim, it might've been a big success. It need not be pure Rust, nothing is pure lang-X.
Personally, I don't have a use for the language and haven't really tried it besides hello world, but I really don't like the syntax. It would've been better if it was ML style maybe. An expression based language (in that most stuff can be expessions rather than statements) becomes very complex to look at when it's all braces and cryptic keywords.
Becoming one of 2-3 go-to languages for one or several domains. C is the go-to language for OS stuff, device drivers, and embedded software. C++ is mostly like C, but it also is one of several...
Define "successful"?
Becoming one of 2-3 go-to languages for one or several domains. C is the go-to language for OS stuff, device drivers, and embedded software. C++ is mostly like C, but it also is one of several go-to languages for desktop applications and web servers. It shares the desktop applications domain on Windows with C#. Java is another choice for high-performance web services and infrastructure. Go is slowly eating away Java's and C++'s web server and infrastructure bread. You have Java (again!) and ObjC on mobile. You have Lua for embedded scripting. You have Ruby, Python, and PHP for less performant and more flexible web stuff. I think you got the idea.
Until there is a type of program for which a significant portion of programmers will say “It's easy, we'll be boring and just Rust for this”, Rust will remain in that league of “those weird languages” along with Haskell, OCaml, Prolog, and most Lisp dialects. It doesn't make it a bad language, or a one that you can't enjoy. It's just not a skill you can easily sell on the workforce market.
You're right that Rust is not, say, the go-to language for embedded software and so forth; but I wouldn't put it in the same bucket as "weird/toy" languages like Haskell, Lua, etc. It's got...
You're right that Rust is not, say, the go-to language for embedded software and so forth; but I wouldn't put it in the same bucket as "weird/toy" languages like Haskell, Lua, etc. It's got significantly more mindshare than Haskell and co, and was first place for "Most Loved" language in Stack Overflow's 2018 dev survey, as well as 8th most wanted.
Pretty good place to be in for a "small" language, if you ask me.
This is my take as well. Rust is a very young entrant into an ecosystem which has been dominated by C and C++ for forty years. C is in everything, and to change that would be like getting everyone...
This is my take as well. Rust is a very young entrant into an ecosystem which has been dominated by C and C++ for forty years. C is in everything, and to change that would be like getting everyone in the world to speak Esperanto.
With that in mind, Rust has made more inroads than any systems programming language I've seen come around before it. It has transcended the stage of being a fad language, and has really filled a niche which people were longing to be filled.
Besides Mozilla's high profile deployment, people are building all sorts of projects with it, ranging from operating system kernels to coreutils replacements, to applications, to web services.
It may not take over the world, but it's not going away either.
I'm curious about this. Supposedly there should not be any breaking changes to rust since 1.0.0. Perhaps 7% of people are confused and mistook a breaking change in a crate for a breaking change in...
IIRC ~7% of respondents of the recent Rust survey have indicated that a Rust update broke their code
I'm curious about this. Supposedly there should not be any breaking changes to rust since 1.0.0. Perhaps 7% of people are confused and mistook a breaking change in a crate for a breaking change in the compiler?
stuff needs to be rewritten constantly to make use of the newest “best way” to do things
This depends entirely on the attention span of your own developers. You don't need to use the shiny new features - rust is a good language today, and it will still be a good language even if you're using today's version in 5 years.
Of course, this all depends on your use of external crates. If your code heavily depends on an alpha or beta status crate today, then you'll need to keep up to date. But that's more of a failing of the crate than the language. In time the ecosystem will mature. I've already seen improvements in the couple of years I've been following rust.
The percentage of people who see a breakage during a routine compiler update has stayed the same since last year, with 7.4% saying they’ve experienced breakage.
Breakages generally leaned to requiring minor fixes, though some reported having moderate or major fixes to upgrade to the next stable compiler.
That comes right after they say that now 56% of people are using nightly rust. I assume that using the unstable variant is what gives people breaking changes. However, if you know of any specific...
That comes right after they say that now 56% of people are using nightly rust.
I assume that using the unstable variant is what gives people breaking changes. However, if you know of any specific breaking changes on stable I'd like to hear about them.
I don't even have to look for them. The release history documents them. Rust 1.2.0, 1.3.0, 1.4.0, 1.5.0, and 1.15.0 all have from one to thirteen breaking changes. Most are minor, but they exist....
However, if you know of any specific breaking changes on stable I'd like to hear about them.
I don't even have to look for them. The release history documents them. Rust 1.2.0, 1.3.0, 1.4.0, 1.5.0, and 1.15.0 all have from one to thirteen breaking changes. Most are minor, but they exist.
While we're at it, this culture of using nightly is very disturbing to me. I remember making yet another attempt to dive into Rust and build something, just to find out that the most popular crate to do that was nightly-only. That was a very long time ago, probably around 1.5.0, but still, forcing programmers to use what is literally an unstable distribution seems unproductive to me. And definitely not something C programmers will want to deal with.
And what is up with language terminology these days? Go names modules “packages” and packages “modules”, Rust decides that it should call namespaces “modules” and modules “crates”.
Well, looks like I'm very wrong then. I thought rust would have no breaking changes, but really they just do their best to avoid major ones. While digging through that release history, and...
Well, looks like I'm very wrong then. I thought rust would have no breaking changes, but really they just do their best to avoid major ones.
While digging through that release history, and googling around for other information, I found this comment on reddit which makes a good argument for small breaking changes:
AFAIK, Rust has had minor breaking changes before, so this is not a new thing. But it doesn’t hurt trying to bring the issue to light, I guess.
In my opinion, taking such a strict approach to backwards compatibility only hurts the language and its users in the long run, and does no good. I don't think it's worth making such a fuss over code like if let false = foo && bar, because I don't think anyone has written that before the RFC discussion.
Someone in TC39 has written there that they've found out there's a bit of wiggle room wrt. breaking changes, and I think that's a wise lesson to learn. Even C++ has had a lot of breaking changes before, in code that was much more plausible than if let false = foo && bar. C# had breaking changes. Java had (minor) breaking changes.
Legal systems everywhere have that bit of that wiggle room. It seems to me that "no breaking changes, ever" is just trying to tick a check box. I agree it's desirable, and backwards compatibility should always be a concern. But I don't think anyone is trying to dismiss it without the due process.
You seem to be very upset about these changes, but please try to think at the bigger picture, instead of considering only the rule from above. Rust remains the same language, with the same values as before. Some never-uttered-before code might break, probably with a trivial and easy to automate fix.
WellMakeItSomehow
So for someone looking for stability, rust isn't anywhere near C's level yet. But if it's still used in a few decades it might be where C is today.
While we're at it, this culture of using nightly is very disturbing to me.
I agree. I've personally never used nightly except for a quick test of a new feature. If a crate or tool requires nightly I don't use it.
I agree with that comment, actually. As someone who has worked in Java and Swift, I've seen both extremes. With Java, as an example, I wish they would rip out their implementation of Serialization...
I agree with that comment, actually. As someone who has worked in Java and Swift, I've seen both extremes.
With Java, as an example, I wish they would rip out their implementation of Serialization - it's broken, it's awful, and even worse using it will cause issues down the line unless you really need what Java's serialization offers, and not just some bog-standard way of taking objects and translating them into some format that can be interpreted by anything else (e.g. JSON). It's a shame because I actually enjoy Java, but there are some parts of the code which really needs a breaking change to prevent some poor sod from writing dud code with the intent of writing sane code.
Swift, on the other hand, has a breaking change every single major release. If you've ever made a mobile app using Swift and you do maintenance updates at the least, you will absolutely have to put in the leg work to upgrade your Swift code lest you want your code to not build in future Xcode versions. And future Xcode builds will happen, as iOS and macOS update all the time, and so does the framework. For me it feels like insanity.
From what I've seen in Rust, everything seems fair and sensible. I've even dabbled in it and it really doesn't make me sweat bullets like C and C++ usually does. And if this is the approach Mozilla are going to take, then I agree with them.
I know this thread is seven months old, but I've just encountered this on /r/rust. A user's code was presumably correct and used to compile. After the 1.36.0 release, it stopped compiling despite...
I know this thread is seven months old, but I've just encountered this on /r/rust. A user's code was presumably correct and used to compile. After the 1.36.0 release, it stopped compiling despite being correct. A person probably working for one of the Rust Teams reminds that:
Type inference regressions are explicitly permitted per our stability policy.
This made me think of you and this thread, so I decided to share.
Thanks! Awesome of you to add to the thread. I've been writing rust more and more since this thread was fresh. I still haven't personally been burned by this "wiggle room" philosophy. My only...
Thanks! Awesome of you to add to the thread.
I've been writing rust more and more since this thread was fresh. I still haven't personally been burned by this "wiggle room" philosophy.
My only complaint it's that I wish for a comprehensive source on the borrow checker. I frequently feel blindsided by related compiler errors. There are tricks like wrapping certain fields in an option so that you can take ownership in a Drop implementation. All of those should be compiled into a cheat sheet.
I really want to try using Rust for web stuff but I spent weeks trying to work out how to get Rocket to connect to postgres and then every time I resumed work on it I needed to update to a new...
I really want to try using Rust for web stuff but I spent weeks trying to work out how to get Rocket to connect to postgres and then every time I resumed work on it I needed to update to a new version of rust nightly which would break everything and I'd end up spending the day trying to unbreak it.
Still super excited to use it one day but I think the libraries need more work. I might look in to it for writing native extensions for my rails app though.
Rocket looks interesting, but it takes a long time to get a web framework to the point where it's fun and easy to use. Personally I haven't touched it at all.
Rocket looks interesting, but it takes a long time to get a web framework to the point where it's fun and easy to use. Personally I haven't touched it at all.
From my abandoned web project, Rocket is what I would call good, but only through very gritted teeth. The biggest problem I had with it was some very vague documentation. But vague documentation...
From my abandoned web project, Rocket is what I would call good, but only through very gritted teeth. The biggest problem I had with it was some very vague documentation. But vague documentation is a huge problem with basically any cutting edge software package.
If they had excellent documentation, I would both unclench my teeth and briefly consider calling it great.
I like Rust's way of adding keywords, as compared to C's. With C's way, every identifier that begins with an underscore followed by a capital letter is reserved as a future keyword. Then, when C...
I like Rust's way of adding keywords, as compared to C's.
With C's way, every identifier that begins with an underscore followed by a capital letter is reserved as a future keyword. Then, when C wants to add a new keyword (like, let's say, noreturn), they first define _Noreturn, which is already reserved, then they add a standard noreturn.h which consists of a single line:
#define noreturn _Noreturn
That way, old code, which may use noreturn as a variable name, is unaffected, because it doesn't include the header file. No code just has to #include <noreturn.h> and all is well.
It works very well, but it feels a little awkward.
Rust's system: If you want 2018 keywords, compile as 2018 code. If you don't, compile as 2015 code. Seems much simpler.
A lot of people will disagree with me, but the more I think about it, the more I agree with some programming language designs that made keywords distinct from identifiers. It can be uppercase for...
A lot of people will disagree with me, but the more I think about it, the more I agree with some programming language designs that made keywords distinct from identifiers. It can be uppercase for keywords (IF x <> 0 THEN …), sigils for identifiers (if $x != 0 { …), or some other form of stropping. It makes the code harder to write, but also (again, opinion) easier to read.
Perhaps I'm a minority, but I still don't believe that Rust will ever become successful. I have several reasons to think that way, but the main reason IMO is that it's too complex to be a successful application-level language and too unstable to be a successful low-level language. By unstable I don't mean that the code will break (although IIRC ~7% of respondents of the recent Rust survey have indicated that a Rust update broke their code), but that stuff needs to be rewritten constantly to make use of the newest “best way” to do things. A 6 week release cycle is madness if you want to appeal to people who get grumpy when a new, mostly non-breaking standard comes out every 3-7 years.
Define "successful"? Rust is already responsible for many aspects of Mozilla's software, such as the Servo CSS engine.
I'm not a low level developer. I spend most of my time writing extremely high level code—PHP, JS, C#. I've written two applications in Rust now and I really enjoyed it. Sure, you have to navigate its borrowing system at first, but if you don't fight it, it'll reward you. I can't say I've ever felt a desire to learn C or C++, but Rust makes the experience pleasant end-to-end across the platform. From dependencies to compilation to documentation.
I'm definitely going to use Rust again.
I think the definition of successful for Rust is to eat some of the market share of C++ and maybe C. It's obviously got the potential (Firefox is a good example for it replacing C++, and there's RedoxOS which is in C's league), but we'll see. I think the tendency to rewrite stuff that's present in the community is a bit problematic, say if Redox just ported over GNU Coreutils, GCC and Vim, it might've been a big success. It need not be pure Rust, nothing is pure lang-X.
Personally, I don't have a use for the language and haven't really tried it besides hello world, but I really don't like the syntax. It would've been better if it was ML style maybe. An expression based language (in that most stuff can be expessions rather than statements) becomes very complex to look at when it's all braces and cryptic keywords.
Becoming one of 2-3 go-to languages for one or several domains. C is the go-to language for OS stuff, device drivers, and embedded software. C++ is mostly like C, but it also is one of several go-to languages for desktop applications and web servers. It shares the desktop applications domain on Windows with C#. Java is another choice for high-performance web services and infrastructure. Go is slowly eating away Java's and C++'s web server and infrastructure bread. You have Java (again!) and ObjC on mobile. You have Lua for embedded scripting. You have Ruby, Python, and PHP for less performant and more flexible web stuff. I think you got the idea.
Until there is a type of program for which a significant portion of programmers will say “It's easy, we'll be boring and just Rust for this”, Rust will remain in that league of “those weird languages” along with Haskell, OCaml, Prolog, and most Lisp dialects. It doesn't make it a bad language, or a one that you can't enjoy. It's just not a skill you can easily sell on the workforce market.
You're right that Rust is not, say, the go-to language for embedded software and so forth; but I wouldn't put it in the same bucket as "weird/toy" languages like Haskell, Lua, etc. It's got significantly more mindshare than Haskell and co, and was first place for "Most Loved" language in Stack Overflow's 2018 dev survey, as well as 8th most wanted.
Pretty good place to be in for a "small" language, if you ask me.
Isn't it a bit early for it to fully solidify? C and C++ are decades old.
This is my take as well. Rust is a very young entrant into an ecosystem which has been dominated by C and C++ for forty years. C is in everything, and to change that would be like getting everyone in the world to speak Esperanto.
With that in mind, Rust has made more inroads than any systems programming language I've seen come around before it. It has transcended the stage of being a fad language, and has really filled a niche which people were longing to be filled.
Besides Mozilla's high profile deployment, people are building all sorts of projects with it, ranging from operating system kernels to coreutils replacements, to applications, to web services.
It may not take over the world, but it's not going away either.
I'm curious about this. Supposedly there should not be any breaking changes to rust since 1.0.0. Perhaps 7% of people are confused and mistook a breaking change in a crate for a breaking change in the compiler?
This depends entirely on the attention span of your own developers. You don't need to use the shiny new features - rust is a good language today, and it will still be a good language even if you're using today's version in 5 years.
Of course, this all depends on your use of external crates. If your code heavily depends on an alpha or beta status crate today, then you'll need to keep up to date. But that's more of a failing of the crate than the language. In time the ecosystem will mature. I've already seen improvements in the couple of years I've been following rust.
Link to the survey results.
That comes right after they say that now 56% of people are using nightly rust.
I assume that using the unstable variant is what gives people breaking changes. However, if you know of any specific breaking changes on stable I'd like to hear about them.
I don't even have to look for them. The release history documents them. Rust 1.2.0, 1.3.0, 1.4.0, 1.5.0, and 1.15.0 all have from one to thirteen breaking changes. Most are minor, but they exist.
While we're at it, this culture of using nightly is very disturbing to me. I remember making yet another attempt to dive into Rust and build something, just to find out that the most popular crate to do that was nightly-only. That was a very long time ago, probably around 1.5.0, but still, forcing programmers to use what is literally an unstable distribution seems unproductive to me. And definitely not something C programmers will want to deal with.
And what is up with language terminology these days? Go names modules “packages” and packages “modules”, Rust decides that it should call namespaces “modules” and modules “crates”.
Well, looks like I'm very wrong then. I thought rust would have no breaking changes, but really they just do their best to avoid major ones.
While digging through that release history, and googling around for other information, I found this comment on reddit which makes a good argument for small breaking changes:
So for someone looking for stability, rust isn't anywhere near C's level yet. But if it's still used in a few decades it might be where C is today.
I agree. I've personally never used nightly except for a quick test of a new feature. If a crate or tool requires nightly I don't use it.
I agree with that comment, actually. As someone who has worked in Java and Swift, I've seen both extremes.
With Java, as an example, I wish they would rip out their implementation of Serialization - it's broken, it's awful, and even worse using it will cause issues down the line unless you really need what Java's serialization offers, and not just some bog-standard way of taking objects and translating them into some format that can be interpreted by anything else (e.g. JSON). It's a shame because I actually enjoy Java, but there are some parts of the code which really needs a breaking change to prevent some poor sod from writing dud code with the intent of writing sane code.
Swift, on the other hand, has a breaking change every single major release. If you've ever made a mobile app using Swift and you do maintenance updates at the least, you will absolutely have to put in the leg work to upgrade your Swift code lest you want your code to not build in future Xcode versions. And future Xcode builds will happen, as iOS and macOS update all the time, and so does the framework. For me it feels like insanity.
From what I've seen in Rust, everything seems fair and sensible. I've even dabbled in it and it really doesn't make me sweat bullets like C and C++ usually does. And if this is the approach Mozilla are going to take, then I agree with them.
I know this thread is seven months old, but I've just encountered this on /r/rust. A user's code was presumably correct and used to compile. After the 1.36.0 release, it stopped compiling despite being correct. A person probably working for one of the Rust Teams reminds that:
This made me think of you and this thread, so I decided to share.
Thanks! Awesome of you to add to the thread.
I've been writing rust more and more since this thread was fresh. I still haven't personally been burned by this "wiggle room" philosophy.
My only complaint it's that I wish for a comprehensive source on the borrow checker. I frequently feel blindsided by related compiler errors. There are tricks like wrapping certain fields in an option so that you can take ownership in a
Dropimplementation. All of those should be compiled into a cheat sheet.I disagree, and I particularly disagree given the content of this article: New Rust features are opt-in.
I really want to try using Rust for web stuff but I spent weeks trying to work out how to get Rocket to connect to postgres and then every time I resumed work on it I needed to update to a new version of rust nightly which would break everything and I'd end up spending the day trying to unbreak it.
Still super excited to use it one day but I think the libraries need more work. I might look in to it for writing native extensions for my rails app though.
Rocket looks interesting, but it takes a long time to get a web framework to the point where it's fun and easy to use. Personally I haven't touched it at all.
From my abandoned web project, Rocket is what I would call good, but only through very gritted teeth. The biggest problem I had with it was some very vague documentation. But vague documentation is a huge problem with basically any cutting edge software package.
If they had excellent documentation, I would both unclench my teeth and briefly consider calling it great.
I like Rust's way of adding keywords, as compared to C's.
With C's way, every identifier that begins with an underscore followed by a capital letter is reserved as a future keyword. Then, when C wants to add a new keyword (like, let's say,
noreturn), they first define_Noreturn, which is already reserved, then they add a standardnoreturn.hwhich consists of a single line:That way, old code, which may use
noreturnas a variable name, is unaffected, because it doesn't include the header file. No code just has to#include <noreturn.h>and all is well.It works very well, but it feels a little awkward.
Rust's system: If you want 2018 keywords, compile as 2018 code. If you don't, compile as 2015 code. Seems much simpler.
A lot of people will disagree with me, but the more I think about it, the more I agree with some programming language designs that made keywords distinct from identifiers. It can be uppercase for keywords (
IF x <> 0 THEN …), sigils for identifiers (if $x != 0 { …), or some other form of stropping. It makes the code harder to write, but also (again, opinion) easier to read.