I mean, I agree, I understand where the author is coming from. But this, I am sorry to say, really does sound like someone who drank kool-aid, and I think it will be less effective for that reason. I think it is an interesting challenge for Rust people to figure out how to express the same thing in a manner that less triggers kool-aid warnings.
Can we add a disclaimer about how clunky UI and web-service development feels compared to things like django ? Starting from missing crates to unbearable compile times when changing 1 line of code. And error reporting for especially the paths where you can’t really handle all failures (UI stuff with lazy initialized things). Thinking about a .clone() and restructuring stuff just to avoid it when using parts of your initial configuration struct at different places in the program, while it wouldn’t matter at all in other langs? These are parts where I dread using rust. I like the feeling of how perfect it can feel to have it written in rust. But at the same time I look at ~2Gb of build artifacts for ~300 dependencies to get a comparable web-service with 5 endpoints and a DBMS connection to run. The resulting debug ELF being ~150MB. (Or 15 minutes of release build time for ~9MB ELF)
I know the tradeoffs, I know how unfair this comparison is and how I could “just” use django. But why wouldn’t I want the speed and safety of rust? This is simply the experience I get in the end, technical reasons or not.
Maybe OPs opinion will change in ~3 years? Probably related to the types of application they write. At least to me rust is still in my heart after 6 years and still in my toolbox. But I enjoy writing programs in languages where I’m not forced to care about every None or Err. Where compilation time is instant and I’m not the early adopter of crates that are pretty much finished in other languages.
I think the question of ‘what is my alternative?’ is a helpful framing. If Django is a reasonable alternative, you probably shouldn’t be using Rust for all of the reasons you just listed and more.* I really like using Rust because my only alternative is C++, and C++ is…
Not that you should 100% be using Django, but something in the Django, Rails, Go, etc family would be a better fit.
These complaints (which are real) feel pretty similar to issues I’ve run into when using Django. Dealing with dependencies in Django projects, like in any python project, can be a time-consuming pain in the ass. I’ve definitely seen Django projects many megabytes in size - not to mention the size of the Python interpreter you need to run them (not to mention debugging problems with selecting the right Python interpreter version!). To be clear, I personally like Django, and think it’s an eminently reasonable choice of web framework. But I don’t think it’s dramatically better than the Rust frameworks I’ve used.
But I enjoy writing programs in languages where I’m not forced to care about every None or Err.
If you’re not forced to care about None and Err values explicitly in the code, you’ll be forced to care about them when you try to do an operation on some value that turns out to be a null when you weren’t expecting it and throws a runtime error. Having to manually unpack an Option<T> replaces TypeError: Cannot read property 'x' of undefined (or whatever your language’s equivalent is).
I think rust triggers my struggle for perfection. I can simply ignore failures in django by letting it crash and dealing with it or leaving it as a crash. While in rust I always try to make it correct and handle all of these cases as I see every possible “exception” point. And this is the part where just setting up a mockup in django for some lightweight ERP system or data management feels so light, so easy. And as my naming suggests I probably won’t build something that requires high correctnes this way in django. But in rust I get the feeling that there’s no other way than the correct, perfect one, if you don’t want to unwrap() at every point.
Declaring some stuff as lateinit var in android and then later initialize it. Just bind it when you need it and it’ll probably be fine, don’t handle each possible case of “it should be initialized because we’re past point X but you can’t be sure”*. Something you won’t do in rust and where the same program in the same setting would be just so ugly.
This also comes down to the last point: Many things like UI just feel clunky because they’re build for different languages or rather idioms. It’s ok to just write loosely coupled UIs in android that get initiated from design sheets during runtime and then bind to them. But you won’t do that in rust. You’ll probably use iced and bake the whole UI declaration and logic into one program that compiles as one big thing (thus taking seconds for a println!() change). Yes its a nice all-in-one binary that runs pretty correct. But I don’t get the feeling that I’ll ever do something serious with this kind of coding style for UI based systems. That I’d have to invest so much more work to reach the same kind of completeness (feature wise, behaviour, look’n feel), reaching the point where its not feeling like a mockup that you won’t ever show to someone that isn’t a CS grad. As if someone would try to write a CMS in assembly, while having seen how fast you get this up with django/rails/cake-php/..
*And yes I hate those NullPointerExceptions and state-loss on rotation. But I like at how many places I don’t have to code around possible nulls. Even though I’m using kotlin to get a little more awareness of possible nulls.
Returning Optional[T] in python function signature helps your syntax checker mark your code with a warning. Syntax checkers are even clever enough to stop warning you after you add the None check. Never had an issue with evaluating None.x after python 3.6.x
Yup, and this is effectively the same thing as matching on an Option type in a language like Rust with ML-style types, just retrofitted onto Python’s existing syntax and semantics. Using a type checker in modern Python makes you have to care about Nones, because that affects whether the type-checker will pass or fail on your code.
I actually enjoyed this behavior for several years while using kotlin with the jetbrains community edition IDE. Very nice to see other languages adopting it where their type system allows.
If the author is here and open to changing the post title, Rust is for everyone, and good for professionals too! The title as is sounds like it may be exclusionary toward people who don’t identity as professionals, or feel intimidated by Rust, which is contrary to Rust’s core goal of opening up systems programming to everyone!
I appreciate the constructive feedback and can see your point. Choosing titles is hard. I too was concerned about the exclusionary potential for the title. However, I thought I had it sufficiently mitigated by the introduction paragraphs. Apparently I could have done better.
I’m not going to change the title of this post because I don’t want to deal with the hassle of rewriting URLs. However, I will try to consider your feedback for future posts I author.
I’ve programmed in the following languages: C, C++ (only until C++11), C#, Erlang, Go, JavaScript, Java, Lua, Perl, PHP, Python, Ruby, Rust, shell, SQL, and Verilog.
To me, Rust introduced a number of new concepts, like match for control flow, enums as algebraic types, the borrow checker, the Option and Result types/enums and more.
My usual way of framing it is “Rust is an industrial programming language”. That leaves the door open for practitioners of all kinds. It’s more like a cars are (in general) a utility and not a plaything or research endeavor, but are open to enthusiasts and amateur practitioners as well.
Thanks! I liked the disclaimer, and think predicting how people will respond can be tough. Appreciate you putting in the time to write this, and agree that Rust can be used in professional / production environments successfully, and that it can feel like a breath of fresh air for many!
Or, alternately, when someone writes 13,000 words about how nice Rust is, how ergonomic and human-centric and welcoming and humane the language and tooling and community are, they can keep the title without someone telling them they’re maybe being exclusionary.
It’s criticism, but just because it’s delivered politely does not mean it is constructive. There is a cost to spending the effort to write a thirteen thousand word love letter to a language, just to have someone nipping at your ankles about how the first four words might exclude someone. Objectively speaking, this is a blogger that Rust would benefit from sticking around – but what is the signal they’ve received here?
Recently a friend submitted his static site generator which is optimised for math heavy sites on HN.
He made the fatal mistake of calling it “beautiful” in the description and the amount of hangups that people had. It was done in a mostly polite manner, but the amount of time and energy wasted in discussing just the first sentence with barely any technical discussion of the internals, was a form of pathological bikeshedding that I was surprised to see. It was just that “nipping at his ankles” as you’ve described, which can take its toll.
It was done in a mostly polite manner, but the amount of time and energy wasted in discussing just the first sentence with barely any technical discussion of the internals, was a form of pathological bikeshedding that I was surprised to see. It was just that “nipping at his ankles” as you’ve described, which can take its toll.
Agreed. Yet here we are- arguing about arguing. I need a life… xD
Right, in my experience, HN often attracts uninteresting, unhelpful, or even mean-spirited commentary. Sometimes I am surprised by the opposite, though. In any case, understanding the dynamic really helps. A lot of commentary, seems to me, are upset at some level in some way and take it out in their commentary.
The author thanked them and described the feedback as constructive. So if they feel like they’ve taken something away from it, who are we to decide otherwise? My own hopefully constructive feedback here is that this subthread strikes me as projecting conflict into an interaction between two parties who themselves seem to have had a positive experience with it.
Yeah, I get where you’re coming from and I don’t really disagree.
But I also think that the person who offered the criticism is just trying to help the author get more views.
It’s fair to suggest that we all should consider our criticisms carefully, though. Because you’re right- if the criticism isn’t that important, we may just be disincentivizing someone from future contributions.
I also wonder if you’re maybe reading a little too hard into the choice of the word “exclude” used by the criticizer, though… I think that term has a little bit of extra charge and connotation in today’s social environment and I don’t believe the criticizer meant it in that way. I think they simply meant that a person who isn’t writing enterprise software might pass over the article because they believe they aren’t the target audience. I agree with that conclusion as well, because I do write enterprisey software and I thought the article was going to be about that specific point of view- I thought I would see arguments about productivity and developer costs and cross-platform support and other less-sexy stuff. But, it was really- as you said, just a love letter to everything about Rust.
FWIW first third of those thousands of words is irellevant chitchat. The First actual claim on why is rust good is rust makes me giddy. I’m not sure “giddy” describes profesionals. It’s not no, but for me definitely not a yes either - giddy is just…giddy. Then all the technical points, borrow checkers, race conditions and whatnot - none of that tells me why is it a thing for professionals.
What I mean is, I don’t know if rust is for pros or not, I just think that the title is a bit click-baity, and “rust is good for everyone, even pros” like alilleybrinker suggested would work much better.
The First actual claim on why is rust good is rust makes me giddy. I’m not sure “giddy” describes profesionals.
There’s a layer of extra irony here in that the word “amateur” comes from a root meaning “love”; in other words, amateurs are people who do something because they love it. So taken literally, this is very unprofessional!
It seems relevant to note that the author does address this in the post itself:
The statement Rust is for Professionals does not imply any logical variant thereof. e.g. I am not implying Rust is not for non-professionals. Rather, the subject/thesis merely defines the audience I want to speak to: people who spend a lot of time authoring, maintaining, and supporting software and are invested in its longer-term outcomes.
Yes, except the title doesn’t have a disclaimer, and will be taken in the way they say they don’t want. Rather than leaving it ambiguous, they could change the title to remove the ambiguity.
This side-steps the issue “people don’t read past the title” - which is the real problem. It’s bad, and unrealistic, to expect every person who writes on the internet to tailor each individual sub-part of an article (including the title) to an audience that is refusing to read the (whole) article itself before making judgements or assumptions. That’s purely the fault of the audience, not the writer, and changing the article title is merely addressing the symptoms, instead of the root problem, which will allow it to just become worse.
We have an expression “judging a book by its cover” specifically for this scenario, and in addition to that, any reasonably-thoughtful reader is aware that, once a sufficient amount of context has been stripped away, any statement loses its meaning - which logically implies that full context must be absorbed before the reader has any chance of understanding the author’s intended meaning.
Agreed. It’s a poor choice for a title, even with a disclaimer. In fact, that he knew he needed a disclaimer should have been a big clue that it wasn’t a good title.
A better title would be: “Professional devs should love Rust”, or “Rust isn’t just for enthusiasts and hipsters”
Responses like this make me hesitant to try Rust, because they make me feel that I’d have to tiptoe around every word I put into a chat room, issue tracker, or mailing list.
I’m not sure this is a Rust issue as much as a general issue of recent years. Be delicate and excessively sensitive about everything because everyone’s an egg shell. It’s contrary to anti-fragility which I would suggest is a far better approach; and the opposite approach. “Rust is for professionals” would have had me targeting Rust so that I could level up, not scare me away. Show me a challenge,
I used rust for three years outside of work, but I’m afraid I stopped last year because I find it too big for a hobbyist. If I used it all day every day - no problem. It’s a great language, but I agree with the title.
This was my first thought, as well, before even reading the article. Obviously I should read before judging, but the author may want to consider that the title could turn away potential readers.
I made the same mistake in my own My staff engineering reading list. There was no reason for me to needlessly exclude people earlier in their careers from my list.
And it’s good feedback that the author of this piece may not want to unintentionally exclude people from their article.
Since the author is here, I’ll say: if you know that the big gap in your programming language repertoire is a haskell/scala like language, and you are giddy with excitement about rust’s type inference, memory safety, variant types, and option/result types, you should really check out a haskell/scala type language.
Many of the new concepts weren’t novel to Rust. But considering I’ve had exposure to many popular programming languages, the fact many were new to me means these aren’t common features in mainstream languages.
My takeaways from this is that:
We need a better/different term for “mainstream languages” that includes the many languages that have those things
Programmers really need to explore PLs a bit more
“Mainstream languages” are really far behind and programmers are hamstringing themselves by sticking with them
I hope that you would agree that if a Rust program is a confused deputy, then that program is buggy. We should be careful to not imagine Rust as the ultimate language.
C was released in 1972 and wasn’t standardized until 1989, 17 years later. Rust was released 6 years ago. So I’d say check back in about 5 years or so, but I wouldn’t expect to see a standard, if at all, for at least 10 years. Standards come with costs and I don’t know if the Rust organization is willing to pay them. But there is some effort underway: https://ferrous-systems.com/blog/sealed-rust-the-pitch/
Thanks for the clear answer, the time frame is more or less what I expected. We will see if Rust is still around it 10 years or goes the way of every very promising language that fixes the problems of C.
Rust 1.0 has a stability guarantee and is intended to last more than 30 years.
Note that “won’t change” here means that a Rust compiler from 30 years in the future will still accept source code written today — with a disclaimer that small code changes may be necessary due to language bug fixes. In practice it’s similar to amount of changes needed in C for GCC upgrades.
However, “won’t change” doesn’t meant that Rust is going to sit still and not improve or fix anything at all for the next 30 years, in the way that C89 and C99 are treated as the final C versions.
In many ways Rust is already more stable and portable than C, because Rust’s stability and portability guarantee covers the whole language, a larger standard library, compiler flags, and the build system.
The scope of the C standard is minimal, so C programs also need to depend on things that are not standardized, and are not stable. The C standard doesn’t change, but your C compiler, C system headers, C build tools are not standardized and do change.
This I have an issue with. Without a formal specification like C has, everything done by the compiler is undefined behaviour. What if the rustc compiler is unobtainable in 30 years? Without a specification, how could other implementations take its place and guarantee that their programs will work the same way?
In many ways Rust is already more stable and portable than C
This is completely false. Rust only has tier 1 support for x86 and ARM (https://doc.rust-lang.org/nightly/rustc/platform-support.html). That is by no means portable. Additionally, since it uses LLVM, it doesn’t work on many non-mainstream operating systems like Plan 9.
The C standard doesn’t change, but your C compiler, C system headers, C build tools are not standardized and do change.
My C compiler and build tools have options for conforming to the standard I wish (-std=c99 -pedantic). Rust doesn’t even have a standard. Personally, I don’t use compiler extensions like #pragma once since I want to confirm to a standard and want my programs to run on as many platforms as possible.
Additionally, since it uses LLVM, it doesn’t work on many non-mainstream operating systems like Plan 9.
This is the paradox: compatibility with Plan 9 is touted as C’s virtue, but fragmentation and poor implementations that make Windows support painful are not C’s problem (swept under “Microsoft sucks” carpet).
In my day-to-day programming painless support one of the most popular platforms in the world makes my programs more portable than ability to compile for abandoned platforms and discontinued architectures.
Without a formal specification like C has, everything done by the compiler is undefined behaviour
I’m not sure if you’re being disingenuous with usage of this term here. We’re talking in the context of the C spec, where “undefined behavior” doesn’t mean colloquial “not defined”, but rather a case that is precisely defined by the spec, and is forbidden.
In C-speak, Rust is implementation-defined. It is precisely defined in the form of rustc’s source code. In practice there’s also Rust Reference, RFCs, and other documentation.
My C compiler and build tools have options for conforming to the standard I wish (-std=c99 -pedantic)
These flags are not part of the C standard. They are implementation-specific. Standard C compilers don’t have to have them. This has practical consequences, e.g. my C build scripts have been broken by clang changing its flags, and don’t work with ICC and MSVC. C build systems are at best de-facto standards, and have very poor portability, especially when dependencies are involved.
This is in contrast with Rust where e.g. support for -W bad_styleis part of Rust’s stability guarantee. Cargo has the stability guarantee too, and is the same on all platforms.
These flags are not part of the C standard. They are implementation-specific.
I’m aware. I wasn’t stating otherwise. I was using this as an example since most people use GCC/Clang which have these settings. Other compilers simply follow the standard automatically.
This is the paradox: compatibility with Plan 9 is touted as C’s virtue, but fragmentation and poor implementations that make Windows support painful are not C’s problem (swept under “Microsoft sucks” carpet).
I don’t develop on or for Windows since it isn’t practical to me and I don’t really care. But people I know and chat with have no problem compiling C on Windows.
my C build scripts have been broken by clang changing its flags, and don’t work with ICC and MSVC.
This is precisely why I stick to standard-conforming practice and avoid non-standard settings. If you are doing something that isn’t standardized, you have no guarantee it will work on other platforms/in the future.
everything done by the compiler is undefined behaviour.
On the contrary, everything done by the compiler is defined to be correct behavior (apart from regressions and the other documented exceptions to the guarantees), while anything done by a C compiler may or may not be undefined behavior depending on how correctly they implemented the standard. Backwards compatibility guarantees are really better than standards at this. (The flip side is that it’s easier to match a standard than to match an existing implementation if you’re writing a new version, but that isn’t because the behavior is undefined, it’s because the behavior is well defined)
What if the rustc compiler is unobtainable in 30 years
What if a C standard is unobtainable in 30 years? In either case society has collapsed and you have better things to worry about. The C standard is far less available than the rust compiler because it’s proprietary and not that many people pay for it.
This is completely false
No, it’s not, it’s a difference in perspective. In many ways C is not portable because so much of the behavior is architecture specific. You can write C code for any architecture, but not the same C code. Rust supports less architectures, but lets you run the same rust code with reasonably confidence on different architectures.
On the contrary, everything done by the compiler is defined to be correct behavior
This would mean that to implement a new compiler, you would have to check every single edge case to figure out what is excluded from this list of “correct behaviour”.
The C standard is far less available than the rust compiler because it’s proprietary and not that many people pay for it.
I agree that the fact that a standard is proprietary is bad. But to say that its availability is poor is not true. From a quick search engine search I’ve already found multiple sources to read it for free:
More importantly, its distribution is decentralized as opposed to the Rust compiler.
You can write C code for any architecture, but not the same C code.
This is true for those cases where architecture specific code has to be executed. However, this is true for all programming languages and not limited to just C.
This would mean that to implement a new compiler, you would have to check every single edge case to figure out what is excluded from this list of “correct behaviour”.
Indeed… that’s the tradeoff you ask for when you ask for backwards compatibility.
From a quick search engine search I’ve already found multiple sources to read it for free:
These are either drafts and not the actual standard, outdated, really outdated, or being distributed illegally. Generally at least two out of the four (which is why I listed really outdated separately from outdated).
More importantly, its distribution is decentralized as opposed to the Rust compiler.
You have this backwards. The rust compiler is distributed via git. I have multiple copies sitting on computers just because. So does anyone else who has ever worked with it. I’m not entirely sure if the rust-src rust component is enough to build rustc, but I wouldn’t be surprised if it is, in which case so does the average user of rust. I have the rights and the ability to distribute this. The C standard is only legally distributed by two groups, iso and iec (edit: Or some other groups for older versions, again see the wiki, but I’ve never seen a license which allows me to freely redistribute it).
This is true for those cases where architecture specific code has to be executed. However, this is true for all programming languages and not limited to just C.
Emphasis added to the above, that parts not right for C. It’s true that architecture specific code does have to be executed and it’s by definition architecture specific in every language. However in C lots of other code is architecture specific when it has no need to be so. The size of basically all the int types, for example.
I will not argue against the standard criticism, I agree that the proprietary nature of it is bad.
I think this discussion is based on a misunderstanding that Rust is trying to fill the same space as C. Rust is focused on providing new features to the world of systems-programming, neglecting stability in the process in favour of exploring new ground quickly. The people who write C (like antt, the guy who started this comment thread) find its stability to be a feature and don’t want their language to change.
The size of basically all the int types, for example.
I was mainly thinking about changes in terms of stability, not regarding the spec issue.
What I mean is that Rust is adding new features to its language constantly and is growing at a rapid rate. Even if its ideas aren’t new, they are new to the field of systems development which has been dominated by C and C++ the past years.
Rust makes frequent small releases, instead of making infrequent big releases. This doesn’t affect rate of change of the language — features still take years to develop, and are added very conservatively. If Rust used C-like release cadence, it’d be Rust15 and Rust18, with Rust21 in the works.
Rust releases cover not only the language, but also its compiler implementation, libraries, and the build system. Nobody complains that C is growing constantly when GCC or CMake make new releases, or when POSIX adds new functions.
There’s an assumption that Rust 1.0 was a complete language, and now it’s adding useless junk. In fact 1.0 was a very bare-bones MVP, and it’s mostly catching up to what a decent language needs to be. For example, Rust 1.0 couldn’t clone an array larger than 32 elements, and it took years to add features to make it possible. Most recent release adds ability to convert char to an integer (wow!) and to make a pointer to a field of a struct (what a radical new feature!)
Majority of Rust changes are on such trivial scale, and actual users don’t complain there’s too much, they complain “I need to use a 3rd-party dependency to cast an integer to an enum? WTF? Why isn’t it built-in yet!?”
Judging from the 5 year recap of the Rust language (https://blog.rust-lang.org/2020/05/15/five-years-of-rust.html) the language added at least 1 feature every year since 2015. This is more than C, even with its infrequent release schedule, which averages about 0.7 features a year (judging from the list of new features per standard on their respective wikipedia pages), with most people sticking to older versions of C (which are standardized and forever accessible, unlike the Rust ecosystem which for the most part depends on specific compiler versions).
This has not been my experience in the slightest. Even porting relatively simple command line programs that don’t interact with the OS past opening files from windows to linux often seems to involve mucking with windows header files, and changes the size of longs which are still in use in some programs for some inconceivable reason. Compatibility between things like 8 bit micro controllers and x64 linux is far worse.
Perfectly written C code is probably not that bad, especially if the author made use of fixed size ints. In practice, if I pick up some random persons c code, it is that bad.
These are not changes in C, these are changes in the apis between platforms. If you limit your program to getc and putc then programs need no modification in my experience.
Good callout to not fall into the trap of being too confident in your code. I haven’t thought of this before, but imagine it could be easy to forget that there may still be pockets of unsafety or logic errors present.
I mean, I agree, I understand where the author is coming from. But this, I am sorry to say, really does sound like someone who drank kool-aid, and I think it will be less effective for that reason. I think it is an interesting challenge for Rust people to figure out how to express the same thing in a manner that less triggers kool-aid warnings.
Yeah it sounds like the perfect ad-whitepaper.
Can we add a disclaimer about how clunky UI and web-service development feels compared to things like django ? Starting from missing crates to unbearable compile times when changing 1 line of code. And error reporting for especially the paths where you can’t really handle all failures (UI stuff with lazy initialized things). Thinking about a .clone() and restructuring stuff just to avoid it when using parts of your initial configuration struct at different places in the program, while it wouldn’t matter at all in other langs? These are parts where I dread using rust. I like the feeling of how perfect it can feel to have it written in rust. But at the same time I look at ~2Gb of build artifacts for ~300 dependencies to get a comparable web-service with 5 endpoints and a DBMS connection to run. The resulting debug ELF being ~150MB. (Or 15 minutes of release build time for ~9MB ELF)
I know the tradeoffs, I know how unfair this comparison is and how I could “just” use django. But why wouldn’t I want the speed and safety of rust? This is simply the experience I get in the end, technical reasons or not.
Maybe OPs opinion will change in ~3 years? Probably related to the types of application they write. At least to me rust is still in my heart after 6 years and still in my toolbox. But I enjoy writing programs in languages where I’m not forced to care about every None or Err. Where compilation time is instant and I’m not the early adopter of crates that are pretty much finished in other languages.
I think the question of ‘what is my alternative?’ is a helpful framing. If Django is a reasonable alternative, you probably shouldn’t be using Rust for all of the reasons you just listed and more.* I really like using Rust because my only alternative is C++, and C++ is…
These complaints (which are real) feel pretty similar to issues I’ve run into when using Django. Dealing with dependencies in Django projects, like in any python project, can be a time-consuming pain in the ass. I’ve definitely seen Django projects many megabytes in size - not to mention the size of the Python interpreter you need to run them (not to mention debugging problems with selecting the right Python interpreter version!). To be clear, I personally like Django, and think it’s an eminently reasonable choice of web framework. But I don’t think it’s dramatically better than the Rust frameworks I’ve used.
If you’re not forced to care about
NoneandErrvalues explicitly in the code, you’ll be forced to care about them when you try to do an operation on some value that turns out to be anullwhen you weren’t expecting it and throws a runtime error. Having to manually unpack anOption<T>replacesTypeError: Cannot read property 'x' of undefined(or whatever your language’s equivalent is).I think rust triggers my struggle for perfection. I can simply ignore failures in django by letting it crash and dealing with it or leaving it as a crash. While in rust I always try to make it correct and handle all of these cases as I see every possible “exception” point. And this is the part where just setting up a mockup in django for some lightweight ERP system or data management feels so light, so easy. And as my naming suggests I probably won’t build something that requires high correctnes this way in django. But in rust I get the feeling that there’s no other way than the correct, perfect one, if you don’t want to unwrap() at every point.
Declaring some stuff as
lateinit varin android and then later initialize it. Just bind it when you need it and it’ll probably be fine, don’t handle each possible case of “it should be initialized because we’re past point X but you can’t be sure”*. Something you won’t do in rust and where the same program in the same setting would be just so ugly.This also comes down to the last point: Many things like UI just feel clunky because they’re build for different languages or rather idioms. It’s ok to just write loosely coupled UIs in android that get initiated from design sheets during runtime and then bind to them. But you won’t do that in rust. You’ll probably use iced and bake the whole UI declaration and logic into one program that compiles as one big thing (thus taking seconds for a
println!()change). Yes its a nice all-in-one binary that runs pretty correct. But I don’t get the feeling that I’ll ever do something serious with this kind of coding style for UI based systems. That I’d have to invest so much more work to reach the same kind of completeness (feature wise, behaviour, look’n feel), reaching the point where its not feeling like a mockup that you won’t ever show to someone that isn’t a CS grad. As if someone would try to write a CMS in assembly, while having seen how fast you get this up with django/rails/cake-php/..*And yes I hate those NullPointerExceptions and state-loss on rotation. But I like at how many places I don’t have to code around possible nulls. Even though I’m using kotlin to get a little more awareness of possible nulls.
Returning Optional[T] in python function signature helps your syntax checker mark your code with a warning. Syntax checkers are even clever enough to stop warning you after you add the None check. Never had an issue with evaluating None.x after python 3.6.x
Yup, and this is effectively the same thing as matching on an
Optiontype in a language like Rust with ML-style types, just retrofitted onto Python’s existing syntax and semantics. Using a type checker in modern Python makes you have to care aboutNones, because that affects whether the type-checker will pass or fail on your code.I actually enjoyed this behavior for several years while using kotlin with the jetbrains community edition IDE. Very nice to see other languages adopting it where their type system allows.
not joking, you worded perfectly what i was imprecisely thinking
If the author is here and open to changing the post title, Rust is for everyone, and good for professionals too! The title as is sounds like it may be exclusionary toward people who don’t identity as professionals, or feel intimidated by Rust, which is contrary to Rust’s core goal of opening up systems programming to everyone!
I, the author, am here.
I appreciate the constructive feedback and can see your point. Choosing titles is hard. I too was concerned about the exclusionary potential for the title. However, I thought I had it sufficiently mitigated by the introduction paragraphs. Apparently I could have done better.
I’m not going to change the title of this post because I don’t want to deal with the hassle of rewriting URLs. However, I will try to consider your feedback for future posts I author.
I appreciated the way you took the feedback. Just wanted to say thanks for listening and considering it.
How did you use Erlang without pattern matching?
I think the order is alphabetical so its possible that author used Erlang after he learned Rust.
Have a nice day!
Doesn’t add up, he says that Rust introduced pattern matching to him :-)
My usual way of framing it is “Rust is an industrial programming language”. That leaves the door open for practitioners of all kinds. It’s more like a cars are (in general) a utility and not a plaything or research endeavor, but are open to enthusiasts and amateur practitioners as well.
Thanks! I liked the disclaimer, and think predicting how people will respond can be tough. Appreciate you putting in the time to write this, and agree that Rust can be used in professional / production environments successfully, and that it can feel like a breath of fresh air for many!
Or, alternately, when someone writes 13,000 words about how nice Rust is, how ergonomic and human-centric and welcoming and humane the language and tooling and community are, they can keep the title without someone telling them they’re maybe being exclusionary.
It’s constructive criticism. If you post something on the public web, it’s fair game to criticize it- especially if done in a polite manner.
It’s criticism, but just because it’s delivered politely does not mean it is constructive. There is a cost to spending the effort to write a thirteen thousand word love letter to a language, just to have someone nipping at your ankles about how the first four words might exclude someone. Objectively speaking, this is a blogger that Rust would benefit from sticking around – but what is the signal they’ve received here?
Agree 💯.
Recently a friend submitted his static site generator which is optimised for math heavy sites on HN.
He made the fatal mistake of calling it “beautiful” in the description and the amount of hangups that people had. It was done in a mostly polite manner, but the amount of time and energy wasted in discussing just the first sentence with barely any technical discussion of the internals, was a form of pathological bikeshedding that I was surprised to see. It was just that “nipping at his ankles” as you’ve described, which can take its toll.
Vowed to never take that site seriously again.
Agreed. Yet here we are- arguing about arguing. I need a life… xD
Right, in my experience, HN often attracts uninteresting, unhelpful, or even mean-spirited commentary. Sometimes I am surprised by the opposite, though. In any case, understanding the dynamic really helps. A lot of commentary, seems to me, are upset at some level in some way and take it out in their commentary.
The author thanked them and described the feedback as constructive. So if they feel like they’ve taken something away from it, who are we to decide otherwise? My own hopefully constructive feedback here is that this subthread strikes me as projecting conflict into an interaction between two parties who themselves seem to have had a positive experience with it.
Yeah, I get where you’re coming from and I don’t really disagree.
But I also think that the person who offered the criticism is just trying to help the author get more views.
It’s fair to suggest that we all should consider our criticisms carefully, though. Because you’re right- if the criticism isn’t that important, we may just be disincentivizing someone from future contributions.
I also wonder if you’re maybe reading a little too hard into the choice of the word “exclude” used by the criticizer, though… I think that term has a little bit of extra charge and connotation in today’s social environment and I don’t believe the criticizer meant it in that way. I think they simply meant that a person who isn’t writing enterprise software might pass over the article because they believe they aren’t the target audience. I agree with that conclusion as well, because I do write enterprisey software and I thought the article was going to be about that specific point of view- I thought I would see arguments about productivity and developer costs and cross-platform support and other less-sexy stuff. But, it was really- as you said, just a love letter to everything about Rust.
I felt this lead-in made it a friendly suggestion and not harsh:
FWIW first third of those thousands of words is irellevant chitchat. The First actual claim on why is rust good is rust makes me giddy. I’m not sure “giddy” describes profesionals. It’s not no, but for me definitely not a yes either - giddy is just…giddy. Then all the technical points, borrow checkers, race conditions and whatnot - none of that tells me why is it a thing for professionals.
What I mean is, I don’t know if rust is for pros or not, I just think that the title is a bit click-baity, and “rust is good for everyone, even pros” like alilleybrinker suggested would work much better.
There’s a layer of extra irony here in that the word “amateur” comes from a root meaning “love”; in other words, amateurs are people who do something because they love it. So taken literally, this is very unprofessional!
It seems relevant to note that the author does address this in the post itself:
Yes, except the title doesn’t have a disclaimer, and will be taken in the way they say they don’t want. Rather than leaving it ambiguous, they could change the title to remove the ambiguity.
This side-steps the issue “people don’t read past the title” - which is the real problem. It’s bad, and unrealistic, to expect every person who writes on the internet to tailor each individual sub-part of an article (including the title) to an audience that is refusing to read the (whole) article itself before making judgements or assumptions. That’s purely the fault of the audience, not the writer, and changing the article title is merely addressing the symptoms, instead of the root problem, which will allow it to just become worse.
We have an expression “judging a book by its cover” specifically for this scenario, and in addition to that, any reasonably-thoughtful reader is aware that, once a sufficient amount of context has been stripped away, any statement loses its meaning - which logically implies that full context must be absorbed before the reader has any chance of understanding the author’s intended meaning.
People should not have to write hyper-defensively on the internet, or anywhere, because civil discussion collapses when your audience isn’t acting honestly.
Reading the title and judging before reading the content itself is not acting honestly.
Thank you for writing this. I’m sick of how much culture is warped by toxic social media sites.
Agreed. It’s a poor choice for a title, even with a disclaimer. In fact, that he knew he needed a disclaimer should have been a big clue that it wasn’t a good title.
A better title would be: “Professional devs should love Rust”, or “Rust isn’t just for enthusiasts and hipsters”
I don’t disagree.
Responses like this make me hesitant to try Rust, because they make me feel that I’d have to tiptoe around every word I put into a chat room, issue tracker, or mailing list.
I’m not sure this is a Rust issue as much as a general issue of recent years. Be delicate and excessively sensitive about everything because everyone’s an egg shell. It’s contrary to anti-fragility which I would suggest is a far better approach; and the opposite approach. “Rust is for professionals” would have had me targeting Rust so that I could level up, not scare me away. Show me a challenge,
I used rust for three years outside of work, but I’m afraid I stopped last year because I find it too big for a hobbyist. If I used it all day every day - no problem. It’s a great language, but I agree with the title.
This was my first thought, as well, before even reading the article. Obviously I should read before judging, but the author may want to consider that the title could turn away potential readers.
I made the same mistake in my own My staff engineering reading list. There was no reason for me to needlessly exclude people earlier in their careers from my list.
And it’s good feedback that the author of this piece may not want to unintentionally exclude people from their article.
Since the author is here, I’ll say: if you know that the big gap in your programming language repertoire is a haskell/scala like language, and you are giddy with excitement about rust’s type inference, memory safety, variant types, and option/result types, you should really check out a haskell/scala type language.
My takeaways from this is that:
I hope that you would agree that if a Rust program is a confused deputy, then that program is buggy. We should be careful to not imagine Rust as the ultimate language.
Does rust have a well defined standard that won’t change in the next 30 years?
Because that’s the main selling point of C for me.
No, although a specification is being worked on.
C was released in 1972 and wasn’t standardized until 1989, 17 years later. Rust was released 6 years ago. So I’d say check back in about 5 years or so, but I wouldn’t expect to see a standard, if at all, for at least 10 years. Standards come with costs and I don’t know if the Rust organization is willing to pay them. But there is some effort underway: https://ferrous-systems.com/blog/sealed-rust-the-pitch/
Thanks for the clear answer, the time frame is more or less what I expected. We will see if Rust is still around it 10 years or goes the way of every very promising language that fixes the problems of C.
See you in 10 years!
Rust 1.0 has a stability guarantee and is intended to last more than 30 years.
Note that “won’t change” here means that a Rust compiler from 30 years in the future will still accept source code written today — with a disclaimer that small code changes may be necessary due to language bug fixes. In practice it’s similar to amount of changes needed in C for GCC upgrades.
However, “won’t change” doesn’t meant that Rust is going to sit still and not improve or fix anything at all for the next 30 years, in the way that C89 and C99 are treated as the final C versions.
In many ways Rust is already more stable and portable than C, because Rust’s stability and portability guarantee covers the whole language, a larger standard library, compiler flags, and the build system.
The scope of the C standard is minimal, so C programs also need to depend on things that are not standardized, and are not stable. The C standard doesn’t change, but your C compiler, C system headers, C build tools are not standardized and do change.
This I have an issue with. Without a formal specification like C has, everything done by the compiler is undefined behaviour. What if the rustc compiler is unobtainable in 30 years? Without a specification, how could other implementations take its place and guarantee that their programs will work the same way?
This is completely false. Rust only has tier 1 support for x86 and ARM (https://doc.rust-lang.org/nightly/rustc/platform-support.html). That is by no means portable. Additionally, since it uses LLVM, it doesn’t work on many non-mainstream operating systems like Plan 9.
My C compiler and build tools have options for conforming to the standard I wish (-std=c99 -pedantic). Rust doesn’t even have a standard. Personally, I don’t use compiler extensions like
#pragma oncesince I want to confirm to a standard and want my programs to run on as many platforms as possible.This is the paradox: compatibility with Plan 9 is touted as C’s virtue, but fragmentation and poor implementations that make Windows support painful are not C’s problem (swept under “Microsoft sucks” carpet).
In my day-to-day programming painless support one of the most popular platforms in the world makes my programs more portable than ability to compile for abandoned platforms and discontinued architectures.
I’m not sure if you’re being disingenuous with usage of this term here. We’re talking in the context of the C spec, where “undefined behavior” doesn’t mean colloquial “not defined”, but rather a case that is precisely defined by the spec, and is forbidden.
In C-speak, Rust is implementation-defined. It is precisely defined in the form of rustc’s source code. In practice there’s also Rust Reference, RFCs, and other documentation.
These flags are not part of the C standard. They are implementation-specific. Standard C compilers don’t have to have them. This has practical consequences, e.g. my C build scripts have been broken by clang changing its flags, and don’t work with ICC and MSVC. C build systems are at best de-facto standards, and have very poor portability, especially when dependencies are involved.
This is in contrast with Rust where e.g. support for
-W bad_styleis part of Rust’s stability guarantee. Cargo has the stability guarantee too, and is the same on all platforms.I’m aware. I wasn’t stating otherwise. I was using this as an example since most people use GCC/Clang which have these settings. Other compilers simply follow the standard automatically.
I don’t develop on or for Windows since it isn’t practical to me and I don’t really care. But people I know and chat with have no problem compiling C on Windows.
This is precisely why I stick to standard-conforming practice and avoid non-standard settings. If you are doing something that isn’t standardized, you have no guarantee it will work on other platforms/in the future.
On the contrary, everything done by the compiler is defined to be correct behavior (apart from regressions and the other documented exceptions to the guarantees), while anything done by a C compiler may or may not be undefined behavior depending on how correctly they implemented the standard. Backwards compatibility guarantees are really better than standards at this. (The flip side is that it’s easier to match a standard than to match an existing implementation if you’re writing a new version, but that isn’t because the behavior is undefined, it’s because the behavior is well defined)
What if a C standard is unobtainable in 30 years? In either case society has collapsed and you have better things to worry about. The C standard is far less available than the rust compiler because it’s proprietary and not that many people pay for it.
No, it’s not, it’s a difference in perspective. In many ways C is not portable because so much of the behavior is architecture specific. You can write C code for any architecture, but not the same C code. Rust supports less architectures, but lets you run the same rust code with reasonably confidence on different architectures.
This would mean that to implement a new compiler, you would have to check every single edge case to figure out what is excluded from this list of “correct behaviour”.
I agree that the fact that a standard is proprietary is bad. But to say that its availability is poor is not true. From a quick search engine search I’ve already found multiple sources to read it for free:
http://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
More importantly, its distribution is decentralized as opposed to the Rust compiler.
This is true for those cases where architecture specific code has to be executed. However, this is true for all programming languages and not limited to just C.
Indeed… that’s the tradeoff you ask for when you ask for backwards compatibility.
These are either drafts and not the actual standard, outdated, really outdated, or being distributed illegally. Generally at least two out of the four (which is why I listed really outdated separately from outdated).
Here’s a nice wiki that lists what is available: http://www.iso-9899.info/wiki/The_Standard
You have this backwards. The rust compiler is distributed via git. I have multiple copies sitting on computers just because. So does anyone else who has ever worked with it. I’m not entirely sure if the rust-src rust component is enough to build rustc, but I wouldn’t be surprised if it is, in which case so does the average user of rust. I have the rights and the ability to distribute this. The C standard is only legally distributed by two groups, iso and iec (edit: Or some other groups for older versions, again see the wiki, but I’ve never seen a license which allows me to freely redistribute it).
Emphasis added to the above, that parts not right for C. It’s true that architecture specific code does have to be executed and it’s by definition architecture specific in every language. However in C lots of other code is architecture specific when it has no need to be so. The size of basically all the int types, for example.
I will not argue against the standard criticism, I agree that the proprietary nature of it is bad.
I think this discussion is based on a misunderstanding that Rust is trying to fill the same space as C. Rust is focused on providing new features to the world of systems-programming, neglecting stability in the process in favour of exploring new ground quickly. The people who write C (like antt, the guy who started this comment thread) find its stability to be a feature and don’t want their language to change.
This is true for vanilla integer types like
intandlong, but C99 standardized fixed width integers (https://en.cppreference.com/w/c/types/integer) so this is no longer a problem.This has nothing to do with the language having a spec. For example:
C++ has a formal ISO spec, and changes so recklessly that “you’ll end up like C++” is used as a cautionary tale for other languages.
JavaScriptECMAScript has a formal spec, but projects written in it have a shelf-life of an avocado.Perl doesn’t have any spec, and is just as frozen in time as C.
From the first introduction to Rust that kicked off the project at Mozilla (original emphasis):
I was mainly thinking about changes in terms of stability, not regarding the spec issue.
What I mean is that Rust is adding new features to its language constantly and is growing at a rapid rate. Even if its ideas aren’t new, they are new to the field of systems development which has been dominated by C and C++ the past years.
This is a common misconception about Rust.
Rust makes frequent small releases, instead of making infrequent big releases. This doesn’t affect rate of change of the language — features still take years to develop, and are added very conservatively. If Rust used C-like release cadence, it’d be Rust15 and Rust18, with Rust21 in the works.
Rust releases cover not only the language, but also its compiler implementation, libraries, and the build system. Nobody complains that C is growing constantly when GCC or CMake make new releases, or when POSIX adds new functions.
There’s an assumption that Rust 1.0 was a complete language, and now it’s adding useless junk. In fact 1.0 was a very bare-bones MVP, and it’s mostly catching up to what a decent language needs to be. For example, Rust 1.0 couldn’t clone an array larger than 32 elements, and it took years to add features to make it possible. Most recent release adds ability to convert
charto an integer (wow!) and to make a pointer to a field of a struct (what a radical new feature!)Majority of Rust changes are on such trivial scale, and actual users don’t complain there’s too much, they complain “I need to use a 3rd-party dependency to cast an integer to an
enum? WTF? Why isn’t it built-in yet!?”Judging from the 5 year recap of the Rust language (https://blog.rust-lang.org/2020/05/15/five-years-of-rust.html) the language added at least 1 feature every year since 2015. This is more than C, even with its infrequent release schedule, which averages about 0.7 features a year (judging from the list of new features per standard on their respective wikipedia pages), with most people sticking to older versions of C (which are standardized and forever accessible, unlike the Rust ecosystem which for the most part depends on specific compiler versions).
Rust definitely adds more features than C.
It’s rare when you have to modify C because of something architecture-specific, assuming you know C.
This has not been my experience in the slightest. Even porting relatively simple command line programs that don’t interact with the OS past opening files from windows to linux often seems to involve mucking with windows header files, and changes the size of longs which are still in use in some programs for some inconceivable reason. Compatibility between things like 8 bit micro controllers and x64 linux is far worse.
Perfectly written C code is probably not that bad, especially if the author made use of fixed size ints. In practice, if I pick up some random persons c code, it is that bad.
These are not changes in C, these are changes in the apis between platforms. If you limit your program to getc and putc then programs need no modification in my experience.
Good callout to not fall into the trap of being too confident in your code. I haven’t thought of this before, but imagine it could be easy to forget that there may still be pockets of unsafety or logic errors present.