Wanted to point out one potential side effect of their primary point. If you have a team of system developers fully proficient in Rust, and the next task is to build some middleware web API, Rust could seem like an obvious choice, because everyone on the team already knows it and loves it. However, unless you plan on having these developers work on web APIs forever, there is now a huge barrier for future hiring because none of the millions of developers out there with experience in C#, JS, Java, Go, Python and the like are qualified to work on this simple backend. You have narrowed down your hiring pool to expert Rust developers even though all you need is a new college grad who can start a Flask server.
At Oxide, we do "web API layer" stuff in Rust. We also don't require that candidates be Rust experts, though obviously experience helps. Many of those people who are "proficient in C#, JS, Java, Go, Python and the like" can absolutely write Rust, even if there is some slowness at first.
You have to be willing to believe that and consider it when hiring, of course, which some organizations may reasonably not be willing to.
I’ve been working primarily in .NET the last five years, and have been transitioning to Rust professionally the last few years.
For some reason, people act like being a C# or Java dev means that you’re an idiot. If you’re skilled enough to be writing quality high-performance code in those languages, learning Rust is not a huge barrier…
I agree with you: learning a new language, sometimes in the heat of the moment without even knowing the language existed before, is a thing skilled software developers are able to do remarkably quickly, even if they haven't specially gone out of their way to train for that skill, as, in the real world, you end up dealing with so many different languages--as a C#/Java developer you probably also have had to work with SQL, either bash or PowerShell, can't really avoid JavaScript, likely had to drop to C/C++ at some point to build a way to access a "legacy" component--that it is very difficult to avoid having the right generalizations happen accidentally in your brain.
But, I work with a lot of college students who are just beginning to learn software development, and the realization that that kind of generalization is possible is not obvious; and a lot of people who are only a few years into their career--but maybe think they are pretty damned good at it (I look back at myself when I had a mere 10 years of actual-real-world experience and think just how much I still had to learn to become who I am today... I am thankful I worked with some gods and always knew I had a long way to go)--not only have a hard time learning a new language (I remember when I was in high school trying to learn Pascal after I had spent years coding in Visual Basic and even getting paid to do so, and thinking I knew C... I did not ;P) but internalize how daunting it is and then go really far out of their way to avoid learning new languages (which, thankfully, I could not as high schools at the time were ping through a big upset in curriculums and so we learned a new language every year for a while and I got recruited to help my AP Computer Science teacher as he also was having to adjust way too quickly through Pascal, C/C++, and Java/JavaScript).
And it is actually quite remarkable how well people manage to do at this, using IDEs to avoid command lines and ORM technology and DSL compilers to avoid having to use SQL or other languages, they glom onto whatever ridiculous interop mechanism they can that prevents them from learning about low-level languages... and I think it really does hurt them, and I remember running into some software developers who did so well that they never managed to get to the right generalizations and they are now old and can still only program in one language (the same way I have a really really really hard time speaking in any language other than English); but like, most developers, no matter how hard they try, eventually do get enough exposure to enough at least slightly-different languages to get this skill (which is, when I get hired to teach courses, what I try to accelerate: Comparative Machine Language Morphology ;P).
But like, due to us all living in the Eternal September--and I do not just mean online: I was shocked recently when I learned how many CS students there are at most of the other Universities (it turns out the one I still live at is an extreme minority with only a few percent of the population being Computer Science and only half the students being engineering at all)--not only are we going to end up interacting directly with a number of people who actually do find learning new languages hard (and think it must fundamentally be hard for everyone forever), but I think we are going to run into a lot of managers on the front lines of trying to build businesses out of cogs (a practice I dislike on a number of grounds, but fully admit, if you can pull it off, is probably an extremely powerful and efficient way to do industrial/corporate engineering) who are also extremely resigned to the notion that the early-stage people they hire are oft incapable of learning new languages quickly enough to truly be a usable cog, as like... do they really even want to hire someone who has as much experience as you must (as the way you worded your comment implies you've been coding a lot longer than the mere 5 years you have been coding in Java/C# ;P).
I can appreciate why my statement there might seem overly dismissive if you want to get particularly defensive; but I'm commenting on people, not technology, and I've met/seen quite a number of developers who rush to and relish these technologies to actively avoid learning languages, and list such as their primary reason for their use.
> I agree with you: learning a new language, sometimes in the heat of the moment without even knowing the language existed before, is a thing skilled software developers are able to do remarkably quickly
Maybe it is true, for some people and for some languages.
However, learning the syntax of a new language means nothing if you don't already learn libraries, tools, frameworks, tools, patterns, idioms. And that still takes time.
Memory isn't unlimited and while you learn new concepts, try to make room for new concepts, you start to forget some of the old concepts, especially if you start using them less frequently or seldom use them.
So, what I try to teach in my Comparative Machine Language Morphology course is the skill of being able to go from nothing to expert in a technology almost immediately by trying to get your brain to generalize into what we know about how humans conceptualize algorithms.
To tell a quick anecdote: when Apple announced Swift, I was hearing about it for the first time in the audience at WWDC during the keynote. As I watched, it was quite clear to me that this was a language that was mixing parts of Scala, Haskell, and (awkwardly enough) Ruby with the background of Objective-C, and it just immediately clicked. I ended up giving a talk about the language a few days later at AltConf.
The reality is that, unless people go extremely far out of their way to push their language in a way that makes it awkward for the user--I had a student who designed an esolang based on gravity and "roadrunner physics" where the code was a map where things didn't start to fall until they had some kind of interaction--there is very little "new" under the sun: the vast majority of "advances" in programming languages were already pioneered many decades ago.
(The most ridiculously-obvious example of this is probably Go, which has almost nothing that wasn't already understood by the 1970s, including its mechanisms around channel-oriented concurrency. There is an amazing article that attempts to compare Go to a "Brand X" language that turns out to be Algol 68. But like, Rust's entire schtick--the reason it is called Rust!--is because they actively refused to do any new language research and instead based it all on well-worn concepts, and yet people still whine about it incessantly merely because they haven't put anywhere near enough time into learning about the history of programming.)
There is a learning tax at the beginning, for sure, but this is a fixed cost. We experience that once this first hump is passed, the code and output quality is higher, and the cloud resource cost decreases significantly.
Now the challenge is to hire new developers that are not familiar with Rust; it would take a month or so for them to be productive (assuming robust internal code practice). But, well worthwhile in our opinion, as least for greenfield application/services.
How long would you say it takes your average, competent developer to become proficient in Rust? In your experience, what's the best path to learn Rust in 2023?
My current employer has a web backend and CLI in Rust. I joined the company having only dabbled in Rust, but having a background in C++, python, javascript, and verilog. It took me a month to feel able to do things and 3 months to feel reasonably comfortable. Still haven't mastered it after 1.5 years. Certain pieces of the rust ecosystem have their own learning curve such as diesel orm.
As a fellow rust n00b, one of the big problems I'm seeing with using ChatGPT to generate rust is that it often doesn't have a good model of ownership semantics. This has caused me lots of burnt time working through plausible but not accurate solutions to problems.
> How long would you say it takes your average, competent developer to become proficient in Rust?
I think it's exceedingly difficult to make such a broad generalization. There's a number of factors here at play, but for example, I think the struggles of a Rubyist learning Rust are very different than a C developer learning Rust, and are very different than someone who's proficient with both who is learning Rust.
It's also hard because there's also just other random factors. There's a semi-common experience where people try Rust, think it's too hard, quit, and then come back 3 or 6 months later, try again, and are completely unstuck. Sometimes it takes coming back two or three times. Do you count all of that dead time? Something in there helped, but it's unclear what, or why this affects some people.
Another theme of stories I've heard is a sort of Golidlocks situation about how "right" you think the compiler is. Some folks have the attitude that the compiler is to be seen, not heard, and should stop nagging them about things. Those folks tend to really struggle with Rust, even if they have lots of relevant experience previously. Likewise, some folks trust the compiler so completely that they will lose a bunch of time when a compiler suggestion leads them down the wrong path. Luckily, that problem is easier to fix than the former one, and is rarer and rarer every day. But these sorts of attributes are completely separate than what we think of when we talk "competency" of devs.
> In your experience, what's the best path to learn Rust in 2023?
This sounds tautological, but bear with me: it's whatever path gets you to learn Rust. That sounds trite but what I mean is that different people have different needs (see above) and so need different things. There is no one best way. For some people, the book works really, really well. For others, they either hate the writing style, or the pace, or just something ineffable. I wouldn't say that they're wrong for that, just that they'd be served by different strategies.
What I will say is that "I know other languages, I can just kinda start coding and pick it up" tends to not work for almost anyone. You either need to be quick to ask questions from the community, or be willing to do some reading, or you may run into some struggles that will take you longer to overcome than if you were willing to get some help. Folks who take advantage of community resources, broadly speaking, tend to do better than folks that think they can write some code and learn solely through errors, as Rust's semantics are just unique enough that some background and explanation can be extremely helpful.
> There's a semi-common experience where people try Rust, think it's too hard, quit, and then come back 3 or 6 months later, try again, and are completely unstuck.
This was my experience, I came back a year or two later, and both I and the language had improved. I'm not sure who improved more, but whatever happened I'm really enjoying the language now.
6 months if you're a college-sophmore-level student doing it part-time (my own experience + numbers), I'd estimate 3-4 weeks if you were spending more than 3hrs/day on it and knew 2 other languages.
That would be my estimate as well. I've seem some porting between Go and Rust (both ways) where either way an experienced developer with some multi-language knowledge got up and running in a day, writing useful code in a week and being proficient enough to do normal sprint work in about another week.
It mostly depends on what you have in you brain, what you see when you look at code, and if you understand why you do what you do rather than repeating a trick and hoping it works, and I suppose that is a combination of theory and experience.
The tokio tutorial is (mostly) pretty well written and worth a read.
There's a lot of good docs like rust-by-example and the rust book, but for my liking, those both seem to spend too much time on each topics rather than distilling the info into smaller denser topics. This is probably great for newer developers but more difficult for someone that wants to learn the 30 second version of something rather than the 5 minute version. It's possible that punching these books through a GPT prompt like "Extract the salient points from the following:" might help?
We also have a ton of projects on our GitHub, including the web framework we developed for our API that I’m alluding to above. Of course, that’s not the core product, but you can see what we’ve got going on.
>At Oxide, we do "web API layer" stuff in Rust. We also don't require that candidates be Rust experts, though obviously experience helps. Many of those people who are "proficient in C#, JS, Java, Go, Python and the like" can absolutely write Rust, even if there is some slowness at first.
Many of developers who are skilled in X can learn Y. But that doesn't mean you should hire X developers and ask the to do Y.
The process should be easy. Identify the tool which is most fitted for the project. Hire developers proficient in that tool.
Not sure if rust is significantly harder to learn than Go, but as a Java dev I was able to pickup go and make contributions in around a week or so. Yeah I was slower, but we had some really good Go devs who had all of the tooling and packages laid out with best practices. This made it easy for new devs to jump into it.
I think the issue happens when you have a new rust/go/javascript/etc. dev trying to setup a project for the first time.
Yes Rust is significantly harder than go. It's diametrically opposite if there was a circle of complexity.
I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust.
The ownership model makes sense to me but if I had to grok manual memory management and rust abstractions on top of it at the same time I think I would be unable to contribute even trivial stuff for a month.
Oh and coming from a dynamic language background at that ?
Not saying can't be done just saying time till contributing is probably weeks-months.
> I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust.
In my personal experience you do this by writing your programs in such a way as not to require complex ownership. I had an easy time writing web services where the only cross-request shared state was a database handle. I had a hard time when I had to write a websocket document sync serverwhere I needed per-document global state shared between all the handlers, and I eventually gave up and moved to a model where a language with an easier concurrency story called rust code.
This. Implementing an http endpoint is pretty straightforward. Newcomers may struggle with copy vs reference semantics (and that just takes time), but otherwise it's not too different from other statically typed http work. You define your input/output structs, you grab a database connection, you perform a query, and return it. No lifetimes. No Arcs or Mutexes or Rc or RefCell.
We generally consider our rust backend as two parts: application code and library code. We intend for our application code to be approachable by full stack developers and not require deep rust expertise to use. Our library code can be a bit more complicated, and there we see a bigger ramp up and frankly some self selection among our team and that's fine.
Curious what modern schools teach in Computer Science programs. I went to Salisbury State University 17 years ago, and we had classes on assembly language, system programming and operating systems where we used C, algorithms classes with assignments in C++, computer graphics, which of course also C++.
My professional experience working in industry was primarily in Java, but also some C, Python, Ruby. Learning Rust was not without a challenge, but having a lot of programming in C/C++ in school more than 10 years ago helped a lot. My assumption that all software engineers who have university degree should have some experience in system programming.
At my university the language used for teaching was predominantly Java, with Python or C# used in some papers.
There was an optional operating systems paper which had you writing some assembly to run on an in-house RISC system [1], but a small % of CS+SE students took that paper.
I think they’re trending towards using Python for most papers now. Not unreasonable for a paper on data mining or web development, but there’s definitely something being lost where students don’t /need/ to understand how the computer’s working in order to get a passing grade, so there’s no real incentive to dig deeper for the average student.
The University I work for teaches Java in Programming I (the mandatory introductory language) for Computer Scientists, and teaches them some C in Programming II and then a functional language, typically Haskell, and potentially some Rust, Typescript, whatever by the third year as some of the students will be pursuing Theory. The Electronics students learn C at the beginning meanwhile. Students elsewhere in the university learn mostly Python and R.
> I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust.
I started by reading the Rust Book. It explains most of the low-level concepts. It took me about a week of mostly just learning and experimenting, and another ~3 weeks until I had an MVP of my system. But from there it was just another 2 months until I had a full system written and in production, which it would probably have taken in another language anyway (as the project involved a lot of trial and error reversing a (simple but) only partially documented format).
Perhaps it helps that I came from JavaScript where a lot of the abstractions are similar.
>I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust.
Far easier than the way anyone without low level experience (which meant almost everybody starting out) approached learning C and C+, back when Java, C#, Python, Perl etc were not yet a thing, and you got either got directly into C/C++ or started with PASCAL and BASIC if you were lucky. Oh, and no IDES, internet, stack overflow, or forums either...
Go is garbage collected. It is significantly easier to write than Rust --- it's not just easier to learn, but easier for experts to write, because it's doing a bunch of work for the developer that Rust doesn't.
On the other hand, if you need manual memory management (for performance reasons, or because you're doing something bare-metal), you'll be fighting Go's garbage collector, and Rust has conveniences for manual memory management that Go doesn't.
Go is quite arguably a worse language though, including certain fundamental cornerstones of modern web development. Ever tried to see what fields a JSON payload contains in an "idiomatic" way before casting it to a type in Go? It's all interface{} (now Any) and reflection. If we're talking about developers new to a language, I'd argue that Rust's type system is easier to grok than the cases you may need to account for in Go.
I'm not interested in the language war. It's just the case that Rust is both more difficult to learn --- especially if you've never worked in an unmanaged runtime before --- and more difficult to write. Which language is "better" is undecidable.
I'm sure this is true for some people, but I found in Go their "Don't Be Clever" just drove me nuts. There's a thin layer where it's fine, and then once you get beyond that your options are Be Clever (Nope, Go tells you not to even try) or Give Up, I gave up.
Whereas in Rust I was able to keep going. Sometimes, when I dug down I reached something truly enlightening like the implementation of core::mem::drop -- pub fn drop<T>(_x: T) { }
[ Yes I said implementation, that's not a typo, that's the actual implementation. ]
Sometimes, it's all fucking turtles, e.g. Aria's famous "Pre-pooping your pants" essay and her "Tower of Weakenings". There's bad news, but if you don't like that we also have more and different bad news.
And sometimes it was a voyage of discovery, but it was an interesting voyage, I learned much and I felt invigorated and encouraged. For example why C++ std::vector's reserve is not Rust's Vec::reserve but Vec::reserve_exact or why Rust's functions each have unique unnameable types, or how MaybeUninit actually works.
I have no trouble believing that there are programmers who enjoy writing Rust more than they enjoy Go, and many of those programmers are probably faster when they're not being irritated by the language they're working in. But I simply don't buy arguments that Rust is easier to pick up, or even as easy. Go is a garbage collected, managed runtime. Rust is in some ways harder to write than C++.
The very last thing I'm here to do is to advocate for Go over Rust, or vice versa. But there are some basic facts about the languages we should be able to recognize, without falling into a bottomless pit of language war. Rust is more complicated than Go, and it's that way for a reason: you can readily use Rust in problem domains that don't admit Go.
It does feel like it ought to be true - like you said, there's a garbage collector, surely it'd be easier?
But alas, Go's quest to avoid being clever often means that when the simplest thing would be too clever that must be avoided. If you are implementing Go this is presumably a great convenience, but I'm not implementing Go, I was just trying to write software.
Rust and Go agree that 1 == 1 and 5.26 == 5.26 and "New York" == "New York", but then Go wimps out. Rust has no problem if we should like to use this equality operator on arrays of integers, or slices of booleans, or for that matter HashMaps of HashSets of Vecs of Strings, but that's all too Clever for Go, so in Go we must use extra functions like reflect.DeepEqual.
Rust and Go both agree there's fundamentally only one loop. But, they disagree on what that fundamental loop is. Rust's fundamental loop is named "loop". It just loops, forever, it's a loop. Go's idea of a fundamental loop is a variation on C's for loop it uh, well it has two statements, plus a boolean expression, the expression is tested before each iteration and the first statement happens once, but the other statement happens after each subsequent iteration. That... doesn't seem simpler. I'm not sure what their excuse was here, is an infinite loop too Clever ?
There are a few more like this. Unsafe Rust is definitely way more complicated, but one of the less obvious benefits of that keyword is that it tells beginners what they don't need to know about. Ah, this is marked unsafe, I'm a beginner, no need to explore that yet.
Probably you can argue that the need to teach 'lifetimes undoes all this benefit and that's still safe Rust. It's a position I don't have hard data to refute, just my personal experience, for whatever that's worth.
C++ vs. Rust is a tricky question. C++ is easier to write in, but it's harder to get programs working in it. Rust is harder to write, but it's much more likely that your first execution is going to do something useful. But they're of comparable complexity.
Second this. Rust also follows some habits of C++ like verbose syntax and accidental complexity. There was an article recently where a Rust port of a C++ application ended up being comparable in lines of code.
There's a sense in which people are saying it's easier to learn other languages than Rust because it's easier to get to code that compiles so you can start building new features.
There's a different sense that I feel is being overlooked by those people in that the problems you run into with Rust are frequently actual flaws or bugs in your code, and the compiler shouldn't be thought of an adversary blocking your way to feature development but a teacher showing you the things you're overlooking. So once you put in the upfront cost of learning how to write Rust that compiles, you get code that's much more maintainable, correct, and easy to refactor.
So for someone that likes learning languages, I'd say choosing to learn Rust is a great choice and will teach you things you can take with you to other languages.
This argument gets posted for nearly every [insert language name] that isn’t JS/Java/Python.
It’s not to hard to learn. The Rust web stack is fairly simple and easy to get going with in a few days. Good developers use many languages and enjoy using many languages. If you drop the usual requires ten years experience you have just increased your hiring pool to a bunch of people who are excited to learn so will often put in the hard work to learn.
It’s a bit disrespectful to think a new grad can’t use a language other than JS/Python and they’ll be more productive in JS/Python. How little do you think of grads?
I think highly of the new generation and would consider a good new grad about as good as me (a senior-level SWE age 26). My experience with fully learning and using Rust is that it's a constant burden for high-level work no matter how well you know it. Similarly with C++, except that is even worse.
Rust has its place for things that need to be especially optimized. It's far too pedantic for the kind of things you can do in NodeJS or Flask. New grad would be annoyed, and so would I.
I don't know a whole lot about Rust, but if the pedantism is related to syntax, wouldn't current AI-assisted programming tools be able to help with that?
I've had GPT-4 explain to me weird niches in Django that I don't understand, because I'm coming from a Javascript background. It'll pick up what I'm trying to do, give me the code I'm trying to write, and tell me where I went wrong.
In the process I learn a lot, and waste a lot less time trawling Stack Overflow and parsing other people's code and closed threads.
It's a lot like having a more experienced developer over my shoulder.
To answer your question, yes. This is also what I try to hint people at work who refuse to move past the "real programmer" languages, most of their talent is very soon replaceable by GPT.
Idk if you'd call it syntax or what, but what makes Rust pedantic is that you're always worrying about lifetimes, types, explicit errors (as opposed to exceptions), and other things you mostly don't think about in JS or Py. It's like C++ only nicer and safer. It's not that JS/Py is a lower skill, it's that devs don't want to waste time. Of course Rust or C++ makes plenty of sense for lower-level stuff or anything that needs to be especially optimized.
C++ won't be as safe as Rust unless you use it like Java, copying everywhere or overusing shared_ptr so you don't worry about lifetimes, which nobody really does.
I would argue that learning the language is the easy part even though in my experience some languages are much more difficult in practice to become effective in than others. The hard part is acquiring the expertise related to the domains where particular languages are commonly used. Knowing a language does not convey competence in the domain where they are typically used or the idioms imprinted on the use of the language by those users.
Knowing the language is necessary but not sufficient. There is an enormous amount of practice around language that is not implied by the language itself that you need to learn if you want to be effective.
> You have narrowed down your hiring pool to expert Rust developers even though all you need is a new college grad who can start a Flask server
On the plus side, if you hire someone who isn't an expert Rust developer and they mess things up, it will break at compile time instead of at runtime.
Assuming you still have some Rust developers at your workplace, and assuming the new developer is not completely incompetent, they should be able to get up to speed before too long.
If Rust was C++ what you're saying makes a lot of sense, but it isn't.
Safe Rust is not something that's going to be a problem for a good developer. If they've actually understood what they were doing in C# or Go, for example they'll be fine. It's another semi-colon language, they can be spun up on this language with the Book, or a day's Pluralsight or whatever makes sense.
Yes, Rust makes more sense if that C# programmer also dabbled in F# or maybe the Go programmer took a semester of an ML in college ten years ago, because hey, this semi-colon language is sometimes an ML in a trench coat, but that's not crucial to being productive.
If your software ends up with non-trivial amounts of Unsafe Rust then yes, you will need somebody who knows what the fuck they're doing. But that'd be true if you needed unsafe C# (yes, that's a thing) and again, there's a lot less experience with unsafe C# on the market just like for Rust. And if you've got a problem for which Unsafe Rust was appropriate you'd need all the help you could get in these other languages.
Why can’t candidates learn rust? I’ve never hired people based on specific language skill set. Any skilled developer should be able to learn any language.
Being able to learn X doesn't imply they must learn X. Maybe they don't like X and its way of doing things, which is a perfectly valid reason not to. They can be using Y and enjoy what they are doing.
For sure, but why should I make stack decisions because random SWE doesn’t want to learn something new? If it were asking folks to learn cobol I’d get it. But “learn modern language X with a bunch of experts” should attract the folks who are, IMO, exactly who I want to hire. They’re not afraid to explore and learn, they bring adjacent skills, and they’re eager to keep a simple stack.
> You have narrowed down your hiring pool to expert Rust developers
I don't think that's really that big of a deal. Any above-average developer should be able to become useful in a new language in a pretty short period of time. They don't have to know the language on day 1, they only have to know how to develop software.
In practice we already have our hands full learning the domain unless it's a completely greenfield project. Working out the language and its frameworks makes it exponentially harder when coming into a project.
> If you have a team of system developers fully proficient in Rust, and the next task is to build some middleware web API
If your next task is to write a web api the sensible thing to do is to assign that task to a team of backend developers. Conversely, you generally don't ask web developers to do system programming.
> I really like using Diesel because it generates all your SQL queries for you, from a typed SQL schema that it generates from your SQL migrations.
Fair that the author says that this is their opinion, however... I can't agree.
Maybe I'm too stupid, but for me SQLx is the real killer crate when it comes to databases.
Everything, from the migrate macro, to the way it validates at compile-time the types in the DB, feels (to me) very ergonomic.
Diesel, by contrast, I spent so long trying to set up and I never really understood the three different files that need to somehow be in sync and generated. I just never really grokked the split of these files and when to run the diesel-cli commands...
but SQLx is great, I often lament that there isn't anything comparable in Golang.
We originally used SQLx but eventually moved away for a couple of reasons:
* The sqlx::query! macro is a neat hack, but the fact that it calls out to a database in a proc macro is pretty insane. It significantly slows down compilation with a lot of queries, and doesn't work reliably with rust-analyzer.
* Inconsistent handling of nullability that would regularly break compilation
We now use Cornucopia (https://cornucopia-rs.netlify.app/) which I think is a much better approach. You write your queries in a separate SQL file, alongside annotations that let you specify nullability. A standard build.rs integration performs codegen from that, which means compilation itself doesn't require a DB and IDE features work well. It also lets you share data types between queries which reduces boilerplate significantly.
Compile time verification that you haven't made a typo in your SQL, and that if you have updated your db schema that your code also reflects these changes.
Turning runtime errors in to compile time errors is one of Rust's superpowers.
It's not running the queries, just sanity checking them against table structures/etc. It's actually quite nice and worth checking out.
The real issue is that in performance benchmarks Diesel beats SQLx, at least last I checked. I'm hopeful the rewrite/upgrades to SQLx that are coming shorten this gap.
Doesn't it need to run introspection queries to check the table structures? This is still a significant overhead compared to code-only compilation, and it also requires an additional component (the database) in your build stack, which also needs to have a schema in sync with other developers and whatever deployment target to which you intend to push the compiled program. That also means that if you're building with a local copy of the DB, and deploying to a remote with its own DB, you have another source of risk for disparity between compile and runtime (I assume such an error would be caught quickly, so maybe it's not so much about additional "risk" as it is increased operational complexity).
The .sql files or migrations or whatever else in your repo represents an intent, or contract, defined by your application. But those files aren't the source of truth, the database is the authority. Whether a SQL query is or is not valid is, by definition, something that can only be evaluated at runtime.
Yes, with sqlx, the migrations must be the source of truth for your DB schema. You cannot (ideally), manage them elsewhere. This is why the sqlx migration tool is so good, you kinda have to use it.
It's honestly very nice. The code, my migrations, my DB browser, all in one window in my IDE.
And the query is validated by running it, at compile time, by inserting mock inputs inside a transaction. It works really well.
Even if you disagree that the DB must be the source of authority and it can differ, the development boon of the process is worth the 5% chance there is some issue later, which can probably be easily resolved.
I don't really get your point. Yes, the db validates the requests. But that's based off the schema. The schema is determined from the migrations. You run the new migrations before any deploy.
You can keep pushing this argument but it doesn't mean anything in any practical sense.
my point is basically this: when the code in your application interacts with the DB, and it encounters a (runtime) error from a mismatch between the app's understanding of the DB schema and the DB's understanding of the DB schema, is that error handled gracefully? if yes, good! if no, because the app code assumes this is somehow impossible, that's a problem. that's all.
Yes, that’s exactly the issue. You trade that friction for not having the friction of type errors in queries at runtime. Whether that tradeoff is a good one depends on your situation and preferences.
(You can also check in the results of the database queries, so you only need the db in the build stack when you touch db-related code).
Regarding your second bullet point, can you elaborate more? I haven't seen this. You have to explicitly use Option<> for non null columns but that's what I expect.
Maybe I'm holding it wrong, but my experience with sqlx is a bit more lukewarm. It's really great that compilation success means that you didn't fuck up any queries, but... there's just SO much boilerplate. I find that due to Rust's extremely strict type system, I have to create dedicated record structs for all of my domain models representing how a model is stored in the database. So once everything's up and running it almost always implies there's essentially no bugs, but man is getting there a drag.
Also, testing is quite annoying too. If you're using sqlite, you can use in-memory mode and that's quite nice. But for other databases you basically have only two options: 1. setup and teardown an actual testing db 2. wrap your sqlx interfacing code in something vaguely resembling the repository pattern and create an in-memory implementation for testing. I'd call both of these options less than ideal.
The question is what's the cost of a bug? Lost hours for customer support to collect user reports (which take some time and usually multiple reports before being believed), time spend by CSRs to individually, time by the dev or ops team to fix the affected accounts en-masse, more time by the CSRs to manually fix up affected accounts and give them individual credits where credits are due (which may be manual and thus error-prone process), and finally time spent by the dev team to identify and fix the bug for future users, which is time spent not adding new features or paying down other tech-debt. That's not to say using scripting languages isn't necessarily worth it for increased speed of development, but the time spent above may be impossible to quantify in aggregate. If you're in a low stakes environment, where a bug costs you single digit basis points/bips, not a problem. If you're somewhere like crypto where a bug that an attacker discovered ends up costing the exchange, your employer, 9-figures, or worse, the medical or aerospace industry where bug(s) literally costs people's lives, then avoiding bugs is of paramount importance.
The other option is avoid such a high stakes environment, but someones got to be in those fields.
> But for other databases you basically have only two options: 1. setup and teardown an actual testing db 2. wrap your sqlx interfacing code in something vaguely resembling the repository pattern and create an in-memory implementation for testing. I'd call both of these options less than ideal.
Why not just BEGIN a transaction and then ROLLBACK it after every test case? That's what every other significant backend codebase (using SQL) that I've worked on does. Maybe that's what you meant by #1? Not sure why you'd want to avoid it then—it will help significantly in testing out any piece of code you have that's even slightly outside of the CRUD norms. What does Diesel do, reimplement a completely separate "testing" version for all of its SQL queries?
Just using a transaction that will be rolled back after each test case is exactly what diesel suggests. There is a separate function for this on diesels connection trait[1]
The database schema is owned by the database, the types in your program are owned by your program, these two things change over time independent of each other, mapping from schema to type is an inherently fallible operation, success can only be determined at runtime, type checking SQL queries against .sql definitions at compile time can be a sort of optimization but doesn't provide any kind of runtime guarantee, and you gotta handle syscall errors gracefully anyway if you want your program to be anything close to reliable, so it's all a bit moot I guess
Hello, author here. My coworker Olivia (of https://losslessbits.com/) really likes SQLx, I haven't personally used it though. I'd love to try it for a future project, as long as it can help typecheck my SQL queries.
Personally, what I'm looking for from an ORM is composability and type safety. To my knowledge, it's impossible with sqlx, for e.g., to conditionally add a WHERE clause, and have compile time checked queries. With diesel, it is possible.
I 100% agree with your point about Diesel's dev experience leaving a lot to be desired when it comes to docs and ease-of-learning though. But to me, that is a straightforward problem to solve when compared to the fundamental limitation of sqlx that I described above.
Thank you weiznich! Tbh, it's really hard to come up with concrete proposals to solve these problems, and I still haven't figured out how much of the "not-super-easy-to-learn" issue with Diesel is inherent complexity that can't be avoided if one wants to have runtime-constructed-and-yet-compile-time-checked db queries in Rust.
I think it will require some thought. I hope that, once I get around to using diesel in a second substantial project (already using it for my first), I will write up my thoughts on how to make DX better for diesel.
Agree, for our approach, sqlx has the right level of abstraction. Not too high, not too low, and close enough of a sql builder pattern to be very useful. (We are not using the compile time type validation though).
Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker.
Basically, Rust fulfills the dream of a functional language with pragmatic semantics, syntax, and developer experience. That's why I write it.
This I buy. I’ve never quite gotten why the rust crowd thinks manual memory management and zero cost abstractions are the only bullet points that matter. Many of us would happily switch to a language that didn’t have either, if it made our day to day work not feel like rocket science and the sharp edge of the “never write code as cleverly as you can, because you won’t be able to debug it” adage.
> why the rust crowd thinks manual memory management and zero cost abstractions are the only bullet points that matter.
I don't think that's an accurate characterization of "the Rust crowd," but even if we do take it at face value, it would make sense: Rust was intended for the layer of the stack where these things do matter. Even though Rust has broken out of that initial layer, as the post demonstrates, culturally these things are likely to hold a bit more value than they may otherwise.
Well, because as others have pointed out, languages like that have existed for at least a couple decades. Most of the 'nice parts' of Rust are really borrowings from the ML family of languages: Hindley-Milner type inference, algebraic data types, and pattern matching.
OCaml or StandardML, (or Haskell if you want to get funky ... I don't), F#, Scala, etc.
Hell, these days even Swift, or Kotlin, have these features. Which I'd call: modern static type systems.
And I understand even Java is getting some of them. Even TypeScript is a reasonable-ish solution with a pretty nifty type system, if you don't mind the (non-existent) threading model.
I like Rust, but its niche is: the above nice things and a clean syntax, but without the latency&pause costs of GC.
And that's what I use it for, when I need that kind of thing, for systems programming. And for that, the killer feature is the borrow checker which makes using the above features relatively painless, despite having no GC.
(Now one other advantage of the borrow checker is its application to concurrency -- making ownership of locks, and mutable state generally, easier to reason about. That's perhaps a killer feature that the other languages I mentioned don't really have)
Memory management/performance are just among the most obvious points of comparison when looking at Rust versus other languages. Ergonomics come up too, though less often, and with less agreement on how good they are, since it's a pretty subjective judgement on a mixed bag of features and syntax.
It's often a good idea to focus on a narrower range of use cases when evaluating the tradeoffs involved in designing a system. In the case of Rust, it's designed for writing systems software in performance critical code paths where these bullet points matter.
Guarantees about those things are impossible to add after a language/community abandons them, and you can Arc::<RWLock<T>> your way to writing Java pretty fast. I hold that keeping the strongest-possible abstractions is the best decision, even if that means your average developer needs to learn borrow checking. I've started a career writing Java, spent a year with Rust, and when I came back to Java my data structures were 5x as useful. I could spit out features _WITHOUT_NULLPOINTER_ISSUES_ in hours where previously it would have taken a week.
Yes there is a skill gradient, but everyone who doesn't climb that hill is a fool and a weaker team member for it in my opinion.
The borrow checker is Rust's unique selling point, if you don't care much about it, there are many alternatives that do the things Rust does but better. (Well and the error messages: other than Elm there are really no other languages with such excellent messages as Rust has.)
You might want to explore the space of statically typed functional programming languages a bit more. OCaml and F# are both very pragmatic functional programming language that will give you everything you want and even more.
I would emphatically disagree here. The ergonomics of Rust blow any functional language out of the water. The combination of cargo, rust-analyzer, and rustfmt is far better than anything OCaml can offer. Likewise, the choice of modules instead of traits, while probably a "better" design from a language design aesthetic perspective (more compositional, less global), make simple things like printing or checking equality rather difficult. And that's not even getting into compiler errors, package ecosystem, or documentation.
And really, you can see the priorities in how the people driving the language talk about it. In Rust there's a focus on ergonomics. How can we make this easier to use? How can we make the tooling nicer? In OCaml and other languages the focus is almost always on semantics. We have unboxed types like Rust. We have multicore with green threads. We have effects. This is missing the point. I don't care about the features of the language if the language itself is annoying to use. It's like wondering why Slack or Discord won versus IRC. Ergonomics is the answer.
Interesting you came to that conclusion. I liked Rust when I tried it, but it is definitely less productive and ergonomic than F#. Of course the memory overhead in Rust is much more predictable and generally lower, which might be an important factor for you.
> In Rust there's a focus on ergonomics. How can we make this easier to use? How can we make the tooling nicer?
rustc’s error messages are _unbelievably_ nice. It’s shocking how much better they are, even compared to other modern languages. Error messages aren’t an arcane invocation that needs to be deciphered—they almost always explain exactly what went wrong, with suggestions for how to fix the issue.
I wish other languages had the same focus on DX that Rust does…
F# is pretty close to "GC'd Rust with Python-esque indenting". In my head it feels like "Rust-lite".
I ported a program from C#, to F#, and then to Rust. The F# -> Rust conversion was a lot of "add curly braces and parentheses" and "replace |> with ." It's almost kind of ridiculous how similar the code can be. I've been going back and forth between F# and Rust on hobby work and it's very, very easy to do.
You get the equivalent of many crates of cross-platform stuff straight out of .NET Core: e.g serialize to/from JSON, network requests, tasking/async, etc. Either VS or Rider is great, the debugger also works out of the box. I also skip Python/Powershell/Bash and write any extra scripts I need in F# and run then with ``dotnet fsi``. This "Keep all the things in the same language" is very attractive to me. Using F# over Python for scripting is very enticing to me -- good implicit typing, enums, ``match``, etc. I'm not sure why this hasn't been pushed before.
The docs are great and most things "just work", but I've been trying to hold back my enthusiasm because I just haven't been able to find folks using it, and http://forums.fsharp.org seems empty. It is fun to write though :)
I agree. There's a lot of sibling comments to mine saying "You're thinking of F#" or Ocaml or whatever, and from a purely semantic point I agree with them.
The problem is, where the hell is the enthusiasm for those languages in a similar direction as rust?
The only reason I don't use those languages is because people are overwhelmingly more enthusiastic about rust, which has the majority of features I want. This in turn makes rust have a better developer experience as more people use and contribute to that experience
> Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker.
Basically, Rust fulfills the dream of a functional language with pragmatic semantics, syntax, and developer experience. That's why I write it.
>Yeah what a lot of people don't understand is that if there was a garbage collected version of Rust that kept the same guarantees around mutable data, with the same good type system, good ecosystem, and good tooling, I'd still write a lot of it. Those benefits are way more important to me than the borrow checker.
If garbage collection helps, you no longer have ownership, because a single place where a value is dropped obviates the need for GC. If you no longer have ownership, you no longer have use-site mutability, because no single place controls the mutability anymore. If you no longer have use-site mutability, you no longer have the good type system. The borrow checker is what makes it work.
I wish this was less of a contentious conversation. Liking a piece of technology and being able to derive maximal value from it is like 90% of the battle. If your team dislikes a tool, they'll use it suboptimally. All of the song and dance around why some language or framework is better than all the others is usually irrelevant - a team that hates Rust but tries to use it will derive less value from their tooling than a team that loves PHP. It's not rocket science, and preference isn't a bad thing.
A lot of these bullet points apply equally well in Haskell. Automatically derived JSON serialization from records, typed (and compose-able) SQL queries, whole-program feedback from the compiler; etc.
Especially the all-important advice: use Haskell when everyone on your team uses and wants to learn Haskell! Can't stress that enough. From experience, even when a language has all of the technical features to merit consideration for a project, what your developers are already familiar with will trump them all.
I wish it were a purely technical decision what language to use for a project but it's not. "Use the right tool for the job," is not the right advice for choosing a language. It's a social/network-effects type of decision.
Haskell doesn't have the documentation / doctest / code examples culture of Rust, cargo is arguably a better experience than any of the Haskell package management options (at least last time I checked) and I don't believe rust-analyzer is matched by anything in Haskell as a language server.
1000% this. Having worked in Haskell and having learned rust the past couple years. I love Haskell, but Rust really married a ton of the good parts of Haskell with a lot of "soft skill" elements that allowed it to graduate beyond being mostly a research language. It matters that in Rust I don't need to go read some blog posts about type theory if I want to make an API endpoint. It's not even that Haskell the language requires that, Haskell the culture requires that because there aren't (or at least weren't a few years ago) that many people promoting practical Haskell.
I haven't written more than a few pet projects in Haskell, but in my experience haskell-language-server is quite fantastic. I agree though that cargo has been a better experience for me, and while the documentation for Haskell is better than I would have expected, it certainly doesn't match up to rust.
Yes. About 2/3rds of the points rely on underlying language features of algebraic data types, type driven metaprogramming, and linear / affine types. Haskell has all of those, although linear types are still experimental. Scala has all of them apart from linear types (which have been explored at various times but are not officially part of the language.)
Haskell is cute until somebody in the team starts using the most advanced parts in some common task, destroying team's ability to understand what's going on and make changes; in a few years the author of such code will have the same problem (one's brain won't keep PhD-level capabilities the whole life). The same issue hit Scala development and led to complete rewrites back to Java or similar.
I would love to use Haskell. The main reason I stopped writing Haskell and started writing Rust was that I could more easily teach new programmers Rust due to better compiler error messages, and Cargo is 10000x easier to use than the Haskell package managers, which never seem to be able to resolve the right set of versions for me.
Being able to write a lot of functional Rust and drop down to imperative/mutation when necessary also eases the curve compared to Haskell.
I've written Haskell for 10+ years and I can honestly say that there are very few areas where I would seriously consider Haskell over Rust at this point. It also seems and feels like that is the general consensus at a lot of companies, many haskell shops having moved to using mainly rust, etc.
Everything in Haskell is an academic exercise with very little to show for it in the end. The performance is not that great, and even with "fearless concurrency", most complicated performance tuning situations are entirely consumed by understanding the intricacies of GHC Haskell and how to best tune your program by letting GHC abstractions leak into your code in the appropriate places to get it to run fast. People constantly keep reinventing streaming libraries because there are always problems or compromises, etc etc.
I really used to be on the haskell bandwagon for many years, but these days, when I reach for it, I end up really wondering why. Even the dev tooling is still bad, slow and buggy.
Social/network-effecst are critical part of the rigth tool, I read a blog about a companies who regret using rust becouse was impossible gey people whit experience in rust like the founders.
I have seen this perspective thrown around quite a bit. I see where they are coming from, but I can't empathize with it.
Rust's ecosystem does an admirable job in making it less painful to use, but I am still waiting for the day when just chuck any type into Gc<T>. Rc<T> or Arc<T> is not an alternative here. A garbage collector seriously makes business logic way easier to write. And none of rust's other advantages can offset this for Web development.
I know there have been attempts at general purpose garbage collectors for rust but as far as I've seen none of them seem to work seamlessly. Some justifications I've read about it go along the lines of LLVM not having native support for stackmaps?
And given how you have unmanaged native pointers lying around everywhere, I don't know if you could even have a general purpose GC without putting heavy restrictions on code that uses it effectively creating a split dialect.
I'm not sure why this is being downvoted. Are people disagreeing that manual memory management adds overhead compared to GC'd languages for prototyping?
I'm expecting my own comment to be downvoted as well, so I'll give a huge disclaimer that I lack experience with Rust, but I always find myself playing type tetris and having to think hard about memory management whereas Clojure, JavaScript, and Python all have interactive solutions that let one quickly hack together some web server and endpoints.
"Type Tetris" is the perfect description of what I've felt with rust at times for stuff where I don't care too much about performance but don't want to wrap everything with Arc<Mutex<T>> or .clone() everything.
I don't say this from a perspective of distaste. I really like rust's ecosystem and tooling, but would really love to use `RustScript` one day which is basically Rust with a hint of Go. Green threads and all references can be treated as if they are effectively pointing into the heap.
I find it hilarious when the industry that made Node a thing is suddenly very sensitive about using languages in other places than their original niche.
I would have been interested if the author had expanded on how they planned to use the borrow checker to avoid multiple listeners using the same IP address. I haven’t used rust much outside of some self learning but in other language I’d simply mutex/lock, how can the borrow checker at compile time validate that each listener cannot get the same value of a hash set?
- use `&mut` references to allow the borrow checker to statically enforce only one reference to the IP exists at a time (the major unique feature of Rust is the borrow checker which basically only allows one mutable reference at a time
- use an `UncloneableIp` new type that doesn't implement `Clone` to prevent the IP from being copied
I might be dense, but I still don’t get how it works: I put the 10 addresses in a HashSet, and I have some function that I want to be able to exclusively use one of them, how do I write the constraints to make the borrow checker be able to enforce this at compile time?
I understand the two statements above in the article, just not how they can be made to work in this case. Apologies again if this is an obvious question, as I was saying I am definitely just starting out in rust.
Hopefully that gets the gist of how you might approach it. I'm not sure I'd use the HashSet myself, to be completely honest, because it makes it needlessly complicated to get an element out of it. I'd probably just use a Vec.
Thanks for writing some code! I will try to spend some time to grok it: so is the idea basically that you are guaranteed there is only ever one copy of these unique IPs and there is absolutely no way for any more than one function to hold one? I have to say maybe HashSet was throwing me for a loop and if the important bit is having an object that can not be copied, then it shouldn’t matter what data structure you keep them in does it…
I don’t find a strong case for using Rust just to guarantee each thread gets its own IP (a mutex protected getter seems like it would do just fine for just that) but I guess it would guarantee that as long as you use this “uncopiable” object you could not, even if you wanted to, have two identical IPs in your program if I understand things correctly, which if your mutex getter had a bug would not protect you against.
The Mutex/RwLock would be a runtime guarantee, while with this, you can make it a compile-time guarantee.
I think that mutex are actually a really good example of what he's talking about in the article. You can only access the data from a Rust mutex through a `MutexGuard` returned from the lock method. `MutexGuard` is uncloneable and therefore, when it is dropped at the end of its scope, the mutex knows that it is free and can automatically unlock it. Additionally, it is impossible to access the data without having the `MutexGuard`, so you can statically determine at compile time that all data access is behind a lock.
The HashSet would be the owner of the IP address type. Your function would call the "take" method of the HashSet to take ownership of the IP address. Now the IP address cannot go back into the HashSet unless you give ownership back and no other thread/caller can take ownership.
> Building a model of the SQL type system within the Rust type system is very impressive work. It also leads to really annoying problems, because the Diesel types are so complex.
Oh man have I felt this pain, trying to do anything mildly complex with Diesel's types is so ridiculously difficult. I once (foolishly) tried to write a generic repository implementation for database entities which could either have sqlite or postgres as a backend. I thought this would be very convenient for testing, being able to just keep all of the code the same safe for using a sqlite backed repository instead of a Postgres one.
I gave up after about ~10 hours of battling incomprehensible error messages.
Diesel maintainer here. So first of all we are aware of the sometimes bad error message and we are working on solutions. There is already an unstable feature flag that improves some error messages and the next diesel release will include additional tools to improve the error messages in additional cases. In addition we try to change the language to give us more tools to control certain error messages emitted by the compiler, because mostly the error is large, but has a well known underlying issue that can be described much shorter.
> I once (foolishly) tried to write a generic repository implementation for database entities which could either have sqlite or postgres as a backend. I thought this would be very convenient for testing, being able to just keep all of the code the same safe for using a sqlite backed repository instead of a Postgres one.
It's generally not advice to test against different databases than you run in production. This is one of the reasons why these kind of things are not simple in diesel. Prefer running the tests against the "real" database system and use `Connection::begin_test_transaction()` to prevent polluting the database with test data.
More generally speaking: Writing generic code involving diesel is likely an advanced topic, so don't expect it to work quickly. I usually advice people to not write this generic code, at least not if they just want to use diesel in their applications.
I've given up on trying to wrap SQL in any way. Too many bad experiences. I just use it as-is with fully dynamic types. My go-to stack is Postgres + NodeJS, no Typescript. No query builders, no ORMs especially. Postgres is meant to be used on its own with a minimal client lib. It works beautifully.
And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests. I get to do full TDD often. And the bugs I catch are never due to mishandled types.
> And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests.
I'm a type-safety kind of guy, but this argument (that time spent "fighting" the type system) is better spent writing tests when it comes to DB queries, has me very very curious. Would love others' opinions/experience on this!
Small clarification, the tests aren't on the DB queries alone. It's a full flow on a test backend, like it calls /editProfile to name a user "Bob" then calls /getProfile, and it expects the response to have `name: "Bob"`. It'll probably fail if I mess up a type and get "undefined," but it's also testing much more than that.
Ah, in that case, I'm much less interested :D , because that would mean that you let the untypedness of the DB queries propagate through pretty much the entire codebase.
I heartily agree with the conclusion. It's not worth learning Rust to write your REST API (with the possible exception of code that needs to be very reliably fast, like starting a new HFT firm from scratch). But if you already know it the strengths balance out the weaknesses.
What's everyone using when it comes to data validation these days? Maintenance for one of the most popular crates for this seems to have slowed[1] and options for JSON Schema validators still seem immature[2] (but the ones I've tried work well so far).
The author's sale pitch for Rust is team already knowing Rust.
This is akin to a construction company saying: "We already have some carpenters, let them do the bricklaying and use their hammers while at that."
What happened to the right tool for the job?
I see Rust as a specialized language, fit for specific problems. If you need performance, need low level access to the hardware and also need the kind of safety guarantees Rust provides, then is the right tool for the job.
Using Rust for backends can be as good an endeavor as using Go for writing device drivers.
It really sucks when you are the only one on your team that knows Rust. I whole-heartedly think that I'd be more productive and write better backend code in Rust than JavaScript/TypeScript/Python/Ruby from my experiences of using Rust in side-projects. But I have to suffer because I cannot make the case of rewriting our backend and teaching all the devs Rust.
So my only choice if I want to use Rust is to leave the company, but it's really hard to find other companies that primarily use Rust. The majority of the ones that do are crypto/blockchain related or doing something extremely low-level or out of my wheelhouse since they assume you're also comfortable with writing C++. I'm primarily a web developer and I hardly see any web startups choosing Rust.
We need to do that movie thing where two people switch places and pretend to be each other, that way we swap jobs. Cause where I work, we write web backends in C++ purely because people there want to use a "real language." Not only do I hate it, but they have a hard time hiring people cause all those kinds of candidates want to do lower-level stuff.
The speed of rust out of the box is insane. I sped up one python endpoint by a factor of 100x with Rust (not 100%, 10,000%). If you can get 1 endpoint that is causing performance issues to be written in Rust, it may be the skinny end of the wedge. You obviously shouldn't sneak that in, but if you get buy-in, then it may start the process.
Go is definitely easier and more productive when you're operating in the happy path of web development with simple requirements and little tricky business logic. I wrote two extremely similar web services, one in Go and the other in Rust, and the productivity difference was night and day (granted, with some of that being experience).
The problem is when you start to have to dealing with edge cases or want to express complex invariants statically. Fasterthanlime's articles, though IMO a bit excessively long-winded, are some of the best, most damning critique of Go's refusal to support correctness-by-design in a disappointing number of areas.
The learning curve is much steeper, but if you learn it and truly understand what the compiler is trying to stop you from doing, you'll begin to see all the possible side-effects in other languages.
I recently revisited a Go project that does a bunch of async tasks right after doing a somewhat involved Rust project, and all I could see were foot guns everywhere, even though most of it was considered the idiomatic approach.
I'm comfortable writing simple applications in Rust, but I've never been a bleeding edge guy. I don't want to be an early adopter or get caught in dealing with gotchas.
What's the most mature web framework and how does that compare to working with basic Servlets sans Spring?
I would choose [axum](https://docs.rs/axum) as my default Rust server framework. It compiles quickly, it's very ergonomic, and it integrates well into the rest of the ecosystem.
Never wrote a Java web server sorry cannot compare.
This works until you have to integrate with third party solution to exchange data, then you end up needing to "externalize" the data, and why not from there start with protobuf/flatbuffers/capnproto/etc. For each of these one can rewrite a more optimal (perf sensitive) writer, but missing some functionality (e.g. append/write only protobuf with zero overhead).
Granted, for their task this was over complication, but if they were doing ads (or something similar) it always needs ways to structure your data, and then you end up needing something hierarchical, typed, extensible with backward and forward compatibility (e.g. in protobuf for example, never reuse already used index field, etc.)
We have been building relatively big enterprise cloud applications with a high level of compliance over the last decade and a half, and our next blueprint is all Rust on the backend (web server, web services, and job/micro services). For our approach, Rust is a transformative language for those parts of our systems.
