Heck, if you ask some people, Rust is less secure than a GC’ed language for web apps if you use any crates that have unsafe code - which includes Actix, the most popular web framework, because unsafe code allows things like deferencing raw pointers.
I can’t help but think calling the unsafe keyword unsafe was a potential marketing error. Actually, within the rust community it helps to keep the portions of unsafe -marked code lower.
But many people short circuit to the conclusion that code with the unsafe keyword must be, indeed, unsafe. Maybe, they should think of it as expert or free code that relaxes some constraints (and by far not all, you have still more checks than in normal C++).
In terms of Rust unsafe, Java/ruby is full of unsafe code since some crucial safety guarantees in these languages are weaker. Obviously, there is a lot of unsafe rust code in the Rust std lib and especially in low level libraries. If this code is carefully vetted, this is all good. Rust allows you to focus extra attention on the small blocks of unsafe code.
Will I avoid unsafe code when I can? Yes. Should popular libraries make prudent use of unsafe if it results in large benefits? Absolutely. Is that dangerous? Not more than in other languages without these restrictions but yeah, it requires great care that you can avoid if you avoid unsafe.
It’s an especially annoying considering that performance-critical parts can always be written in unsafe ways, GC’d language or not. A prime example is uwsgi for Python.
@matklad Thank you for pointing out weak parts in my post. I wanted to post this as a separate reply to your reply but lobste.rs prevents me from multiple replies in short succession??
Having to mark certain snippets of code as unsafe is a great tool – that not all languages have. The less unsafe you use, the easier it is to achieve the security, of course, without being a genius or having lots of people helping out.
We agree that unsafe code should be avoided and carefully weight against advantages. I personally thing that well-reviewed libraries are a good place for unsafe code with huge performace benefits: crossbeam, …
Writing a highly perfomant async core library is a task involving some instances of unsafe code.
To clarify my remarks on the comparison to “GC’d languages”:
A) The quote compares safety of Rust to “GC’d” languages and says that Rust is maybe less unsafe because it uses “unsafe” code in its libraries.
I’d argue that there is no completely “safe” web app stack in any language that I am aware of. (and then you’d have to deal with compiler errors, operating systems, …)
If you look at NodeJS or Ruby on Rails, the interpreters and the HTTPS stacks contain lots of native code that isn’t verified by a smart compiler for safety guarantees. Correct me if my assumptions are wrong. I’d not be surprised if a Rust web app with actix contained a lot less “unsafe” code (in the Rust meaning) than an app built with these other stacks.
Of course, maybe more importantly, counting unsafe code lines is only a proxy argument because we cannot measure security: One line of unsafe code can destroy the safety of the whole application in crucial ways as can a compiler or std library bug. And a library like actix with six usages of unsafe could be completely secure. Or not.
B) I didn’t say what I meant with “crucial safety guarantees”, it was misleading. What I had in mind was more than only basic memory safety. The initial quote was about security. The argument was that Rust was less secure than “GC’d’ languages. I don’t believe that Rust code is usually less secure than that of GC’d languages and the expressive type system and guarantees that go beyond basic memory safety contribute to that.
I hope that makes sense. I wish I could make my point clearer in less words ;)
Thanks for the clarification! I think we are in a broad agreement here. In a narrow sense, unsafe is a sharp tool, easily misused, and dangerous even in the hands of an expert. However, it does improve the overall system’s security.
I violently agree with your point about full-stack safety of web apps. On the one hand, Rust’s unsafe (unlike Python’s ctypes) is available to “application programmer”, and pulls in the less safe direction. On the other hand, safe Rust is available to “systems programmer” (which again is unlike ctypes), and this massively improves the safety of lower levels of the stack, which feels like a bigger deal.
I also agree that Rust’s other type-system niceties improve application level correctness (and hence security) in comparison to current crop of popular static or dynamic languages.
That being said, I expect in the web domain specifically, application-level security (csrf tokens, protection against SQL injection, not storing passwords in plain text, etc) is a relatively bigger issue than execution-environment security. And here I expect a lot depends on maturity. I am not an expert in web dev, and, at this point I think I’ll be able to develop overall more secure web app with Django, as that should be much more hardened against misuse by web-security-naive programmers.
Interesting point about what is “available” to the “application programmer.” I guess the “available” is in terms of convenience and just writing unsafe somewhere is very convenient.
I, for myself, was never tempted to use unsafe but I neither wrote a low-level lib nor should I assume that I am the standard… I might be overcareful. And I can already shoot myself in the foot with misunderstanding atomic variables in safe code already ;)
But many people short circuit to the conclusion that code with the unsafe keyword must be, indeed, unsafe.
The short-circuiting might be wrong, but I personally don’t disagree with the conclusion. Unsafe code is hard, even widely battle tested things like SmallVec get CVEs. So, in practice, rust with unsafe does have memory safety issues due to bugs (although it’s important to keep in mind that Rust CVE have a somewhat lower bar, as theoretical, and not only practical, unsoundness counts).
In terms of Rust unsafe, Java/ruby is full of unsafe code since some crucial safety guarantees in these languages are weaker.
I am not sure I exactly understand what you are saying here. I think I agree with the general idea, but I disagree with the specific wording. In the context of Rust, unqualified safe/unsafe refers to memory safety, and, in terms of memory safety, Rust, Ruby, and Java are roughly equivalent (roughly because there’s extensions/ffi/native runtime angle). Things like iterator invalidation are not covered by the safety terminology.
Frankly, if we hadn’t had years of the Rust Evangelion Strike Force shitting on C and C++ for their use of unsafe pointers and whatnot, this might fly.
This charity wasn’t extended to references and some of the nice pointer types in C++ that solve memory safety issues, so why should we give unsafe a pass now?
Sorry your language doesn’t actually match its marketing.
Your ax grinding is absurd. It is possible to entertain two different problems simultaneously:
People get too excited about new technology like Rust and oversell its benefits by stating misleading things like “Rust can’t have memory safety bugs.” (I personally have been pretty consistent and vocal about clarifying this particular point.)
People get too curmudgeony and undersell Rust’s benefits by pointing to existence of unsafe as proof positive that Rust is no better than [insert other language here].
Really, it’s not difficult to see how both of these problems can exist simultaneously. Just because the first exists doesn’t mean we can’t also talk about the second.
Your consistent anti-RESF ax grinding is really just as bad as RESF zealots, if not worse. And yours has been going on for years too.
You didn’t say a damn thing when the user I replied to said “oh ho ho Rust is no less safe than Java or Ruby, if you just vet the code”. This is the same argument as neckbeards going “C is safe if you just write the code carefully!”. It’s pretty obvious when you give a pass to one but not the other.
Again, for context:
In terms of Rust unsafe, Java/ruby is full of unsafe code since some crucial safety guarantees in these languages are weaker. Obviously, there is a lot of unsafe rust code in the Rust std lib and especially in low level libraries. If this code is carefully vetted, this is all good.
Kettle meet pot, and you’re experienced enough (grats on ripgrep) that you should know when shilling is happening.
Anyways: my grinding has been consistent, for years, because the RESF has been obnoxious, for years.
I have observed no patterns of this behavior behind other C/C++ replacements. The D folks are underappreciated and chill. The Zig people don’t spam message boards and bug trackers asking to rewrite things in Zig. The Nim community, to my observation, don’t show up in every comment section to talk about how impossible is is to write safe software in C and how Nim is the answer, every time C shows up. Go people seemingly are too busy shipping useful utilities to even talk very much about Go being better than C–even at the height of Google’s shilling of it.
And every time this gets brought up, people like you show up to motte-and-bailey it and go “oh no no, who are those other ruffians, we’re just a kind and inclusive and loving community, oh we’d never say anything bad about another language, perish the thought!” This is a real problem, and just because y’all either can’t or won’t acknowledge it doesn’t mean the damage hasn’t been done to people outside your blessed tribe.
~
The hell of it is, I think Rust is a neat language with some neat features. I think it has some cool things going for it, even though the Rust talking-point bingo is predictable (almost as much as Elixir bingo). I can list the ideas I like from it, and if my workflow looked like it needed Rust more than what I’m already doing, I’d be excited to switch.
I just don’t like a community whose evangelism seemingly requires pervasive and persistent propaganda and, at times, lying. It shows a lack of moral character and engineering rigor that makes me concerned for the long-term health of the ecosystem.
You didn’t say a damn thing when the user I replied to said “oh ho ho Rust is no less safe than Java or Ruby, if you just vet the code”.
Because that isn’t a sensational thing to say? It’s nowhere near the same as the “neckbeard C programmer” you alluded to.
Kettle meet pot, and you’re experienced enough (grats on ripgrep) that you should know when shilling is happening.
Anyways: my grinding has been consistent, for years, because the RESF has been obnoxious, for years.
Is this some kind of joke? And you aren’t obnoxious? If that isn’t the kettle calling the pot black, then I don’t know what it is.
It’s one thing to respond and clarify things said by the “RESF” (and other claims made by zealots), but you go far beyond that and consistently engage in this meta flame war.
I have observed no patterns of this behavior behind other C/C++ replacements.
Well, what patterns of behavior have you observed among C/C++ programmers? The D, Nim and Zig communities aren’t nearly as big as Rust’s. And Go doesn’t really bring any new big ideas to the mainstream, so I really wouldn’t expect people to get that excited about it. That’s a feature of Go IMO. You also have immense pressure against talking about Go anyway, lest you be shouted down by PL zealots. (Zealots zealots everywhere, yet you seem to love to grind against one particular group in particular. How… obnoxious?)
And every time this gets brought up, people like you show up to motte-and-bailey it and go “oh no no, who are those other ruffians, we’re just a kind and inclusive and loving community, oh we’d never say anything bad about another language, perish the thought!” This is a real problem, and just because y’all either can’t or won’t acknowledge it doesn’t mean the damage hasn’t been done to people outside your blessed tribe.
Given that I’m a moderator in the Rust community and that I have shut down PL flame war discussions in official Rust spaces, it would be pretty weird of me to say that we never say anything bad about another language, now wouldn’t it?
And it has been acknowledged. That’s why I always do my best to clarify claims that are too bold. Do I get every single one? No. But then again, I don’t spend my time responding to every single one of your ridiculous comments either.
I just don’t like a community whose evangelism seemingly requires pervasive and persistent propaganda and, at times, lying. It shows a lack of moral character and engineering rigor that makes me concerned for the long-term health of the ecosystem.
This is a giant load of conspiracy-like bullshit. For someone who is so keen to call out bullshit and shilling, you sure do like to sling a lot of it yourself.
You didn’t say a damn thing when the user I replied to said “oh ho ho Rust is no less safe than Java or Ruby, if you just vet the code”. This is the same argument as neckbeards going “C is safe if you just write the code carefully!”. It’s pretty obvious when you give a pass to one but not the other.
I mean, yes? @burntsushi is a member of the Rust community, of course it’s going to bother him a bit more when someone like you is attacking that community vs someone in that community (politely!) making a debatable claim. That’s basic human social skills, not him being a hippocrite.
Kettle meet pot, and you’re experienced enough (grats on ripgrep) that you should know when shilling is happening. […] And every time this gets brought up, people like you show up to motte-and-bailey it and go “oh no no, who are those other ruffians, we’re just a kind and inclusive and loving community, oh we’d never say anything bad about another language, perish the thought!” This is a real problem, and just because y’all either can’t or won’t acknowledge it doesn’t mean the damage hasn’t been done to people outside your blessed tribe.
I know you’ve been trying to be less angersock and more friendlysock, so I’m just going to say this straight: you’re being an obnoxious jerk right now.
Agreed. This is like mom and dad fighting. Both are respected members of the community. Obviously it’s okay to disagree, but I expect both to be examples of what it means to be a good citizen.
I have a bias here. However my commentary should be applied broadly. Let’s demonstrate an eagerness to give each other the benefit of the doubt. Our community is known for being effective and compassionate regardless of disagreements. I’m committed to that because of lobster leaders like you have both demonstrated that it works here.
Thank you both for being candid. I look forward to the constructive conversation this exchange will lead to.
I know you’ve been trying to be less angersock and more friendlysock, so I’m just going to say this straight: you’re being an obnoxious jerk right now.
Yeah, you got me there–fair point. I’ll go cool off.
Why should I wear a seatbelt if I’m still at risk of dying or injury in a car accident?
At least with C/C++ there are libraries that have existed for 20+ years, written by competent people.
That’s great. I use a lot of Rust code written by competent people too. None have existed for 20+ years, of course, but many have been around for 5+ years and work great. Gotta start somewhere! Or maybe in 15 years you’ll just be bragging about how you use libraries that have existed for 35+ years?
Brining in Rust dependencies is really easy though. Arguably too easy. So I don’t quite understand that part of your comment.
My rhetorical question was meant to point out that risk isn’t a binary thing. We can’t really quantify it here, but I think it’s at least clear that it isn’t binary. Which is why I asked you about seat belts. We acknowledge that seat belts mitigate risk, not eliminate it. Your argument is like saying, “seatbelts aren’t perfect, so why wear them?”
Now the extent to which the seat belt bothers you is the unclear bit. Maybe a seat belt is so bothersome that the risk mitigation it offers isn’t worth it. But to not use it purely because it isn’t perfect just seems weird.
But analogies only go so far. I don’t just use Rust for security or safety reasons intrinsically. I use it because its type system (and borrow checker) mentally frees me from needing to care about whether I’m committing UB or not in 99% of the code I write. This frees up my mental energy to focus on other things.
So for me, it ends up being a liberating experience. But that’s me. Not everyone shares that experience.
The important bit is to recognize this dynamic instead of talking like it’s this binary thing and making backhanded comments about competency.
In comparison to C/C++ no it’s not. You have to bring in a whole new language and toolchain.
I interpreted your comment as, “it’s hard to add a new crate to an existing Rust project.” But what you’re saying is, “adding a new toolchain to an existing project is a lot of work.” Sure, that’s true. Not particularly interesting, but true.
I rarely think about undefined behavior when writing C/C++.
Well, I think the long history of documented security vulnerabilities due to memory unsafety makes that pretty difficult to believe. You get a segfault only if you’re lucky.
Because UB isn’t just a security issue. I can either believe your anecdote, or look at the data that says programmers routinely trip over UB in C. Sorry, but you just don’t present a compelling case.
I’m not saying that you’re lying. But I am saying that it defies credulity.
One should not “fight” with the borrow checker. It merely tells you when your code is wrong. One of the main things I like about rust is I can largely code just as I would in a GC’d environment without paying the GC tax.
One should not “fight” with the borrow checker. It merely tells you when your code is wrong.
This isn’t true. Fighting with the borrow checker is a thing, even for people who have been writing Rust for years. It’s a trade off. The borrow checker rejects some valid programs. (And this is, more generally, the trade off we make when using non-unityped languages.) Here’s one of my favorite examples because it’s so easy to express and is not that uncommon in Rust code (because the borrow checker impedes logical decomposition): https://github.com/BurntSushi/regex-automata/blob/e7bda549a0d49d79c631ded6f47846ad69aa8a3e/src/nfa/compiler.rs#L22-L32
But even aside from that, there are other things, like self-referential types, that are painful to express in Rust safely and easily.
The borrow checker rejects programs that one might imagine working at runtime in some language that allowed them, but since they are rejected they cannot be valid rust?
That’s a truism. What I mean is, programs that would be accepted and valid (as in, don’t exhibit undefined behavior or other logical bugs) if the borrow checker weren’t present. It’s a thought experiment and a way to recognize the costs of the borrow checker, of which there are several.
Here’s a real-world example of the fight from rust-analyzer’s code base. here, we have to accept a callback (internal iterator) instead of returning an iterator, because the lifetimes just don’t work out. In Kotlin, I’d just returned a Sequence there, without thinking twice.
They can be valid Rust with unsafe. The only problem is that it is not unsafe, not wrong just the borrow checker thinks it is. People who use Rust have to adopt to write code that Rust allows. It is limited sometimes for safety reasons, sometimes for correction reasons, and sometimes no reasons at all. If you code in Rust you put up or leave.
No, it does not do that only. It is perfectly legitimate to have globally readable constants in your code. The borrow checker disagrees. My code is not wrong, the borrow checker is.
Global read-only constants work just fine without any fuss in Rust. The only become fussy when you introduce mutation of some sort. (Even if that mutation is only done once at start-up, but then, those wouldn’t be called constants I suppose. Constants are generally regarded as things known at compile time.)
If your code is in rust and the borrow checker disagrees with you, then you are wrong. Of course in a different language maybe you can do things differently and it would not be wrong for that language. But insisting rust is wrong because it bans those things is like saying latin has word order wrong because you like SVO.
This is a bad take, as I said in my other replies to you. I even gave you a concrete example. If you insist on not permitting a thought experiment, then it’s easy to rephrase. Given a program that the borrow checker rejects, I claim that I can very likely rewrite that program to be accepted by the borrow checker by using unsafe. Among that set of programs, there exists a non-empty subset that are sound, logically correct and free of undefined behavior. Indeed, this is precisely the utility of unsafe in many circumstances.
“Fighting” with the borrow checker then manifests as the tension between writing code without unsafe and dropping down into unsafe. It should be taken as given that Rust would be less useful if you were forced to use unsafe in more cases than today, because that would reduce Rust’s value proposition. (Some cases can be fixed using interior mutability as my example showed, but not all.)
Indeed, much of the work that has gone into the borrow checker has been improving it by making it accept more source code as valid programs. Non-lexical lifetimes that landed as part of Rust 2018 are excellent example of this.
So when people say “the borrow checker doesn’t accept some valid programs,” this is what they mean. Interpreting the statement literally as a truism misses the point being made.
I can’t help but think calling the unsafe keyword unsafe was a potential marketing error.
Isn’t there a comparison to unsafe in C#? The same arguments were made back in the early 2000s about that and it made for many tirades and comments.
I think Rust user’s domain requirements might provide longevity to the use of unsafe, it has disappeared from discussions in the C# space. It’s to the point where many C# programmers would give you a puzzled look if you mentioned unsafe existed.
I’m a big fan/user of Rust I think this is a fairly accurate assessment. There is a lot of interest in building web applications with Rust and I’ve built a couple myself but there’s still a ways to go. Coming from Rails, some of things I’ve missed are:
built in csrf protection on forms
an equivalent to devise
sophisticated form handling (array attributes, nested attributes)
form validation and presentation of errors back to the user, preserving form input
Actually… maybe it’s mostly form handling that’s immature. Seems many people build back ends in Rust for JS SPAs where this isn’t such an issue but I’m not interested in building that type of web application.
On the other hand some things are delightfully easy:
JSON responses/request parsing — often a single line thanks to serde
Microsecond response times, low memory use, instant start up time.
Serde is so amazing. It’s actually something I miss in higher-level language frameworks, but that’s because it ties in with the type system in Rust to also do validation.
In general, the type system in Rust takes a way a great deal of ‘what-ifs’ about corner cases in code. I feel like we often cut corners when working in higher-level languages, causing confusing error messages to the user or straight up security issues.
I guess it’s a double edged sword that also causes some of the difficulty highlighted by OP.
Yeah; I’d like to underscore this sentiment. This has been a massive pain point for me lately.
I really appreciate the Rust approach to async (library based). However, I still find myself frustrated by dependency lock-in and lack of up to date documentation. If I want to leverage the larger async ecosystem, in almost every case, I need to commit to tokio and ensure that it’s version is consistent across any other dependency that leverages tokio under the hood. Eventually, I realized that I was spending more time juggling dependencies and troubleshooting async runtime shenanigans than I was writing business logic. Much of the async ecosystem still has incomplete documentation and requires spelunking source code. This is good and bad. It’s a sign that the ecosystem is growing rapidly, but unfortunately it quickly makes google/stackoverflow queries out of date. I’ll admit that it’s possible that some of the pain I’ve experienced already has a solution in the form of a compat style lib.
I generally try to avoid being to critical in comments as it’s easy to just leave low-energy feedback/complaints. I know a lot of hard work and thought has been put into Rust’s async effort. However, I’m concerned that if my pain tolerance is being hit, what kind of impression is left on users with less experience?
In spite of all of this, I’m still optimistic that Rust is headed in the right direction.
The original author of Devise went on to create Elixir, and he has decided to take a different approach to authentication this time around. So a strict equivalent to Devise might not be the best thing.
There’s also something to be said about code verbosity. Particularly when building something small and to the point, it does make a difference to use a language which gets it done with less lines of code and less syntactical elements.
I don’t think people give python, ruby, or even PHP, or JavaScript enough credit for this.
Python derives block definition by indentation that you would use anyway. Has very few weird chars to indicate what type symbol a given identifier is because it derives it from its position on a syntactic rule.
It also has carefully crafted not overly complicated shapes and very few keywords.
These things matter. When writing a program in java, it typicaly requires me 5-10 times more code than a python version.
I think rust does suffer from this and I think this will always give space for more succinct alternatives.
Crystal is a neat language with many of the advantages of rust but with a compact syntax mimicking ruby. It is currently my go to language of I need to write a quick rest API. But the community is tiny and their standard lib relies upon c libraries which in practice results in many portability headaches.ä
I am a Java developer, currently forced into writing NodeJS/Javascript code, and while I have to write fewer lines of code to accomplish the same thing, I have found that I have to write twice as many, if not more, tests than I would have in Java, simply because the language does not provide sufficient validation from the standard interpreters or linters. This increase in cognitive load has hampered my productivity. I can’t speak to the other languages you have mentioned, but I have to say that Javascript specifically does not deserve any credit.
This is true. It is a downside that those languages don’t have built in type checks. They were designed no to be compiled manually, then there was no oportunity to do that anyway.
Linters and other type checks hacked on top of the language are a dead end in my opinion.
Crystal, nim, Scala, Haskell do this right. The type declarations are sucint and even omitable if they can be interest. I think this is the right direction.
I love crystal, but I’m not sure it has any of the advantages of Rust? It has a GC and a runtime and no idiomatic access to raw ponters or trivial c abi compatible exports…
Type safety, a compiler targeting native binaries and performance are the advantages the bulk of users care about. The details you mentioned matter to a tiny minority of people. Most people want to write their cli app, building their rest API, process their data files, and such other everyday tasks.
I think the article makes some good points on why writing APIs might be easy, but proper websites / web applications not so much if you factor in things like form validation or CSRF tokens. And where there might be middlewares for that they are not standardized across web frameworks or toolkits.
I’ve used Rocket in some internal tooling in my company. I’ve liked the API; but the requirement of using nightly Rust compiler build is a real dealbreaker, regularly I had to spend time fighting with the compiler in order to compile the library. Even if it finally compiled, few months later and few rustup’s later, it broke again.
I’ve switched to Actix, which requires a stable compiler version.
I had an argument with a person that said: the rust compiler changes too much, they need to update their code constantly.
I was really surprised because my experience was had the opposite with very rare exceptions.
They failed to mention that they used the nightly compiler. When we discovered that this was the cause for our different experiences, they basically said that in their opinion, you had to use the nightly compiler to use anything in their niche (ML).
I wonder for how many people this seems to be the case and if popular libraries like rocket which depend on nightly, support this.
https://nim-lang.org/ compiles fast, is quite mature by now and works in similar performance and safety levels as Rust (except for multithreading safety). But also it doesn’t have a web framework comparable to Rails or Django.
Channels are just data structures. When speaking about thread safety in Rust, specifically with respect to what it offers at compile time, is a static guarantee that no data races may occur in safe code. This can lead to real wins, particularly in large code bases, where it might be otherwise easy to introduce UB through unsynchronized mutation inside a data structure where the programmer doesn’t realize that it is actually used from multiple threads simultaneously.
Note that preventing data races just means that safe Rust code won’t allow you to perform an unsynchronized read and write to the same location in memory. It does not mean that it prevents larger application oriented bugs resulting from race conditions, deadlock or other types of concurrency bugs. (Although RAII does help prevent some common causes of those types of bugs.)
If a data race does occur in safe code, then it must be the case that there is a bug somewhere in an unsafe block of code.
These statements annoy me:
I can’t help but think calling the
unsafekeywordunsafewas a potential marketing error. Actually, within the rust community it helps to keep the portions ofunsafe-marked code lower.But many people short circuit to the conclusion that code with the
unsafekeyword must be, indeed, unsafe. Maybe, they should think of it asexpertorfreecode that relaxes some constraints (and by far not all, you have still more checks than in normal C++).In terms of Rust
unsafe, Java/ruby is full ofunsafecode since some crucial safety guarantees in these languages are weaker. Obviously, there is a lot ofunsaferust code in the Rust std lib and especially in low level libraries. If this code is carefully vetted, this is all good. Rust allows you to focus extra attention on the small blocks of unsafe code.Will I avoid
unsafecode when I can? Yes. Should popular libraries make prudent use ofunsafeif it results in large benefits? Absolutely. Is that dangerous? Not more than in other languages without these restrictions but yeah, it requires great care that you can avoid if you avoidunsafe.It’s an especially annoying considering that performance-critical parts can always be written in unsafe ways, GC’d language or not. A prime example is uwsgi for Python.
@matklad Thank you for pointing out weak parts in my post. I wanted to post this as a separate reply to your reply but lobste.rs prevents me from multiple replies in short succession??
Having to mark certain snippets of code as
unsafeis a great tool – that not all languages have. The lessunsafeyou use, the easier it is to achieve the security, of course, without being a genius or having lots of people helping out.We agree that
unsafecode should be avoided and carefully weight against advantages. I personally thing that well-reviewed libraries are a good place for unsafe code with huge performace benefits: crossbeam, …To quote from
async-stdsecurity:To clarify my remarks on the comparison to “GC’d languages”:
A) The quote compares safety of Rust to “GC’d” languages and says that Rust is maybe less unsafe because it uses “unsafe” code in its libraries.
I’d argue that there is no completely “safe” web app stack in any language that I am aware of. (and then you’d have to deal with compiler errors, operating systems, …)
If you look at NodeJS or Ruby on Rails, the interpreters and the HTTPS stacks contain lots of native code that isn’t verified by a smart compiler for safety guarantees. Correct me if my assumptions are wrong. I’d not be surprised if a Rust web app with actix contained a lot less “unsafe” code (in the Rust meaning) than an app built with these other stacks.
Of course, maybe more importantly, counting unsafe code lines is only a proxy argument because we cannot measure security: One line of unsafe code can destroy the safety of the whole application in crucial ways as can a compiler or std library bug. And a library like actix with six usages of
unsafecould be completely secure. Or not.B) I didn’t say what I meant with “crucial safety guarantees”, it was misleading. What I had in mind was more than only basic memory safety. The initial quote was about security. The argument was that Rust was less secure than “GC’d’ languages. I don’t believe that Rust code is usually less secure than that of GC’d languages and the expressive type system and guarantees that go beyond basic memory safety contribute to that.
I hope that makes sense. I wish I could make my point clearer in less words ;)
Thanks for the clarification! I think we are in a broad agreement here. In a narrow sense, unsafe is a sharp tool, easily misused, and dangerous even in the hands of an expert. However, it does improve the overall system’s security.
I violently agree with your point about full-stack safety of web apps. On the one hand, Rust’s
unsafe(unlike Python’s ctypes) is available to “application programmer”, and pulls in the less safe direction. On the other hand, safe Rust is available to “systems programmer” (which again is unlike ctypes), and this massively improves the safety of lower levels of the stack, which feels like a bigger deal.I also agree that Rust’s other type-system niceties improve application level correctness (and hence security) in comparison to current crop of popular static or dynamic languages.
That being said, I expect in the web domain specifically, application-level security (csrf tokens, protection against SQL injection, not storing passwords in plain text, etc) is a relatively bigger issue than execution-environment security. And here I expect a lot depends on maturity. I am not an expert in web dev, and, at this point I think I’ll be able to develop overall more secure web app with Django, as that should be much more hardened against misuse by web-security-naive programmers.
Interesting point about what is “available” to the “application programmer.” I guess the “available” is in terms of convenience and just writing
unsafesomewhere is very convenient.I, for myself, was never tempted to use
unsafebut I neither wrote a low-level lib nor should I assume that I am the standard… I might be overcareful. And I can already shoot myself in the foot with misunderstanding atomic variables in safe code already ;)The short-circuiting might be wrong, but I personally don’t disagree with the conclusion. Unsafe code is hard, even widely battle tested things like SmallVec get CVEs. So, in practice, rust with unsafe does have memory safety issues due to bugs (although it’s important to keep in mind that Rust CVE have a somewhat lower bar, as theoretical, and not only practical, unsoundness counts).
I am not sure I exactly understand what you are saying here. I think I agree with the general idea, but I disagree with the specific wording. In the context of Rust, unqualified safe/unsafe refers to memory safety, and, in terms of memory safety, Rust, Ruby, and Java are roughly equivalent (roughly because there’s extensions/ffi/native runtime angle). Things like iterator invalidation are not covered by the safety terminology.
[Comment removed by author]
Frankly, if we hadn’t had years of the Rust Evangelion Strike Force shitting on C and C++ for their use of unsafe pointers and whatnot, this might fly.
This charity wasn’t extended to references and some of the nice pointer types in C++ that solve memory safety issues, so why should we give
unsafea pass now?Sorry your language doesn’t actually match its marketing.
Your ax grinding is absurd. It is possible to entertain two different problems simultaneously:
unsafeas proof positive that Rust is no better than [insert other language here].Really, it’s not difficult to see how both of these problems can exist simultaneously. Just because the first exists doesn’t mean we can’t also talk about the second.
Your consistent anti-RESF ax grinding is really just as bad as RESF zealots, if not worse. And yours has been going on for years too.
You didn’t say a damn thing when the user I replied to said “oh ho ho Rust is no less safe than Java or Ruby, if you just vet the code”. This is the same argument as neckbeards going “C is safe if you just write the code carefully!”. It’s pretty obvious when you give a pass to one but not the other.
Again, for context:
Kettle meet pot, and you’re experienced enough (grats on ripgrep) that you should know when shilling is happening.
Anyways: my grinding has been consistent, for years, because the RESF has been obnoxious, for years.
I have observed no patterns of this behavior behind other C/C++ replacements. The D folks are underappreciated and chill. The Zig people don’t spam message boards and bug trackers asking to rewrite things in Zig. The Nim community, to my observation, don’t show up in every comment section to talk about how impossible is is to write safe software in C and how Nim is the answer, every time C shows up. Go people seemingly are too busy shipping useful utilities to even talk very much about Go being better than C–even at the height of Google’s shilling of it.
And every time this gets brought up, people like you show up to motte-and-bailey it and go “oh no no, who are those other ruffians, we’re just a kind and inclusive and loving community, oh we’d never say anything bad about another language, perish the thought!” This is a real problem, and just because y’all either can’t or won’t acknowledge it doesn’t mean the damage hasn’t been done to people outside your blessed tribe.
~
The hell of it is, I think Rust is a neat language with some neat features. I think it has some cool things going for it, even though the Rust talking-point bingo is predictable (almost as much as Elixir bingo). I can list the ideas I like from it, and if my workflow looked like it needed Rust more than what I’m already doing, I’d be excited to switch.
I just don’t like a community whose evangelism seemingly requires pervasive and persistent propaganda and, at times, lying. It shows a lack of moral character and engineering rigor that makes me concerned for the long-term health of the ecosystem.
Because that isn’t a sensational thing to say? It’s nowhere near the same as the “neckbeard C programmer” you alluded to.
Is this some kind of joke? And you aren’t obnoxious? If that isn’t the kettle calling the pot black, then I don’t know what it is.
It’s one thing to respond and clarify things said by the “RESF” (and other claims made by zealots), but you go far beyond that and consistently engage in this meta flame war.
Well, what patterns of behavior have you observed among C/C++ programmers? The D, Nim and Zig communities aren’t nearly as big as Rust’s. And Go doesn’t really bring any new big ideas to the mainstream, so I really wouldn’t expect people to get that excited about it. That’s a feature of Go IMO. You also have immense pressure against talking about Go anyway, lest you be shouted down by PL zealots. (Zealots zealots everywhere, yet you seem to love to grind against one particular group in particular. How… obnoxious?)
Given that I’m a moderator in the Rust community and that I have shut down PL flame war discussions in official Rust spaces, it would be pretty weird of me to say that we never say anything bad about another language, now wouldn’t it?
And it has been acknowledged. That’s why I always do my best to clarify claims that are too bold. Do I get every single one? No. But then again, I don’t spend my time responding to every single one of your ridiculous comments either.
This is a giant load of conspiracy-like bullshit. For someone who is so keen to call out bullshit and shilling, you sure do like to sling a lot of it yourself.
I’m not sure the community is actively funded to evangelize. Could it just be that using rust makes people want to share their enthusiasm?
It’s certainly possible. Maybe people just really liked Java, C#, and Go too.
I mean, yes? @burntsushi is a member of the Rust community, of course it’s going to bother him a bit more when someone like you is attacking that community vs someone in that community (politely!) making a debatable claim. That’s basic human social skills, not him being a hippocrite.
I know you’ve been trying to be less angersock and more friendlysock, so I’m just going to say this straight: you’re being an obnoxious jerk right now.
Agreed. This is like mom and dad fighting. Both are respected members of the community. Obviously it’s okay to disagree, but I expect both to be examples of what it means to be a good citizen.
I have a bias here. However my commentary should be applied broadly. Let’s demonstrate an eagerness to give each other the benefit of the doubt. Our community is known for being effective and compassionate regardless of disagreements. I’m committed to that because of lobster leaders like you have both demonstrated that it works here.
Thank you both for being candid. I look forward to the constructive conversation this exchange will lead to.
Yeah, again, sorry for setting a bad example. :(
Yeah, you got me there–fair point. I’ll go cool off.
[Comment removed by author]
Why should I wear a seatbelt if I’m still at risk of dying or injury in a car accident?
That’s great. I use a lot of Rust code written by competent people too. None have existed for 20+ years, of course, but many have been around for 5+ years and work great. Gotta start somewhere! Or maybe in 15 years you’ll just be bragging about how you use libraries that have existed for 35+ years?
[Comment removed by author]
Brining in Rust dependencies is really easy though. Arguably too easy. So I don’t quite understand that part of your comment.
My rhetorical question was meant to point out that risk isn’t a binary thing. We can’t really quantify it here, but I think it’s at least clear that it isn’t binary. Which is why I asked you about seat belts. We acknowledge that seat belts mitigate risk, not eliminate it. Your argument is like saying, “seatbelts aren’t perfect, so why wear them?”
Now the extent to which the seat belt bothers you is the unclear bit. Maybe a seat belt is so bothersome that the risk mitigation it offers isn’t worth it. But to not use it purely because it isn’t perfect just seems weird.
But analogies only go so far. I don’t just use Rust for security or safety reasons intrinsically. I use it because its type system (and borrow checker) mentally frees me from needing to care about whether I’m committing UB or not in 99% of the code I write. This frees up my mental energy to focus on other things.
So for me, it ends up being a liberating experience. But that’s me. Not everyone shares that experience.
The important bit is to recognize this dynamic instead of talking like it’s this binary thing and making backhanded comments about competency.
[Comment removed by author]
I interpreted your comment as, “it’s hard to add a new crate to an existing Rust project.” But what you’re saying is, “adding a new toolchain to an existing project is a lot of work.” Sure, that’s true. Not particularly interesting, but true.
I find this surprising, but okay.
If you say so.
[Comment removed by author]
Well, I think the long history of documented security vulnerabilities due to memory unsafety makes that pretty difficult to believe. You get a segfault only if you’re lucky.
[Comment removed by author]
Because UB isn’t just a security issue. I can either believe your anecdote, or look at the data that says programmers routinely trip over UB in C. Sorry, but you just don’t present a compelling case.
I’m not saying that you’re lying. But I am saying that it defies credulity.
[Comment removed by author]
One should not “fight” with the borrow checker. It merely tells you when your code is wrong. One of the main things I like about rust is I can largely code just as I would in a GC’d environment without paying the GC tax.
This isn’t true. Fighting with the borrow checker is a thing, even for people who have been writing Rust for years. It’s a trade off. The borrow checker rejects some valid programs. (And this is, more generally, the trade off we make when using non-unityped languages.) Here’s one of my favorite examples because it’s so easy to express and is not that uncommon in Rust code (because the borrow checker impedes logical decomposition): https://github.com/BurntSushi/regex-automata/blob/e7bda549a0d49d79c631ded6f47846ad69aa8a3e/src/nfa/compiler.rs#L22-L32
But even aside from that, there are other things, like self-referential types, that are painful to express in Rust safely and easily.
The borrow checker rejects programs that one might imagine working at runtime in some language that allowed them, but since they are rejected they cannot be valid rust?
That’s a truism. What I mean is, programs that would be accepted and valid (as in, don’t exhibit undefined behavior or other logical bugs) if the borrow checker weren’t present. It’s a thought experiment and a way to recognize the costs of the borrow checker, of which there are several.
Here’s a real-world example of the fight from rust-analyzer’s code base. here, we have to accept a callback (internal iterator) instead of returning an iterator, because the lifetimes just don’t work out. In Kotlin, I’d just returned a
Sequencethere, without thinking twice.They can be valid Rust with unsafe. The only problem is that it is not unsafe, not wrong just the borrow checker thinks it is. People who use Rust have to adopt to write code that Rust allows. It is limited sometimes for safety reasons, sometimes for correction reasons, and sometimes no reasons at all. If you code in Rust you put up or leave.
No, it does not do that only. It is perfectly legitimate to have globally readable constants in your code. The borrow checker disagrees. My code is not wrong, the borrow checker is.
Global read-only constants work just fine without any fuss in Rust. The only become fussy when you introduce mutation of some sort. (Even if that mutation is only done once at start-up, but then, those wouldn’t be called constants I suppose. Constants are generally regarded as things known at compile time.)
If your code is in rust and the borrow checker disagrees with you, then you are wrong. Of course in a different language maybe you can do things differently and it would not be wrong for that language. But insisting rust is wrong because it bans those things is like saying latin has word order wrong because you like SVO.
This is a bad take, as I said in my other replies to you. I even gave you a concrete example. If you insist on not permitting a thought experiment, then it’s easy to rephrase. Given a program that the borrow checker rejects, I claim that I can very likely rewrite that program to be accepted by the borrow checker by using
unsafe. Among that set of programs, there exists a non-empty subset that are sound, logically correct and free of undefined behavior. Indeed, this is precisely the utility ofunsafein many circumstances.“Fighting” with the borrow checker then manifests as the tension between writing code without
unsafeand dropping down intounsafe. It should be taken as given that Rust would be less useful if you were forced to useunsafein more cases than today, because that would reduce Rust’s value proposition. (Some cases can be fixed using interior mutability as my example showed, but not all.)Indeed, much of the work that has gone into the borrow checker has been improving it by making it accept more source code as valid programs. Non-lexical lifetimes that landed as part of Rust 2018 are excellent example of this.
So when people say “the borrow checker doesn’t accept some valid programs,” this is what they mean. Interpreting the statement literally as a truism misses the point being made.
I totally agree. There’s more than a little bit of trying to have it both ways here, and observers are too smart for that.
Isn’t there a comparison to unsafe in C#? The same arguments were made back in the early 2000s about that and it made for many tirades and comments.
I think Rust user’s domain requirements might provide longevity to the use of unsafe, it has disappeared from discussions in the C# space. It’s to the point where many C# programmers would give you a puzzled look if you mentioned unsafe existed.
I’m a big fan/user of Rust I think this is a fairly accurate assessment. There is a lot of interest in building web applications with Rust and I’ve built a couple myself but there’s still a ways to go. Coming from Rails, some of things I’ve missed are:
Actually… maybe it’s mostly form handling that’s immature. Seems many people build back ends in Rust for JS SPAs where this isn’t such an issue but I’m not interested in building that type of web application.
On the other hand some things are delightfully easy:
Serde is so amazing. It’s actually something I miss in higher-level language frameworks, but that’s because it ties in with the type system in Rust to also do validation.
In general, the type system in Rust takes a way a great deal of ‘what-ifs’ about corner cases in code. I feel like we often cut corners when working in higher-level languages, causing confusing error messages to the user or straight up security issues.
I guess it’s a double edged sword that also causes some of the difficulty highlighted by OP.
Well, and async is complicated if you use it.
Yeah; I’d like to underscore this sentiment. This has been a massive pain point for me lately.
I really appreciate the Rust approach to async (library based). However, I still find myself frustrated by dependency lock-in and lack of up to date documentation. If I want to leverage the larger async ecosystem, in almost every case, I need to commit to tokio and ensure that it’s version is consistent across any other dependency that leverages tokio under the hood. Eventually, I realized that I was spending more time juggling dependencies and troubleshooting async runtime shenanigans than I was writing business logic. Much of the async ecosystem still has incomplete documentation and requires spelunking source code. This is good and bad. It’s a sign that the ecosystem is growing rapidly, but unfortunately it quickly makes google/stackoverflow queries out of date. I’ll admit that it’s possible that some of the pain I’ve experienced already has a solution in the form of a
compatstyle lib.I generally try to avoid being to critical in comments as it’s easy to just leave low-energy feedback/complaints. I know a lot of hard work and thought has been put into Rust’s async effort. However, I’m concerned that if my pain tolerance is being hit, what kind of impression is left on users with less experience?
In spite of all of this, I’m still optimistic that Rust is headed in the right direction.
The original author of Devise went on to create Elixir, and he has decided to take a different approach to authentication this time around. So a strict equivalent to Devise might not be the best thing.
By equivalent I meant more generally: a solution to common authentication patterns in web applications so you don’t have to roll your own.
There’s also something to be said about code verbosity. Particularly when building something small and to the point, it does make a difference to use a language which gets it done with less lines of code and less syntactical elements.
I don’t think people give python, ruby, or even PHP, or JavaScript enough credit for this.
Python derives block definition by indentation that you would use anyway. Has very few weird chars to indicate what type symbol a given identifier is because it derives it from its position on a syntactic rule. It also has carefully crafted not overly complicated shapes and very few keywords.
These things matter. When writing a program in java, it typicaly requires me 5-10 times more code than a python version. I think rust does suffer from this and I think this will always give space for more succinct alternatives.
Crystal is a neat language with many of the advantages of rust but with a compact syntax mimicking ruby. It is currently my go to language of I need to write a quick rest API. But the community is tiny and their standard lib relies upon c libraries which in practice results in many portability headaches.ä
I am a Java developer, currently forced into writing NodeJS/Javascript code, and while I have to write fewer lines of code to accomplish the same thing, I have found that I have to write twice as many, if not more, tests than I would have in Java, simply because the language does not provide sufficient validation from the standard interpreters or linters. This increase in cognitive load has hampered my productivity. I can’t speak to the other languages you have mentioned, but I have to say that Javascript specifically does not deserve any credit.
This is true. It is a downside that those languages don’t have built in type checks. They were designed no to be compiled manually, then there was no oportunity to do that anyway.
Linters and other type checks hacked on top of the language are a dead end in my opinion.
Crystal, nim, Scala, Haskell do this right. The type declarations are sucint and even omitable if they can be interest. I think this is the right direction.
I love crystal, but I’m not sure it has any of the advantages of Rust? It has a GC and a runtime and no idiomatic access to raw ponters or trivial c abi compatible exports…
Type safety, a compiler targeting native binaries and performance are the advantages the bulk of users care about. The details you mentioned matter to a tiny minority of people. Most people want to write their cli app, building their rest API, process their data files, and such other everyday tasks.
Those things aren’t “advantages of rust” though. Yes, rust has those things but so do many, many, many other languages.
Your comments are often misunderstood. Perhaps if you define your terms more clearly that won’t happen so often.
Someone said somethin, I asked them to clarify, they did, then I commented. Seems like a normal discussion interaction to me
When I was playing around with Rocket, I felt that Rust was an easy way to make a web API/website.
Compared to Django or Rails or similar frameworks, it seemed to me like there was significantly less to worry about.
But I haven’t built anything serious with it, so maybe I would change my mind if I did.
Rust is not my favourite language (that would be Zig) but I would use it if I had to build a web app.
I think the article makes some good points on why writing APIs might be easy, but proper websites / web applications not so much if you factor in things like form validation or CSRF tokens. And where there might be middlewares for that they are not standardized across web frameworks or toolkits.
I’ve used Rocket in some internal tooling in my company. I’ve liked the API; but the requirement of using nightly Rust compiler build is a real dealbreaker, regularly I had to spend time fighting with the compiler in order to compile the library. Even if it finally compiled, few months later and few rustup’s later, it broke again.
I’ve switched to Actix, which requires a stable compiler version.
I had an argument with a person that said: the rust compiler changes too much, they need to update their code constantly.
I was really surprised because my experience was had the opposite with very rare exceptions.
They failed to mention that they used the nightly compiler. When we discovered that this was the cause for our different experiences, they basically said that in their opinion, you had to use the nightly compiler to use anything in their niche (ML).
I wonder for how many people this seems to be the case and if popular libraries like rocket which depend on nightly, support this.
Yeah.
That’s one reason why I haven’t done anything serious with it.
It should work on stable in the next release it seems.
If I’d knew that, I’d leave those tools running on Rocket, dammit! ;)
https://nim-lang.org/ compiles fast, is quite mature by now and works in similar performance and safety levels as Rust (except for multithreading safety). But also it doesn’t have a web framework comparable to Rails or Django.
Isn’t channels provide the same safety just like in Rust?
Channels are just data structures. When speaking about thread safety in Rust, specifically with respect to what it offers at compile time, is a static guarantee that no data races may occur in safe code. This can lead to real wins, particularly in large code bases, where it might be otherwise easy to introduce UB through unsynchronized mutation inside a data structure where the programmer doesn’t realize that it is actually used from multiple threads simultaneously.
Note that preventing data races just means that safe Rust code won’t allow you to perform an unsynchronized read and write to the same location in memory. It does not mean that it prevents larger application oriented bugs resulting from race conditions, deadlock or other types of concurrency bugs. (Although RAII does help prevent some common causes of those types of bugs.)
If a data race does occur in safe code, then it must be the case that there is a bug somewhere in an
unsafeblock of code.Yep, this is why we use F# instead. Productivity wise it is a much better option.