Great to see people found my article interesting! I wrote it after I was asked by a company about the possibility of helping them by contributing to some open source Rust projects. During the conversation I tried to explain my involvement in the community, but I noticed the story wasn't that fresh in my mind. A few days later I decided to research it, write it down and publish it, because it might inspire other people to contribute and also because there might be other companies willing to bring an old contributor back, if they only knew
I know Rust is very popular right now but as a back-end dev I always wondered what's in it for me. I never had to write programs where garbage collection was a problem and learning a whole new paradigm (borrow-checking) just seemed unnecessary. And it seems like it is a language that is more difficult for junior developers than almost any other one. What does Rust solve for the casual user?
If by casual user, you mean the 95% case of a back-end developer whose main job is pulling data from various sources, performing operations, and placing that data elsewhere and/or displaying it to an end user: nothing, really.
Rust excels at performance, but the bottleneck in modern web apps is going to be IO, whether that's loading data from a database or from a third-party API you're integrating with. Rust excels at correctness, but your errors are going to come from bad data and system outages which require manual intervention anyway. Rust excels at security, but if you're using a GC language running on a Docker container on an ephemeral cloud instance, the kind of security Rust provides isn't a likely attack vector for you.
All that being said, Rust is a great language! It just has its niche, and that niche is not the typical web-dev back-end work that most developers do these days. As others have said, you'd use Rust in the same situations you'd use C++: building a database, building a web server (like nginx), etc. If you're just building a web app that talks to a database and serves HTTP responses, stick with Python/Ruby/Go/PHP.
> but the bottleneck in modern web apps is going to be IO
This is true in some senses, but also, response latency isn't the only thing a web application does or is evaluated by. Many applications have, for example, background jobs, that do arbitrarily complex processing outside of the request/response cycle.
Additionally, people who write web services in Rust talk about decreased memory usage, consistent memory usage, and lower CPU usage. In a cloud context, that can translate directly to revenue saved, by spending less. If that tradeoff is right for you depends on a variety of things, of course. "speed" isn't the only relevant metric that you may want to optimize for.
Don't forget startup and distribution time. It's not terribly hard to have a scratch rust container which is about as slim and secure as you can get. That container will startup pretty much instantaneously even if it's cold.
You are looking at ~5mb container vs 200+mb if you did a jvm based container.
It's probably overkill for most applications and companies, but it's something to keep in mind if you need fast scaling for cheap.
For webdev Go scratch containers are really nice and quick to develop. Of course the language could use better error checking but that's about it. It really does that job well. Fast, secure (GC and yes you can ignore errors the same way you can unwrap() the world).
Rust will be much lighter than any JVM app, but a fairly complex JVM app can be compiled to a self-contained JVM distribution on around 25MB these days... you use jlink to compile the app and parts of the JVM that you actually use.
Not to mention you can use GraalVM native-image to compile to a binary directly, in which case it'll be even smaller.
> This is true in some senses, but also, response latency isn't the only thing a web application does or is evaluated by. Many applications have, for example, background jobs, that do arbitrarily complex processing outside of the request/response cycle.
Yeah, for sure -- I deal with a web app that does complex, time-consuming analytics in data pipelines with Python, and Rust could help a lot with improving some of the complex calculations. But again, that's more using Rust as a C++ replacement rather than looking at replacing, say, the Python-Flask frontend that serves up the results of those analytics.
> Additionally, people who write web services in Rust talk about decreased memory usage, consistent memory usage, and lower CPU usage. In a cloud context, that can translate directly to revenue saved, by spending less. If that tradeoff is right for you depends on a variety of things, of course. "speed" isn't the only relevant metric that you may want to optimize for.
It'd definitely reduce costs, but yeah, be sure to get a full picture here from a business perspective. Engineers love to optimize AWS costs, but it isn't appropriate in a lot of situations. In my case, I'm paying a nontrivial 5-figure monthly AWS bill, but if my company's AWS costs went to $0/month... it wouldn't move our death date, and it wouldn't change our valuation. This is especially true if there were any loss in developer productivity/feature releases. I would gladly double my AWS bill if I could get features out even 20% faster, though that's not how it works, obviously.
One big advantage to developing in Rust that I have found over other languages is that you _must_ handle error-type conditions; for example, if something returns an Option or a Result you need to check that it was successful in order to extract the value.
This means that you don't accidentally forget a null check (or a catch block) and, in my experience leads to software that is a lot more robust.
Even if all it is doing is pulling from a database and munging it into JSON.
I've found that that's not really true for me, tbh. In theory, it absolutely makes sense that something like Ocaml would be more productive - you can completely sidestep most of the memory management stuff and just get on with writing working programs.
In practice, every time I've tried out Ocaml, I've bounced off _hard_. The standard library is very limited and filled with cruft (stdlib regexes being a notable example), so users very quickly need to start understanding the alternatives. There's little in the way of good intermediate documentation, so once you've figured out how recursion works, it's often quite hard to figure out more practical questions, like when it makes sense to switch to refs and imperative code for a problem. There's also not a lot of "practical" libraries - I wanted to write a small web service recently to organise house chores, and I figured I'd need a decent datetime library (with support for juggling timezones), some way of interacting with sqlite, and a basic web server. The web server situation was okay, but the only SQL library I could find was 80% ungoogleable sigils with minimal documentation, and I couldn't find a single datetime library that has a concept of instances that could be interpreted in different time zones.
In contrast, Rust has a clean (albeit minimal) standard library, with a lot of good pointers to well-maintained third-party libraries; it has plenty of documentation ranging from the beginner guide to the Rustonomicon; and there's a lot of stuff happening in the ecosystem that you can already start relying on. Like, if you're coming from Java or Python you might have to lower your expectations somewhat, but you can still have expectations of _something_, which is not my experience with Ocaml.
I think I need to try out F# more - my impression is that there's at least an existing C# ecosystem there which helps with a lot of the practical issues - but so far I've been really disappointed by my experiences in ML-land. There's so much I want to like - I'm really excited about the new effects work that's happening, for example - but the ecosystem as a whole just doesn't seem that usable for practical things unless you already know what you're doing, or unless you're prepared to build all the stuff you need from scratch à la Jane Street.
So actually, in practice, I find myself much more productive in Rust, despite coming from a Python/Java/JS background. The memory management stuff turns out to be pretty easy to pick up, and having a strong ecosystem means that I've generally got the tools I need at my fingertips.
That is the place Rust is for me, regarding the use cases I still care to reach out to C++, outside of compiled languages with automatic memory management.
If I do them in Rust, I would need to build from scratch and I rather not, as that isn't my focus.
Besides F#, there are also Haskell, Scala, Kotlin.
Java and C# are also getting there, even if a bit slowly, and compromised by backwards compatibility.
What are you wanting to build from scratch? I've not really had that experience in Rust so much, maybe that's just a case of working in different domains though.
Starting with Fsharp that has a gazillion libraries (usually pretty good quality ones) and it has much more advanced features from the ML tree than Rust (like |> for example).
Rust's error handling might be great for people who are used to exception based error handling but it is a joke compare to railway oriented programming in Fsharp or any ML lang that supports |>.
Rust has a well designed macro feature that can make it easy to add custom domain-specific syntax for use in Rust programs. We shouldn't underestimate the impact of that as a productivity enhancer, it's getting a lot of use already in Rust web-backend stacks.
So does plenty of managed languages. Manual memory management is still a huge detractor from the core business needs, slowing down development time and any future maintenance work (people often forget that it leaks into public APIs, so a memory layout/lifetime change will have to be propagated across code bases)
So I deeply love rust and it's my goto even for applications that it's not especially well suited for. I just know it well and it's easy and natural to work in. It's a flexible language so it plays well in a lot of use cases even outside the ones it excels most at.
With that said, it's okay if there isn't much in it for you. If it doesn't sound useful for your current use cases, that's okay. Don't use it. Use things because they are interesting and fun or because they make your life better. Don't feel the need to use it just because it's on The Orange Site a lot.
Rust is very much not a replacement for writing a program in a language that would have a garbage collector. It's main niche is making C++ obsolete, so categories where either resources are limited due to there just not being a lot of resources available (embedded) or are limited due to you needing to squeeze as much performance out of your machine as possible (OS, drivers, numerical computing, maybe someday video games).
It's probably not a good first language, but neither was C++: that's not its niche.
Even for embedded and other systems programming context automatic memory management via ref-counting systems can perform as well or sometimes even better. I found non-atomic ref-counting to be fine for embedded. For truly small programs I'd rely more on compile time computations which Rust isn't actually great at vs Nim or Zig, or a bunch of others.
Actually both C++ and Rust tend to make heavy use of reference counting via `std::shared_ptr<T>` and `Rc<T>/Arc<T>`, respectively. Personally I think that while Rust's borrow checker is nice for some cases and does encourage fast/efficient memory usage, it's also overkill vs automatic memory management for even most system or real-time programming. Especially as compilers get better and can remove 90% of the reference counting spots.
Ah true, I probably overstate the amount of Arc<T>/Rc<T> in Rust code. C++ uses shared_ptr<T> a lot in the code I've been dealing with lately, so maybe its biased me. Though it's partly up to the skill/experience of the programmer too.
And Steve said, "Let there be borrowing," and there was borrowing. And Steve saw that the borrowing was good.”. Tongue-in-cheek. My guess is that your experience and skills perhaps can’t be projected on to the average developer.
Nah. As the sibling says, these types do heap allocation, and a lot of embedded programs simply don't have a heap.
As esteban says, these types do get used more often in async code, which I don't write a ton of at the moment.
But more importantly, I think that if a beginner tries to use arc/rc to "get around the borrow checker" it introduces even more pain. It's not a beginner's tool, it's a possible misleading path. I left a comment a few years back with a practical example here; while the root cause isn't refcounting, look at how much ceremony they add https://news.ycombinator.com/item?id=24992537
If we were talking about clone, however, that would be a different story: clone is often a great tool for beginners who are struggling with a design that fits into what Rust wants.
And even then, the comment didn't qualify as "beginner code" or "expert code": it said that Rust programs generally "make heavy use of reference counting" and that's simply not my experience, nothing more, nothing less. Not only with my own code, but code I see others write, and libraries that I and others use. YMMV, as always.
Rc/Arc requires allocation, which limits its usefulness for embedded programming. It may become more useful once local allocators get stabilized, which would mean allocations can be made even absent a general heap.
Agreed, it's easy to avoid if you architect your code to avoid sharing state, or stick to only sharing state with children that will always be outlived by the parent.
I expect that Rust will include opt-in, pluggable GC at some point. It's effectively a hard requirement for programs that have to work with possibly cyclical references. (You can use weak references as part of refcounting in some cases, but it's not a fully general solution.)
This is a vague sentiment so it’s okay if it doesn’t mesh with you, but I like Rust because it’s a great example of language design done well. I’m not claiming Rust did everything right but I’d say it’s a great example of programming language design that manages to balance theory, practice, user experience, tooling and safety. I think any developer can learn a lot from Rust’s design. Including what not to do!
Also it’s just plain fun sometimes. I love expression based syntax where you can assign to an if or have a block result in a value. It just feels delightful. The standard library is very constrained but within those constraints it has a lot of wonderful depth. Functions like split_once or unwrap_or_else are delightful to use. It gives me that same feeling as Ruby where the language feels designed to have you enjoy writing code. The language has all of the requisite tools I want to model data structures including tuples, structs, and enums. It’s great! Try it out and see for yourself
I like rust, but wouldn't recommend it in my enterprise shop. I don't know what language you are used to, so I will suggest some things that you might enjoy learning about.
In languages without spread operators (like java), immutable objects are quite clumsy to work with: I want this same object but these two fields changed (like the replace method on python's named tuples, but those are also annoying...). But with mutable objects, everyone can mutate: chaos. Rust gives you the mut keyword, structs are immutable by default.
Ever wanted to implement a method on a class in another library that just used the public API? Just make your own Trait in rust.
Ever wanted to make sure that someone would call `close()` on your implementation? Ever wanted to make sure that no one would use the object afterwards? That's garbage collection of a resource that isn't memory, most GC languages won't manage that for you, but the borrow checker will.
Pattern matching, algebraic data types, expressions and statements distinctions, an excellent build system, procedural macros, no null, no exception handling, good type inference; none of these are new or unique to rust, but lots of languages lack a few to many of them.
But yeah, some times I don't want to decide between monomorphisation via generics, or heap allocating for dynamic dispatch. Some times I just want a JIT and a garbage collector to take care of that for me. But that is another thing rust might give you: a newfound appreciation for what you have.
A feature of modern computing is the use of very low power systems (I programme mostly for Raspberry PI - not very low power) and/or systems run on "pay as you go" platforms which can scale hugely.
Rust is very efficient at run time. (Not at programming time nor compile time) so is very useful in these cases.
A counter example, from my life, to illustrate: I ran a mail server for a group I was involved with. I spun up a VPS and Mailman. (Mailman v3 is built on Django/Python). I had to double the capacity of the VPS as 500MB of memory was not enough to install and run Mailman (I think the problem was at install time, but that made very little difference). The cost of my mail server doubled because of the inefficiency of the Django/Python framework.
Django is very efficient at programming time, but is resource hungry. The original Mailman ran in 40k, the "modern" version was not usable on a platform with 500MB.
For me it was no biggy. One server, $10 not $5 a month. Mēh! But if that were a million instances.....
So with all the progress in computers getting more powerful the actual instances we use are getting weaker (for very good reasons). A language like Rust can be very helpful in this case.
(On the Raspberry Pi I use Rust for realtime control of audio processes)
One niche platform is Sandstorm. Because of the way it is architected, a single “grain” is started up for a single document. So fast startup and small footprint is very useful, even if it is still a web platform.
As much as I like Elixir, it wouldn’t do as well running within Sandstorm as something written in Rust.
Many reasons actually. The tooling is excellent (builtin package manager, test suite handling, etc.)
The language itself is also very good in that it prevents you from doing many mistakes you'd do in other languages. It's hard to show an example when you don't know Rust at all, but usually Rust programs tend to have less bugs than others.
That being said, there are also downsides - apart from the steep learning curve, compilation is pretty slow and the language itself isn't as good as some others for prototyping - if you make something simple and want to go fast, then maybe TypeScript will do a better job, despite its numerous problems.
Rust is more about robustness and correctness (and performance of course). If these are not appealing to you, then sure some other languages like Java, Go, C#, TypeScript or others can do the job.
My day job uses the JVM heavily. I don’t have issues with garbage collection and don’t mind the languages to much.
I’ve used a bunch of common languages, Python, JavaScript, Typescript, PHP, Bash, Go etc. Not so common languages such as Haskell.
My first choice for personal projects is now Rust.
The memory/borrow checking to me is just a nice benefit I get from using Rust, I don’t use Rust for the borrow checking.
My main reason for Rust is while it’s not as high level as say Java/Python etc I find it is still at a nice level to work with and can be far more expressive with the enums, traits and generics.
The second big reason I use it is my programs end up fast and efficient with little effort.
The third reason is I can get tiny statically linked binaries that just run anywhere with no dependencies.
Reasons two and three mean I can host my applications on the cheapest, most minimal resources available and still outperform other languages on more expensive hosting. Currently my choice is to stick the binary in a Docker image which ends up sub with a sub 10mb docker image then deploy on the smallest 128mb AWS lambda and pay fractions of a cent to host. Services that need to be long running go on the smallest $5-10 vps’s .
The borrow checker can be a pain however I find the compiler error messages really helpful in it often tells you what you should do to fix the problem with plain English error messages and code suggestions.
You might want to check out GraalVM’s native compilation. While this step will be slow, you can just use the JVM version for development and compile it at the end/CICD step.
The only caveat is that the compile times are still comparable with C++ and Rust, when Graal kind of analyses the whole world to produce a final binary.
On middle range hardware, it appears to be the moment for a coffee pause, although it has definitly gotten better, specially with updated reachability metadata.
I have written another comment for a similar question, so I will paste that below:
---
I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in general.
I will also push back on other commentors here saying Rust is not good for web apps and APIs, and I have found that to be the opposite of true. I read Zero To Production In Rust [0] (a great book by the way, all about creating a web API with actix-web and Postgres) and deployed an API that has not gone down a single time since deploying near the beginning of this year. It's as ergonomic as (and sometimes even more so than) any NodeJS or Go API I've made (as even though Rust doesn't have function overloading, actix-web and others have some macro magic they do behind the scenes to make it appear as if it does), and there were very few times I had to contend with the borrow checker. If there had been and if I were really going for speed, I would also have cloned everywhere that was needed.
When I write something in Rust and it compiles, I can depend on it to work, and to continue working. At the end of the day, use the tool that makes sense for your business, but I don't think Rust was necessarily a bad choice based on my personal experience with it.
Personally, I'm finding myself reaching for C# to solve most problems I come across. Rust is appealing to me on a more theoretical level (or when there is a domain where it truly shines, such as concurrency or C-like performance).
IMO the strengths of the language are not a deal-breaker for a casual user (e.g. someone writing CRUD or line-of-business applications)
Not using Rust is also OK. I don't know Rust web stack enough, but my impression it's sometimes used to reduce AWS cost and decrease latencies, with some success.
But doing a rewrite requires Rust programmers and they hard to hire.
If you write Rust + Actix/Axum for backend, you'll never even see the borrow checker [1].
Rust is quickly growing into Golang and Java's space for web services.
My startup uses Rust in production for our web APIs, and we're really happy with it.
[1] You'll probably need to spend a few hours learning the language basics, but it's really easy at this point with the docs and best-in-class compiler error messages.
So it has a steep learning curve and it's not the "best" choice for people's first couple of projects.
But, before you can make anything meaningful with a language, you have to first make many toys. That's the rationale for using it in cases where there are better alternatives. (To make you comfortable using it when there is a need for it.)
It’s hard to say without knowing what exactly you’re comparing it to.
Because I already know Rust, and prefer it as a language generally, it’ll be my default choice, just like you have your default choice. It works well for many cases in the backend, but not all of them, like lots of technologies. If you don’t find a compelling reason to switch, you shouldn’t!
Learning (and I still am) Rust was great for me. I feel like it teaches good practices that you can also use in other languages and also it forces you to understand “how things really are working underneath”. That’s why it’s hard in the first place, but don’t put it in a corner just because of that.
As guy who has very similar background just like you: there is very little in Rust that will benefit your straight away. On the other side, you are going to learn a lot about low level details associated with systems programming (mostly influenced by C++ in case you are learning Rust).
For me the biggest win with Rust is the performance that I can get out of it, which is irrelevant in most cases. If you work on a problem that requires extreme single node performance then you can learn Rust instead of learning C++. This is probably less than 10% of the use cases people use programming languages for. As far as teaching juniors: I had great success with Python, yet, a lot of foot-gun situations. With Rust I am not good enough to mentor our junior devs, so we learn together. It goes very slowly.
It doesn't. Use C#, Java, or even python. If you're low level and dealing with low level code and constructs, you're better off using C, or C++ just for the language features like templates.
Rust is genuinely only useful for the niche application of a desktop application, that doesn't reach low level, but you need a bit more fine grain controls than C# or another higher level language will allow. For example, a web browser is like the ideal usecase for Rust, and it makes sense, since that's really where it's got most of it's teeth with Mozilla.
I personally don't see why you would do something like Grep, in Rust, when C#, Python, Go, exist. But I do see like Unreal Engine or again, Firefox/webbrowser in Rust being nice.
People have written greps in Go and Python (and Perl), and they aren't even close in all around perf to GNU grep (written in C) or ripgrep (which I wrote in Rust).
Maybe you don't know what you're talking about, despite coming across as certain of yourself.
Powershell actually ships one! I think you have a good point. I was going to build my own as C# ships alot of configuration options that can DRASTICALLY improve speed, which arn't on by default. But, we can test Redmonds version and get at least a decent idea of if it's suitable. I'll run some tests on that and get back to you in an hour or so. I'll use the same tests you have on https://github.com/BurntSushi/ripgrep/blob/master/benchsuite...
My testing will be on my Dev VM, in a WSL container on ubuntu 22.04, targeting a built linux kernel. With powershell from the Microsoft blobs they ship for linux. And Ripgrep from just Apt Install Ripgrep. With 5 warmup cycles for each.
Please be sure to read my blog post that I linked very carefully. Benchmarking greps is rather difficult and quite subtle.
Are you talking about findstr? If so, I'm not sure that's available on Linux. So it doesn't seem like a viable grep to me. If the program you want to be a grep only runs on Windows, then that isn't really viable.
Also, Windows file system operations tend to be quite a bit slower than Linux.
Alright, so initial testing result. I'm not going to even bother putting into excel, RipGrep blew the hell out of Powershells built in stuff. Like, we're talking exponentially quicker, so well done. (3 minutes for Pwsh vs 2 seconds Ripgrep)
But I don't think it's the fault of C# and I think it's the fault of some poor coding on redmonds side, and very good coding on your side. And since I have to make up 12 hours tomorrow at work, but have zero tickets. I'll probably go in and write a Grep utility in C# and I think I can get similar speed to the Rust implementation.
C# is also cross platform as of a couple years ago, as well as is powershell. So my testing was running Powershell on linux against the newest linux kernel source code + the build artifacts.
I think you've kind of already moved the goal posts. Your original comment spoke as if it were factual. But now you're saying "I think it can be done." But you don't know. And on top of that, there have been many greps written in a variety of languages: Go, Python, Perl, Ruby. All of them, that I've tested, are slower than most greps written in C, C++ and Rust. (In some cases, the greps written in Go can be quite fast, but they have very steep performance cliffs that are easy to trip over.)
There are very good reasons to explain this state of affairs.
C# is not something I have a lot of experience with. I don't spend time with Windows-only technologies. C# may technically work on Linux these days, but I don't know of any popular general purpose CLI tooling built with it that works on Unix systems. Why is that? My suspicion is that there are good reasons for it. But if there aren't, then there is a market opening waiting for folks to plow forward.
Basically, I think you are wrong on multiple levels. I think you both under-estimate the difficulty of writing a fast grep and what exactly it takes to do it, and I think you're completely wrong about when Rust is useful. You completely neglect the safety aspect of it, and seem to believe it is not on even footing with C or C++ when it comes to performance. But it most certainly is, in general.
> But I don't think it's the fault of C# and I think it's the fault of some poor coding on redmonds side
Making baseless assertions feels like a pattern that is forming in your comments. Where is Redmond's code? Can you read it and link to me the parts that are "poor"? If not, from whence comes the accusation?
And if you insist with your interpretation of reality, then it follows that I therefore must be a good coder. And if a good coder says to you, "I do not know how to write a fast grep in Go, Python, Perl or Ruby," then why don't you take them seriously?
You keep seeming to come back to "needing the source code.". You know you can reverse engineer a program extremely easily right? Especially a C# one? It's really not the gotcha you think it is. And you can easily see from heuristics that it shouldn't take nearly a minute to gather all the filenames from subdirectories as with GCI. Doesn't take an Einstein to do that.
As for the safety aspect. Can you tell me what Rust means by "Safety"? Alot of Rustacians throw it out, but it really only means "No Undefined behavior". It can help hint at issues, but as someone who writes C code day in and day out, a proper coding technique like SESE can prevent all the issues Rust prevents, and a Static Analyzer like SAL goes far and beyond it. And then with all the icky runtime checks Rust adds, you can't get that in the Kernel, you can't get that "for free". And speaking of reversing your code, it throws in your path names, your file names, and information about the code into each of these. It's definitely not safe opsec wise for a dissident in a dicatorship or an activist!
You also seem to claim C# is "Windows only". Neither C#, nor Powershell, are "Windows Only". C# can run on just the same targets Rust can. WASM, Linux, Windows, etc. You said I wasn't talking about things I was knowledgable on, but despite multiple "hints" on that it's not "Windows Only", you don't seem to want to accept that. It's been the case for years. Being that stale with tech would be retire or fire territory, or just an indicator of incompetence.
And I never said you were a good coder, I said you did a decent job writing RipGrep based off of performance. I personally think from your comments that you have a very small amount of experience with Language design or low level programming, and would not hire you and would put in my review "Does not take hints, is very rude and stubborn."
You call my claims baseless, I went and did testing on the PS commandlets and said they were not fast. I have a program i'm testing right now which matches RG in performance. I'm going to name it "RipGrep But Not Ass". I'll have it on github for you whenever I get the time to finish it. Then you can "Analyze the source code". This conversation is dumb, and you are honestly one of the worst people i've encountered in the coding community.
> You keep seeming to come back to "needing the source code.".
It's important to understand what is being measured. It's not required in the strictest sense, but I am after understanding and without the source, that is difficult. If it doesn't take an "Einstein," then surely you can provide a link either to the source of whatever program you're measuring or some simple instructions for discovering it?
> a proper coding technique like SESE can prevent all the issues Rust prevents
Sigh... So many words on the Internet have been spent on this and related topics, and I do not have the energy to repeat them. If the only education you have on the matter are the words of "Rustacians," then there is plenty more for you to seek out. Maybe start here: https://security.googleblog.com/2022/12/memory-safe-language...
> And then with all the icky runtime checks Rust adds
The only runtime checks ripgrep omits are a few bounds checks deep in the regex engine, and even that gains a 5-10% performance improvement in only some workloads. It would not meaningfully impact ripgrep's overall performance. And yet, ripgrep is faster than GNU grep straight up in many/most cases, which is written in C and lacks your supposed "icky" runtime checks.
> And speaking of reversing your code, it throws in your path names, your file names, and information about the code into each of these. It's definitely not safe opsec wise for a dissident in a dicatorship or an activist!
I'm not aware of any official Rust materials or anyone with any credibility advocating otherwise.
> You also seem to claim C# is "Windows only".
I caveated all such mentions, yet, you seem to ignore them.
> Being that stale with tech would be retire or fire territory, or just an indicator of incompetence.
OK, wow, this conversation has gone to another level. Not really sure what to make of it. I am not retired but gainfully employed. Perhaps I am incompetent, it is not for me to say. Much of the code I have ever written is public, so perhaps you can judge this quality yourself. And if you do, I would love to have any learned critique.
¯\_(ツ)_/¯
> And I never said you were a good coder
I didn't say you did. I specifically and carefully drew an inference, but one you clearly dispute.
> I personally think from your comments that you have a very small amount of experience with Language design or low level programming, and would not hire you and would put in my review "Does not take hints, is very rude and stubborn."
Perhaps you confuse skepticism with rudeness. I am here challenging your claims, of which you have provided zero evidence, but for which I have both published code and published analyses that dispute them. I am glad, though, that my employment does not depend on the whims of random anonymous denizens of the Internet.
> You call my claims baseless, I went and did testing on the PS commandlets and said they were not fast. I have a program i'm testing right now which matches RG in performance. I'm going to name it "RipGrep But Not Ass". I'll have it on github for you whenever I get the time to finish it. Then you can "Analyze the source code".
I'd be happy to analyze it and provide commentary, welcome or not.
> This conversation is dumb, and you are honestly one of the worst people i've encountered in the coding community.
I'm sorry for having troubled you so. I don't mean to come across as rude, although I can see how you might take it that way. I am not really a fan of commentary that states things so certainly but which are contrary to what I perceive to be reality. In so doing, I presented my view of reality and have yet to see a competing version that I can engage with. It is precisely because of that ignorance that I have asked for something that I am able to engage with. I cannot, without expending more resource than I care to, engage with something that is Windows-only or requires a Windows environment to test in. I did not mean to say that what you were doing had those requirements, but meant to merely state what my requirements for engaging were. The point of being clear is not only for me to avoid wasting my time, but for you to avoid wasting yours.
But, I would be happy to do so on my Linux machine if it's possible and update my version of reality. Surely, given that I know little of C#, there is much for me to learn. I note though, that your original comment mentioned several languages other than C#, and my original response did not call out C# specifically. The reason being, of course, that I acknowledge my ignorance of that technology. (And have done so in this conversation before this comment.) Even at the risk of labels of incompetence or staleness from HN commentators.
Why would you compare C#/pwsh PCRE with somethign that is not PCRE and hence has different features. Compare with rg that has --pcre option set if you want to get real comparison.
Why wouldn't you? The other poster hasn't even said which regex engine or which tool they're measuring.
PCRE is absolutely a competitor to Rust's regex crate and it makes sense to compare them.
If all you're doing is measuring the time it takes to find `foo` or `\w+_foo`, then the specific regex engine being used is just an implementation detail.
I'm not saying that using --pcre2 is wrong. It is certainly a useful comparison. But using the default regex engine when the task is "measure a grep" is certainly not wrong either.
Grep is a performance sensitive program, it's not unusual to scan through thousands of files and millions of lines so small inefficiencies are noticeable.
If you tried this in python it would probably take hours to scan through something that ripgrep does in a few seconds
Honest question, but I don't seem to understand the base context of what you're saying. If you're a backend dev, you care more about performance than a front end dev does. That's why backend devs generally write software in something like C or C++ where Rust would play in perfectly. However those languages have security issues and trade that off against performance Why would you say that Rust has no relevance to a back end dev when from my understanding Rust is THE perfect language for backend devs because it maintains the speed of C and C++ but adds security? What is the context that I'm missing?
This is not my experience most backend uses php, ruby, python typescript, java definitly not c or c++ and most performance is usually gained by optimizing queries, adding indexes avoid doing work and caching.
The low level libraries used in these languages do often use c, c++
It's completely okay for rust not to overlap much with your work. If you aren't doing a lot of systems programming type jobs it's probably not all that applicable to your day to day work. If you're interested in systems programming then you might look into it. Seems like Java or typescript or ruby|python|php would be more up your ally and I assume you know one or more of those as a part of your work.
I think the popularity is helped by the fact that it's rarely useful in the day job for most people. You can have your Rust tinkering and there's a natural moat between it and work. It also automatically throws the safe and useful seemign borrow checker puzzles at you that don't involve the outside world.
Pretty sure it's the other way around - Python used to be something that was "not useful in the day job" and mostly about tinkering. This has changed dramatically over time, so Python is now a lot more popular.
Python used to be moated away from enterprise/corporate world as well, and this made Python loveable for the hackers & hobbyists before it went mainstream. So it's the same way around :)
In Python's case the pull was different in quality, it was about a higher level more expressive language that could get more done faster compared to the estabilished corporate/enterprise languages.
Thanks for the mention Adolfo! Never knew that I was in the causal chain of your journey to Rust. Hacker News is definitely a gateway to random experiences :)
I've had quite the opposite experience in fact. You can find numerous topics on places like r/rust where people talk about the downsides of the language compared to others (for instance).
I think this is the big difference. The tone in comments about /r/rust is dramatically different than the tone in /r/programming. I often see some pretty crazy RIIR evangelism in /r/programming.
I don't know if this is a comment about rust the language or reddit commenters.
/r/programming (and all of the other major generic programming subreddits) generally just do not have good conversation (or at least have much more noise to signal), as a large percentage of the community is very inexperienced. Same thing goes for non-programming, high subscriber count communities. You eventually get a lot of people who think they are knowledgeable about a topic because they've read a lot of topics on the subreddit, but they're really just inexperienced people parroting the opinions of other inexperienced people.
I've found there are two entirely different worlds within the Rust community.
Rust does attract a weird subgroup of people who can get preachy and pushy about there only being one way to do things.
But the helpful part of the community is much bigger and much better to work with. You just have to look past the loud people pushing agendas and stay out of flamewars on Reddit and HN.
It's the over-enthusiastic zealots. They're not unique to Rust. For example the golang community has equally defensive people who believe that Moses carved `if err != nil { return err }` as the 11th commandment, and anyone who wants less verbose error handling is an enemy of simplicity.
I have yet to run into the first type and I hope I never do. I’ve had such wonderful experience of people willing to help. Even big names like Steve Klabnik graciously offered some responses to my very elementary comments and questions.
The only community that’s been just as wonderful is the TypeScript community on Discord. Gosh they set the bar high for expectations on getting language help.
> The Rust community is easily the worst thing about Rust. The constant preaching and cult-like reaction to any criticism is very offputting.
I've seen more comments talking about this supposed phenomenon than instances of this phenomenon actually happening. I haven't really seen any examples of preaching and cult-like reactions, I just see people talking about how it supposedly exists somewhere.
Or maybe it's a meme at this point. I really would like to be furnished any examples of "cult-like" behavior from Rust users, because I have not seen any.
I've noticed a very big difference between comments about rust on general programming sites like here and /r/programming and comments in rust specific spaces. I find people in rust-centric spaces to be calm, reasonable, kind and pragmatic. Some of the worst rust evangelism I've seen comes from posters who I'm not even sure have written serious amount of it.
I agree with you that it can be really off-putting. From my perspective what you are seeing could be more of a comment on some of the know-it-all dilettante types who fawn over trendy tech in comment sections than the rust community itself. I've always had great experiences when reaching out for help in discords, user forums or other spaces. I've seen similar patterns with other trendy technologies in the past too.
At some stage there was a squad on StackOverflow who closed all Rust related beginner questions and it was impossible to get started. Most devs new to Rust do not understand &str and String and 99% of the content about is how implementation details backing those types are different. I have not seen any blog post, documentation about how and WHEN to use &str vs String.
I want to have a function that returns the UTC now as a string. Now what? Opening a question on SO -> question closed, here is a question about &str and String that has nothing to do with the use case and everything about the implementation details of &str. Good stuff.
I think the creator of Rust assume that if they explain where a piece of data is allocated suddenly everybody is going to be on the same page about the use of that data.
First off, Stack Overflow is super close questions happy. Asking a question without a minimum code example gets it closed before you can say MVP. Same for mark as duplicate.
> Most devs new to Rust do not understand &str and String and 99% of the content about is how implementation details
Which part didn't convey the info you wanted? How would you convey it?
Curse of Knowledge is real, so to me it looks trivial, but I started Rust before str/String were a thing. I don't know what it's like to start learning Rust.
> I want to have a function that returns the UTC now as a string.
Now what? Opening a question on SO -> question closed, here is a question about &str and String that has nothing to do with the use case.
That's on Stack Overflow overzealous moderation. If I had a dollar for every question of mine that was closed with mark as duplicate, I'd be a richer man. Doesn't mean it was specifically Rust community.
Did you consider Rust Discord? I asked few very technical questions and I got some really good answers.
I agree. I usually teach with example. Sort of here is a situation, this is your input now write something (a function, sql statement, etc.) to produce the desired outcome. While doing so I explain all the relevant details (this might be a good time to talk about different allocations for example).
This works surprisingly well. If you reverse the order (talk about different allocations first) the student need to connect the dots later.
Rule of thumb: use &str when you don't need more than that, use String when creating text at runtime, returning from a function or storing it in a struct field.
Using borrowed values in general in fields is best avoided until you get more comfortable with the rest of the language.
Rust has no GC, so to use it you need to learn how memory allocation works. If you don't want to bother with those details, use a GC language instead of Rust.
If you are struggling to learn these things, even after working through the Rust book and other commonly cited resources, my suggestion would be to drop Rust for now and learn C. In C, pointers, stack/heap, malloc/free are things you have to deal with directly, so you can see how things work under the hood. And then, when you go back to Rust, you can map your hard-earned C understanding to the Rust abstractions
Having been moderately involved in it, that isn't my impression. They were a helpful and informative bunch, and I learned a lot from them.
That said, being an outsider, I'm reminded of this quote from a recent article:
> "What was the deal with [person X] on your team, why are they such a jerk?" (Sadly, if you worked on Chrome you probably know exactly who I'm talking about.) The experience gave me an appreciation for how a group, especially a faceless internet group, can be perceived by its worst behavior.
I do a sort of language-per-year thing for my sins. My previous two were clojure then elixir, Then this year it's been Rust. I've found the Rust community by far the least pleasant to deal with. For the most part, it is fairly helpful (though no more than the others). But there is an implicit contract that to get help you must admit that Rust is the best thing ever, and that if you have any difficulties with it, you agree that it's because you're a bit thick or lazy. Stay within that lane, and smiles & help will abound.
I'm not quite sure why the Rust community is so dogmatic about the language's intrinsic excellence. I never found anything similar with the clojure or elixir communities (which each has its own distinctive style of response to beginner difficulties). My speculation is that Rust has such a strong inclusiveness mandate (which is a good thing in my view), that intrinsic difficulty is threatening to the group's identity. The impulse therefore is to deny the difficulty, from which it's a short step to pointing to the beginner as the source of the problem.
I don't know if this is related to your experience, but one thing I have noticed a lot is that new Rust programmers experience some friction point with the language and suggest some sort of change to address it. This sort of feedback almost always seems to be rejected by other Rust users.
I don't believe it's out of a sense that Rust is perfect as it is. There are loads of discussions about where it does a poor job and how it can be improved. The problem is that the feedback from these new users is usually poorly received because the person has an incomplete understanding of the language. They may not understand that there is another, easier and more idiomatic approach to whatever problem they experienced, or they might not understand the values that underpin the language (Bryan Cantrill has a fantastic talk on this [1]). Others being uncompromising in these respects might come across as elitist or condescending.
I have seen a bit of that, but no more than in other language 'communities' (I mention Elixir and Clojure a few times here, because these are the most recent languages I've been a beginner in).
But that's not what I mean. I'm referring to the denial in the Rust community that it is difficult, when people are expressing the difficulties they are actually experiencing. The default position amongst Rust enthusiasts is simply to deny that the difficult thing is actually difficult. I have not experienced this anywhere else. You can even see it to some extent in the official tag line "A language empowering everyone to build reliable and efficient software". As this axiomatically applies to 'everyone', it logically follows that if you can't use Rust to build something or you're having difficulties doing so, you are either a bit dumb or lazy.
Now of course, if I really drew this inference merely from a marketing slogan, it would be a cheap shot. But I find it pointedly representative of the Rust culture at large. It is polite, and often fairly helpful, but there is a sort of glassy indifference towards struggle or friction. Asking questions online about Rust often feels to me like talking to a corporate rep.
[PS - thanks for the podcast pointer. Corecursive is in my subs but I haven't listened that far back. I shall]
Rust forces you to think of memory ownership. In turn challenging you to design more carefully your data structure and their relationship.
I think this extra effort is experienced differently by different people. But then comes the enlightenment. When you are comfortable thinking of ownership and pleasing the borrow checker without fighting.
And I wonder if sometimes people try to hide how long it took them before enlightenment. Or forgot how much work it was to update ones thinking.
My personal experience with the Rust community has been great. But it was also almost 9y ago. Things may have changed.
I haven't personally had any trouble with Rust's ownership model. It's pretty straightforward. I have found other aspects of the language and associated libraries difficult enough that I've made little progress with real projects. But that's not really relevant here. I'm more referring to the Rust community's characteristic cultural response to difficulties when they're raised, which seems (in my experience) to be first denial, then (generally polite) finger pointing.
> When you are comfortable thinking of ownership and pleasing the borrow checker without fighting.
That's kind of it. Saying "Rust forces you to think of memory ownership" is more accurate at the beginning, but not so much once you're experienced. Rust doesn't make me think about ownership: that's why the compiler checks it. It points out when I've made a mistake, and I move on. That I don't need to keep the rules in my head is kind of the entire point!
It's kind of both. I experienced this with Advent of Code, the other day where I had a vague idea of the data structure I was trying to work with, and the approach I wanted to take to solve the problem, but I started banging into errors from the compiler. I had to step back and take a moment to think about exactly what I was trying to do and what that meant for the model I was using.
My approach wasn't wrong and it likely would have worked on my first shot in Python or C# or something, but the fact that Rust cares about ownership meant I had to think about it too, even if I only really did that after the compiler pointed out that there were some issues.
My personal bigger issue is that at least some parts of the "community" often has a very harsh left to far-left swing to it that I've run into a couple of times that reacted with explosive hatred toward me when they realized I wasn't one of them. Yes I have some right wing views, I still want to use Rust though, but that doesn't mean I should feel forced to adopt your personal brand of far-left progressiveness. I hope that will even out given time.
I think it makes a lot of sense? A language has a surrounding set of commonly used and well adopted libraries for things that are common, but just not critical enough to get included within the standard library. E.g., having serde as a cornerstone for encoding/decoding means that, e.g., I can integrate with a decoder for complicated types easily, and I know how to do that independently of whether it's JSON, or TOML, or …. Having thiserror to help make rich error types.
C, admittedly, doesn't really have that. But I think that's mostly to C's detriment; projects have to sort of fill in those blanks themselves. Largely, I don't think they do: C libraries heavily prefer to return ints for errors, and I don't know that there are really "common" libraries out there? Certainly not to the same degree. (I wonder if the efforts didn't get focused onto higher level languages.)
Today, I'd mostly reach for C++ before C. Relatively¹ safer language, and the STL is far richer, and has basic data-structures that one requires for ordinary tasks. The situation is marginally better, e.g., there's boost, and the STL has seen some growth over time.
The downside, I'd say, is a single implementation and a looser spec, whereas C is standardized and runs on far more platforms.
¹and I mean relatively, as it is pretty trivial to utterly annihilate one's leg with C++
C is standardized by an ISO working group, and then there are multiple independent implementations. Rust is developed in the open, on GitHub by a single organization, which creates a single center for community to naturally aggregate around.
That's funny. My first programming 'community' was entirely comprised of computer magazines and a gruff alcoholic ex-academic who would occasionally throw a manual at me and bark corrections.
That's true in the limit - if you go in guns blazing then any community is going to get defensive. But I have found the Rust community to be uniquely thin-skinned. This is only one person's experience, I can't provide any real evidence beyond my own memory of interactions.
Crude sketches of my experience presenting beginner difficulties to a few communities:
Clojure: "yes, clojure does tend to be used largely by experts, which can present some difficulties", followed by many friendly suggestions about how to get there
Elixir: "you're having trouble? Hmm that's not good. Try this for now, and let's see what we can do to improve matters"
Rust: "no, you're mistaken, nothing in Rust is difficult if you're smart or hard-working enough"
> Rust: "no, you're mistaken, nothing in Rust is difficult if you're smart or hard-working enough"
I feel the need to mention that that attitude isn't welcome in any of the communities I participate in and I make sure to call it out when it does rear its ugly head. Personally I bend myself backwards to try and meet newcomer developers where they are when it comes to the way the compiler uses diagnostics.
The closest I can think of to this attitude being prevalent is "what are you trying to accomplish (because the way you're trying to do it is going to be harder than you're ready for yet)?", which doesn't mean "you're stupid/not hardworking" but rather "there's collective wisdom about how to work in the confines of the borrow checker, and going against the grain while also learning the language will put you off the language".
Well it's common on the Rust user forums in my experience. I had intended to have a good stab at Rust in 2022 as I typically learn a new language per year (to varying degrees). Having failed to really get on very well with it I'm going (for the first time) to continue for a 2nd year and try Rust once more in 2023. But I don't plan to engage with the Rust community again - there are lots of great learning materials around and I'd rather go it alone than run the smug superiority gauntlet.
Politeness and receptiveness are entirely orthogonal qualities. The Rust community is indeed mostly polite. That's a good thing I think, but it can paper over a good deal of dismissiveness (expressed as politely as a Victorian men's club sneer).
I don't think it's the same for the languages that you listed, they seem much more pragmatic and willing to acknowledge flaws and tradeoffs. Maybe the Julia community comes close to Rust in the degree of cultiness.
I feel like the Rust community right now is being flooded by “fanboys” that have heard that the language is great for x and y (and x, y really are great probably), therefore they continue to push only those cool parts of the language but they didn’t even write a single line on code in production with it.
That’s why I’m saying that you find those people in most communities. Rust is just the trendy one right now so you just notice it more.
As someone who both loves Rust and is very much anti woke leftism, I don't think it's a huge concern at present. Much of the leadership happens to be woke but it doesn't get in the way of technical discussion. That could change, of course, but for now it's not causing problems
Yep. Just search “borrow checker” on their subreddit. Any post pointing out an instance where it makes things overly verbose and complex is immediately met with downvotes and “why do you need to do that”s.
I tested that out and mostly only found positive, constructive comments. I only found 2 cases of someone complaining about verbosity though. Searching "borrow checker verbose" doesn't give many results with complaints.
They don't have to be complaining about verbosity, it will suffice to just have an example where the borrow checker gets in the way to be met with downvotes.
You can also try searching "linked list" or "graph". And here are some bigger posts that are genuinely critical, met with the typical rustacean response:
They forget themselves how it was for them at first (the curse of knowledge). New comers might even get onto the train and pretend they know better for appearance's sake. Murking the water.
Remember if you know better than the borrow checker you can use raw pointers. There is very little friction. But are you sure you can do better without the safety of the borrow checker having your back?
Rust purposely handicaps ergonomics, even when it wouldn't come at the expense of safety. This is just one example. Rust also doesn't have function overloading, default arguments, named parameters, anonymous structs, unwrap sugar (like !! in kotlin), etc. Rust's aversion to user choice precisely what is hampering its adoption. Docker and kubernetes are written in go. Unreal engine, high frequency trading systems and most of google is written in C++. What significant thing has been written in rust? it's forever going to be a hobbyist language competing on stackoverflow surveys instead of actual large-scale applications. Nobody with any actual money on the line wants to take the hit in productivity to switch to rust, at most it's used for a small part of a larger project written in another language. By the end of the decade there's going to be more things written in carbon than in rust, and that sucks because it was completely preventable.
As someone else has stated, you have not said anything of value here and are just vaguely screaming into the wind. Do you just find people being highly enthusiastic about something off putting? If so, do some introspection.
