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…
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?
>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.
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 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.
> 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.
> 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.
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?
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.
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.
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.
Readit News
You have to be willing to believe that and consider it when hiring, of course, which some organizations may reasonably not be willing to.
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…
Geniunely curious since the company was found 3+ years ago (2019).
https://oxide.computer/blog/introducing-the-oxide-computer-c...
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.
I think the issue happens when you have a new rust/go/javascript/etc. dev trying to setup a project for the first time.
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?
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.
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.
Deleted Comment
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.
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.
Than maybe it's easier to just use C or C++.
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.
Deleted Comment
- The API is likely to be simple (JSON in and out, or something similar). Those devs already know they domain well.
- The Rust compiler enforces only valid programs, so you won’t get runtime errors for things you would in dynamic languages.
- This leaves just getting the logic right, which the developers know how to do in general, and Rust is a c-like language so it’s familiar.
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.
Deleted Comment
Deleted Comment
Dead Comment
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.
* 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.
wait... proc macros are run at compile time, right? so db queries at compile time?!
but.. but.. why?
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.
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 other option is avoid such a high stakes environment, but someones got to be in those fields.
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?
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.
[1] https://github.com/diesel-rs/diesel/discussions
https://github.com/kyleconroy/sqlc
https://github.com/jackc/pgx
Basically, Rust fulfills the dream of a functional language with pragmatic semantics, syntax, and developer experience. That's why I write it.
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.
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)
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.
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.
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.
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 :)
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
You might want to take a look at F#.
https://fsharpforfunandprofit.com/
This choice is almost always more about the team than the technology, regardless of the specific language or framework or widget.
And in the current economy of random mass layoffs, any morale boosters you can find will matter more.
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.
Being able to write a lot of functional Rust and drop down to imperative/mutation when necessary also eases the curve compared to Haskell.
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.
> 95% of the unwraps in our codebase are in unit tests.
There's a crate for that: https://crates.io/crates/testresult
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 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.
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.