11 ms·

Why use Rust on the back end?

168 points by steveklabnik 4y ago

paxys 4y ago
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.
- steveklabnik 4y ago
  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.
  - whitepoplar 4y ago
    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?
    - arch-ninja 4y ago
      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.
      - oneplane 4y ago
        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.
    - steveklabnik 4y ago
      > 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.
      - DangitBobby 4y ago
    - eYrKEC2 4y ago
      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.
      - DoesntMatter22 4y ago
        I was using Chat GPT to learn rust but most of the examples it generated were pretty old (mysql 4 vs now at 21).
        joshka 4y ago
        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.
        andrewstuart 4y ago
        You’re saying AI has trouble learning Rust too?
        joshka 4y ago
        Lol. Yup. Though it’s possible that it was overfitting its response to my noob questions. I’ve had better luck since.
    - joshka 4y ago
      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?
  - makestuff 4y ago
    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.
    - moonchrome 4y ago
      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. With go it's probably days.
      - iudqnolq 4y ago
        > 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.
        phamilton 4y ago
        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.
  - tiffanyh 4y ago
    Off-topic: has Oxide shipped anything yet? Geniunely curious since the company was found 3+ years ago (2019). https://oxide.computer/blog/introducing-the-oxide-computer-company https://oxide.computer/blog/introducing-the-oxide-computer-c...
    - steveklabnik 4y ago
      Server racks? Not just yet! Soon though. As we get closer, we’ve talked about it more and more, see this recent Oxide and Friends, for example: https://oxide.computer/podcasts/oxide-and-friends/1200412 https://oxide.computer/podcasts/oxide-and-friends/1200412 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.
      - dsincl12 4y ago
        Would that be dropshot you're referring to?
        steveklabnik 4y ago
        Dropshot is the framework, omicron is the control plane implementation, which uses dropshot.
    - deleted 4y ago
      [deleted]
  - evntdrvn 4y ago
    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…
    - saurik 4y ago
      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).
  - DeathArrow 4y ago
    >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.
- deleted 4y ago
  [deleted]
- gonzo41 4y ago
  This is a very good point on thinking about engineering sustainability
- nivenkos 4y ago
  Rust isn't magic, you can become reasonably proficient in a couple of weeks just as with any other language.
  - deleted 4y ago
    [deleted]
- BFLpL0QNek 4y ago
  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?
  - hot_gril 4y ago
    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.
    - AA-BA-94-2A-56 4y ago
      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.
      - hot_gril 4y ago
        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.
- JohnFen 4y ago
  > 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.
  - zeroxfe 4y ago
    That sounds reasonable in theory, but doesn't work out in practice.
    - re-thc 4y ago
      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.
    - JohnFen 4y ago
      I've seen it work in practice plenty of times. It does take a particular sort of dev, though.
  - hot_gril 4y ago
    It's not about learning the language itself, it's about learning the tooling and libs associated with it, and that takes time.
- Klonoar 4y ago
  You do not need an expert-level Rust developer for a backend web server. The hiring pool isn't really a big deal here.
  - _piif 4y ago
    Yup. It's only an issue if you insist on an immense amount of years of experience as a requirement for working on your web stack.
- fnordpiglet 4y ago
  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.
  - DeathArrow 4y ago
    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.
    - fnordpiglet 4y ago
      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.
- mrits 4y ago
  If a recent college grad can't learn rust quickly the rest of us have no hope.
- imron 4y ago
  > 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.
- tialaramex 4y ago
  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.
  - DeathArrow 4y ago
    >If your software ends up with non-trivial amounts of Unsafe Rust Than maybe it's easier to just use C or C++.
- deleted 4y ago
  [deleted]
- patientplatypus 4y ago
  [dead]
- DeathArrow 4y ago
  > 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.
- justsomeuser 4y ago
  I don’t think it is that serious of an issue: - 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.
- paulddraper 4y ago
  By the same token, if all you have is Flask engineers, and you need a Rust service, it's going to be a struggle too.
mastax 4y ago
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.
malkia 4y ago
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.)
yutijke 4y ago
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.
- koito17 4y ago
  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.
  - yutijke 4y ago
    "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.
thallada 4y ago
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.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- hot_gril 4y ago
  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.
- eYrKEC2 4y ago
  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.
notyourday 4y ago
[flagged]
- sealeck 4y ago
  I think this is a really cruel thing to say.
- goodpoint 4y ago
  [flagged]
RaiyanYahya 4y ago
I picked up Go quite fast but its quite different with Rust. The learning curve i feel is steeper.
- beckler 4y ago
  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.
- dgunay 4y ago
  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.
jeremychone 4y ago
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.
DeathArrow 4y ago
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.
wellanyway 4y ago
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.
aww_dang 4y ago
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?
- adamch 4y ago
  I would choose [axum](https://docs.rs/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.
- sn9 4y ago
  https://www.arewewebyet.org/ https://www.arewewebyet.org/
deleted 4y ago
[deleted]
paulgb 4y ago
Glad to see serde mentioned as a top-level item here. It’s a huge timesaver for anything that sends data over the network or persists it to disk.
Reitet00 4y ago
Very nice post even though they're always in this form of "here is my 10 favorite Rust features". Another one along the same lines: https://cloak.software/blog/i-built-startup-in-rust/ https://cloak.software/blog/i-built-startup-in-rust/ > 95% of the unwraps in our codebase are in unit tests. There's a crate for that: https://crates.io/crates/testresult https://crates.io/crates/testresult
dijit 4y ago
> 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.
- necubi 4y ago
  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/ 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.
  - biorach 4y ago
    > * 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. wait... proc macros are run at compile time, right? so db queries at compile time?! but.. but.. why?
    - Klonoar 4y ago
      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.
shashashasha___ 4y ago
at the end, in his usecase, everyone in his team knows and loves rust. all the rest are secondary reasons
- imron 4y ago
  All the rest are the reasons they love Rust.
- DeathArrow 4y ago
  Imagine if everyone in his team knew and loved x86 assembler. :)
hardwaregeek 4y ago
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.
- TylerE 4y ago
  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.
  - steveklabnik 4y ago
    > 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.
    - DeathArrow 4y ago
      > Rust was intended for the layer of the stack where these things do matter. Good point. If those things don't matter, then maybe you are better off using another language.
  - smolder 4y ago
    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.
tetraodonpuffer 4y ago
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?
- jamincan 4y ago
  He does explain it in the article: - 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
  - tetraodonpuffer 4y ago
    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.
    - justincredible 4y ago
      [dead]
    - jdjb 4y ago
      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.
    - jamincan 4y ago
agentultra 4y ago
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.
- noelwelsh 4y ago
  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.)
- bitL 4y ago
  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.
  - dboreham 4y ago
    Rust is cute until you notice your project build creates 50GB of ... something.
  - DeathArrow 4y ago
    But there are also OCaml and F#.
- IceDane 4y ago
falcolas 4y ago
To me, the answer will always boil down to “because we want to” for varying definitions of “we”. This choice is almost always more about the team than the technology, regardless of the specific language or framework or widget.
- alex_lav 4y ago
  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.
  - falcolas 4y ago
    Catering to a teams preference also gives you a free morale boost. And in the current economy of random mass layoffs, any morale boosters you can find will matter more.
Pepe1vo 4y ago
> 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.
- hot_gril 4y ago
  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.
  - davidatbu 4y ago
    > 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!
    - hot_gril 4y ago
      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.
mgomez 4y ago
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). [1] https://github.com/Keats/validator/issues/201 https://github.com/Keats/validator/issues/201 [2] https://json-schema.org/implementations.html#validator-rust https://json-schema.org/implementations.html#validator-rust

168 points by steveklabnik 4y ago

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.

steveklabnik 4y ago
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.
- whitepoplar 4y ago
  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?
  - arch-ninja 4y ago
    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.
    - oneplane 4y ago
      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.
  - steveklabnik 4y ago
    > 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.
    - DangitBobby 4y ago
  - eYrKEC2 4y ago
    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.
    - DoesntMatter22 4y ago
      I was using Chat GPT to learn rust but most of the examples it generated were pretty old (mysql 4 vs now at 21).
      - joshka 4y ago
        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.
        andrewstuart 4y ago
        You’re saying AI has trouble learning Rust too?
        joshka 4y ago
        Lol. Yup. Though it’s possible that it was overfitting its response to my noob questions. I’ve had better luck since.
  - joshka 4y ago
    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?
- makestuff 4y ago
  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.
  - moonchrome 4y ago
    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. With go it's probably days.
    - iudqnolq 4y ago
      > 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.
      - phamilton 4y ago
        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.
- tiffanyh 4y ago
  Off-topic: has Oxide shipped anything yet? Geniunely curious since the company was found 3+ years ago (2019). https://oxide.computer/blog/introducing-the-oxide-computer-company https://oxide.computer/blog/introducing-the-oxide-computer-c...
  - steveklabnik 4y ago
    Server racks? Not just yet! Soon though. As we get closer, we’ve talked about it more and more, see this recent Oxide and Friends, for example: https://oxide.computer/podcasts/oxide-and-friends/1200412 https://oxide.computer/podcasts/oxide-and-friends/1200412 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.
    - dsincl12 4y ago
      Would that be dropshot you're referring to?
      - steveklabnik 4y ago
        Dropshot is the framework, omicron is the control plane implementation, which uses dropshot.
  - deleted 4y ago
    [deleted]
- evntdrvn 4y ago
  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…
  - saurik 4y ago
    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).
- DeathArrow 4y ago
  >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.
deleted 4y ago
[deleted]
gonzo41 4y ago
This is a very good point on thinking about engineering sustainability
nivenkos 4y ago
Rust isn't magic, you can become reasonably proficient in a couple of weeks just as with any other language.
- deleted 4y ago
  [deleted]
BFLpL0QNek 4y ago
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?
- hot_gril 4y ago
  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.
  - AA-BA-94-2A-56 4y ago
    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.
    - hot_gril 4y ago
      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.
JohnFen 4y ago
> 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.
- zeroxfe 4y ago
  That sounds reasonable in theory, but doesn't work out in practice.
  - re-thc 4y ago
    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.
  - JohnFen 4y ago
    I've seen it work in practice plenty of times. It does take a particular sort of dev, though.
- hot_gril 4y ago
  It's not about learning the language itself, it's about learning the tooling and libs associated with it, and that takes time.
Klonoar 4y ago
You do not need an expert-level Rust developer for a backend web server. The hiring pool isn't really a big deal here.
- _piif 4y ago
  Yup. It's only an issue if you insist on an immense amount of years of experience as a requirement for working on your web stack.
fnordpiglet 4y ago
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.
- DeathArrow 4y ago
  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.
  - fnordpiglet 4y ago
    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.
mrits 4y ago
If a recent college grad can't learn rust quickly the rest of us have no hope.
imron 4y ago
> 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.
tialaramex 4y ago
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.
- DeathArrow 4y ago
  >If your software ends up with non-trivial amounts of Unsafe Rust Than maybe it's easier to just use C or C++.
deleted 4y ago
[deleted]
patientplatypus 4y ago
[dead]
DeathArrow 4y ago
> 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.
justsomeuser 4y ago
I don’t think it is that serious of an issue: - 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.
paulddraper 4y ago
By the same token, if all you have is Flask engineers, and you need a Rust service, it's going to be a struggle too.

mastax 4y ago

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.

malkia 4y ago

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.)

yutijke 4y ago

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.

koito17 4y ago
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.
- yutijke 4y ago
  "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.

thallada 4y ago

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.

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
hot_gril 4y ago
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.
eYrKEC2 4y ago
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.

notyourday 4y ago

[flagged]

sealeck 4y ago
I think this is a really cruel thing to say.
goodpoint 4y ago
[flagged]

RaiyanYahya 4y ago

I picked up Go quite fast but its quite different with Rust. The learning curve i feel is steeper.

beckler 4y ago
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.
dgunay 4y ago
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.

jeremychone 4y ago

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.

DeathArrow 4y ago

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.

wellanyway 4y ago

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.

aww_dang 4y ago

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?

adamch 4y ago
I would choose [axum](https://docs.rs/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.
sn9 4y ago
https://www.arewewebyet.org/ https://www.arewewebyet.org/

deleted 4y ago

[deleted]

paulgb 4y ago

Glad to see serde mentioned as a top-level item here. It’s a huge timesaver for anything that sends data over the network or persists it to disk.

Reitet00 4y ago

Very nice post even though they're always in this form of "here is my 10 favorite Rust features". Another one along the same lines: https://cloak.software/blog/i-built-startup-in-rust/ https://cloak.software/blog/i-built-startup-in-rust/ > 95% of the unwraps in our codebase are in unit tests. There's a crate for that: https://crates.io/crates/testresult https://crates.io/crates/testresult

dijit 4y ago

> 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.

necubi 4y ago
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/ 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.
- biorach 4y ago
  > * 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. wait... proc macros are run at compile time, right? so db queries at compile time?! but.. but.. why?
  - Klonoar 4y ago
    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.

shashashasha___ 4y ago

at the end, in his usecase, everyone in his team knows and loves rust. all the rest are secondary reasons

imron 4y ago
All the rest are the reasons they love Rust.
DeathArrow 4y ago
Imagine if everyone in his team knew and loved x86 assembler. :)

hardwaregeek 4y ago

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.

TylerE 4y ago
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.
- steveklabnik 4y ago
  > 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.
  - DeathArrow 4y ago
    > Rust was intended for the layer of the stack where these things do matter. Good point. If those things don't matter, then maybe you are better off using another language.
- smolder 4y ago
  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.

tetraodonpuffer 4y ago

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?

jamincan 4y ago
He does explain it in the article: - 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
- tetraodonpuffer 4y ago
  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.
  - justincredible 4y ago
    [dead]
  - jdjb 4y ago
    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.
  - jamincan 4y ago

agentultra 4y ago

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.

noelwelsh 4y ago
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.)
bitL 4y ago
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.
- dboreham 4y ago
  Rust is cute until you notice your project build creates 50GB of ... something.
- DeathArrow 4y ago
  But there are also OCaml and F#.
IceDane 4y ago

falcolas 4y ago

To me, the answer will always boil down to “because we want to” for varying definitions of “we”. This choice is almost always more about the team than the technology, regardless of the specific language or framework or widget.

alex_lav 4y ago
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.
- falcolas 4y ago
  Catering to a teams preference also gives you a free morale boost. And in the current economy of random mass layoffs, any morale boosters you can find will matter more.

Pepe1vo 4y ago

> 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.

hot_gril 4y ago
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.
- davidatbu 4y ago
  > 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!
  - hot_gril 4y ago
    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.

mgomez 4y ago

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). [1] https://github.com/Keats/validator/issues/201 https://github.com/Keats/validator/issues/201 [2] https://json-schema.org/implementations.html#validator-rust https://json-schema.org/implementations.html#validator-rust