16 ms·

If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or

If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a fantastic language for many purposes, but it has a very high development cost.

wyager 4y ago
Precisely. If you like what you see in Rust but you don't need to worry about extremely strict hardware/memory/realtime constraints (i.e. you could use a memory-managed language), consider Haskell instead.
Animats 4y ago
> If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. It ought to be used more for high-performance games, but the game infrastructure isn't there yet. Unreal Engine is C++ and Unity is C#. Rust has Bevy and Rend3, but they're not AAA title ready. Perhaps Rust is fighting the last war - the mess inside C++.
- WJW 4y ago
  There is probably a good space for Rust in writing the databases, caches and all sorts of proxies as well. I agree though, for most of the stuff I need for $DAYJOB the speed is nice but hardly required. It doesn't really matter if I can generate a HTTP response 50 microseconds quicker if the response then has to travel over the internet for 20+ milliseconds.
  - zozbot234 4y ago
    It does matter if you're using cloud autoscaling FaaS (previously known as CGI) and paying for those HTTP responses by the microsecond (and by RAM usage as well, which is also typically quite low in Rust).
    - WJW 4y ago
      Not really, the connection won't close until you are done sending it all and have received the relevant TCP ACK messages from the other sides. Being on autoscaling FAAS or not does not matter for that. In any case, if you are trying to optimize microsecond usage in AWS lambda I hope you have a truly gargantuan amount of traffic and/or have incredibly cheap engineers or the money saved will barely match up to the cost of the engineering hours sunk into them.
      - steveklabnik 4y ago
        So here's a real-world case of where this actually does matter: https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-with-rust/ https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w... two minor follow-ups on that as well: * https://andre.arko.net/2019/01/11/parsing-logs-faster-with-rust-continued/ https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r... * https://andre.arko.net/2022/03/13/parsing-logs-faster-with-rust-revisited/ https://andre.arko.net/2022/03/13/parsing-logs-faster-with-r...
        WJW 4y ago
        I appreciate that there might be use cases where performance absolutely does matter, and log parsing is indeed one of the sweet spots for that. But offline analytics is something quite different than HTTP request generation, even if you sometimes do both in an AWS lambda. Additionally for the case mentioned, the log parsing apparently already fit quite comfortably in the free tier of AWS lambda. Rubygems.org seems to get its developer time for free, so Andre can keep tuning this log parser as a hobby experiment (in the best sense of the word, nothing wrong with having fun). But TFA was about building a startup and most of those definitely don't manage to get their devs to work for free.
- pcwalton 4y ago
  > A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actual Web app (I personally think it's a solid choice, but reasonable people can disagree). But for building, say, the Python cryptography library [1], which is used as a part of "webcrap", Jupyter notebooks, and in many other domains, Rust is clearly an excellent option. Nobody is going to build core Python infrastructure in Go or Node, and without the plumbing libraries none of the higher-level applications can function. [1]: https://github.com/pyca/cryptography https://github.com/pyca/cryptography
  - huijzer 4y ago
    You mean to link against Rust binaries or can you make library files too? Compared to, say, SQLite as a single C file, I thought that Rust projects are not super easy to use as a dependency
    - ameliaquining 4y ago
      Rust can output library files that use the C calling convention, either static or dynamic. Doing this entirely by hand is pretty annoying, because your API surface has to be C-compatible (so can't contain a lot of Rust's useful language features) and because you still have to do the other half of the FFI to use the library from the other language. However, it's possible to develop automated language-specific tooling to make this easier, with PyO3 being a particularly impressive example.
    - f_devd 4y ago
      Depends on how you link rust, using PyO3 makes it arguably easier to do link python code to rust than any C construction I could think off. Linking a single C file into python is quite difficult (if not using JIT like cppyy) because you need to make bindings & conversion often on both sides for each exported function.
  - 4y ago
- lumb63 4y ago
  They are out of the mainstream, but only because "systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge" "SOLVE THE BEAR MENACE" [0]. [0]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf https://www.usenix.org/system/files/1311_05-08_mickens.pdf
- usgroup 4y ago
  You're right. I think that it replaces C/C++ for many use cases. I'm a quant, and I use it to write fast algos for research. It won't be long until Rust has good high level SIMD primitives like the faster crate offered. I can't see myself using anything else thereafter for performant code. You may be underestimating the amount of need there is for performant code though. Its everywhere.
- hot_gril 4y ago
  > If you're building web backends, Rust is not a good choice This heuristic wouldn't work for my department because we build web backends in C++. I keep telling the most senior devs here that nobody does this and for good reasons (velocity etc), and their response is "who cares what the rest of the world does, they're just bad at C++."
  - Animats 4y ago
    Google developed Go specifically so they didn't have to use C++ in high-volume web backends, which is what they did previously.
    - hot_gril 4y ago
      These aren't high-volume, they're just web interfaces used internally by hundreds of people. Golang wasn't well-received either in our dept. Java would've saved us a lot of headache, a phrase I never thought I'd say; adjacent teams use it for similar things.
    - Frog0fWar 4y ago
      Another (maybe even more) important motivation was to have simple, statically-typed language so that new hires can contribute to the codebase faster and the code itself is more standardized and easier to maintain at large scale.
      - hot_gril 4y ago
        They basically got there with Java + some frameworks. It's not the best (I'd like NodeJS), but it works and has a huge ecosystem already, and anyone can use it. Some people complain that Golang is designed specifically for its original use case of specialized web backends and isn't great otherwise, or that its main design goal was being "not C++."
    - pcwalton 4y ago
      Google absolutely uses lots of C++ in high-volume web backends today. Go didn't replace it.
- Klonoar 4y ago
  >I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. The thing here is that most web backends are basic CRUD bullshit, and you fundamentally will not hit the thread/async distinction, nor need to care about whether there's garbage collection or not. Microsoft has used actix-web in production as far as I know, it's not like the Rust web stack isn't battle tested. >Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. These are all the things that sit adjacent to a web framework, and once you step outside that CRUD happy path, Rust fits very well - and in this case just "bolts on". >It's not that useful for phone apps. This is more tangential but I know of more than a few companies who have written or are writing their cross-platform logic in Rust instead of C++. This is really akin to how some projects back Python modules with Rust: it's easy to have it backing things and it beats the hell out of dealing with C++. And look, I'm not even saying don't use Go/Python/JS/<insert your preferred language here>. You do you, your startup will live or die by so many other things than choice of programming language.
  - satvikpendem 4y ago
    Exactly. And for phone apps, using Flutter with flutter_rust_bridge is a great choice for FFI.
- FridgeSeal 4y ago
  I’ve been writing data ETL pipelines in Rust and having a fantastic time. Most of my data, cost and performance requirements aren’t suited to the likes of FiveTran/etc, and whilst I could theoretically use Python, it’s far too slow, and the propensity to crash unexpectedly (meaning I have to spend extra time debugging) means the development velocity is actually worse than just writing it in Rust. Plus, most of the libs and tooling I’d use from Python are available in Rust. I’ve also written Rest and GRPC API’s in Rust (mostly for serving up data and being a query layer), and found it a far more pleasant experience than Python/Typescript/C#. Admittedly a somewhat ”smaller” use-case than a lot of what people would consider web-API’s but still.
  - gregw2 4y ago
    How much of your ETL is rust vs SQL? I agree pandas for ETL isn’t the fastest but why not isn’t SQL faster still? Or don’t you find yourself in the situation where there is so little logic in the ETL that rust performance/safety isn’t that useful?
- rixed 4y ago
  > and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. Internally Google uses no web and most of the backends are in C++.
- therockhead 4y ago
  > It’s not that useful for phone apps. If you’re building a large complex app that needs to be shared across multiple platforms, C++ is a common choice. Not talking about games here, think Office, Facebook, Zoom, WebEx etc. It easy to see Rust replacing C++ in that stack. But as Rust is so much nicer that C++, I could see it becoming popular for smaller projects that want to share common logic, with a native UI on top.
- pyuser583 4y ago
  Oooh Rust gaming engines. Hadn’t thought of that. One of my favorite games is coincidentally named “Rust.”
Night_Thastus 4y ago
I think it's dismissive and overly simplistic to say that Rust is almost always a better option than C or C++. They're different languages with different strengths. One strength of C++ is that it is far more established than rust - and that comes with a lot of advantages: * It has a larger number of people who know how to work with it * It has a huge catalog of established, fully functional libraries for everything you could imagine from UI to game development to embedded systems to simulation to anything else * It has broad support in developer toolsets in general like editors and IDEs, static analysis tools, formatters, pre-commit hooks, etc If I'm starting a new project with C++, I can immediately know that there's a huge landscape of programming already carved up and ready to work with. I can't do that as easily in Rust. The language, the libraries, the tools are all younger. Some of it isn't as fully featured, some of it isn't nearly as stable. That will improve with time, but it's a huge advantage to C++ right now.
- KMag 4y ago
  That's not the argument the GP is making. The GP is basically saying that if C/C++ aren't your second choice of language, then it's a sign your reasons for picking Rust are suspect. They didn't say Rust is almost always better than C/C++. There's perhaps the implication there, but it's certainly not explicit in the GP's comments.
- Animats 4y ago
  > One strength of C++ is that it is far more established than Rust - and that comes with a lot of advantages: I'm painfully aware of this. Typical Rust problem, from a reply I made to a posting on Reddit: * WebGPU dev: WGPU updated to 0.15! * Me: Might want to hold off on upgrading for a bit. See (bug report on related package) * WebGPU dev: Good to know. I'll keep this in mind if someone has any issues when following my tutorial * Me: I'm using Egui/rend3/wgpu/winit/vulkan cross platform on Linux and Windows, with cross-compiling. Getting all those crates to play well together is not easy. Every time something in that stack changes, it's days or weeks of trouble.
- bsder 4y ago
  > That will improve with time, but it's a huge advantage to C++ right now. Sadly, it's not really an advantage anywhere that hasn't already eaten the grief and doesn't already use C++. Both C and C++ infrastructure are so horribly terrible that Zig is gaining traction simply by creating a better compiling infastructure totally indepdent of whether the language is better or not. That's one hell of a downvote.
jjnoakes 4y ago
I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness. I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe all it needs is time.
- baby 4y ago
  Yeah I would have recommended OCaml, the language seriously need more developers to contribute to the ecosystem. It could be much nicer.
- jdlshore 4y ago
  Have you looked at Node + TypeScript? I'm just starting to dig into TS, but its type system is one of the better ones I've seen. And Node is nice and mature with good async capabilities.
  - jjnoakes 4y ago
    I'd prefer something with a more sound type system, and something that makes cleaning up resources easier and more ergonomic. This might help with cleanup: https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen... But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMAUBtARARgAyYBoACHfY0zAXXgFsBDAB1QboCcJYBJMAFwEo+AKCA https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...
    - jdlshore 4y ago
      > makes cleaning up resources easier I've never really had a problem with it, but I isolate such resources behind a wrapper, which makes cleanup easy. I just create a little higher-order function: function doSomethingThatNeedsCleanup(fn) { const thing = createTheThing(); try { return fn(thing); } finally { cleanUpTheThing(thing); } } > this drives me absolutely insane (console.log(["10", "10", "10"].map(parseInt) outputs [10, NaN, 2]) That's not really an issue with the type system, that's just coincidence and bad luck. The signature of parseInt is: parseInt(string: string, radix?: number | undefined): number And Array<string>.map(fn) takes a function with the signature: fn(element: string, index?: number | undefined, array?: string[] | undefined): any So parseInt coincidentally matches the signature Array<string>.map() is looking for. I'm not sure what you expect the type system to do here. It works just fine at catching an actual type error, such as this: console.log([10, 10, 10].map(parseInt) ...which correctly complains: Argument of type '(string: string, radix?: number | undefined) => number' is not assignable to parameter of type '(value: number, index: number, array: number[]) => number'. Types of parameters 'string' and 'value' are incompatible. Type 'number' is not assignable to type 'string'. (As I'm sure you know, this is the correct code: `console.log(["10", "10", "10"].map(s => parseInt(s))` .)
autophagian 4y ago
I feel like this is probably on the money, at least when it comes to building a startup. I often use Rust where before I would use Go/NodeJS/Python, but mostly because I like the type system and velocity on side-projects isn't as important.
andrepd 4y ago
I don't agree with this. If Rust doesn't exist you might have a choice between the pain and endless bugs of using C++ or the ease, but much slower performance, of js. Maybe you end up choosing js. But if Rust exists, suddenly you have a nicer-to-use high performance language, and you have a choice to use it.
jmmv 4y ago
On the contrary. I’ve been recently writing a web service in Go… and omg what a terrible experience. Sure, I could prototype something very quickly, but now it’s almost impossible to refactor any of it without introducing subtle breakage. And it’s sooooo verbose and redundant and fragile. I’m currently rewriting what I wrote in Rust to see how the prototypes compare and… I just feel so much at peace knowing that the type system and the borrow checker have my back and that I won’t encounter unexpected nil pointers or zero values. And I write this quickly as well. (Yes, I do have experience with both languages, so none of these exercises were new to me. But I’ve been favoring Rust over the last couple of years.)
- jmaker 4y ago
  Quite the opposite here. Go is very easy to refactor if need be. What kind “breakages” are you talking about? Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. In Go you have a garbage collector, no need for the borrow checker or reference counting on your side. What unexpected nil pointers or zeros? It’s all easy and straightforward in Go. If you’re referring to the handling of materialized interfaces, which one may encounter in form of concrete error types, and which is one of Go’s idiosyncrasies, then it might help to look deeper into learning how to handle Go’s interfaces.
  - drogus 4y ago
    > Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. Maybe compared to C, Go is quite concise, but Go is nowhere near Rust's level of expressiveness, especially with poor generics support, much more verbose error handling etc. > no need for the borrow checker or reference counting on your side. I think that people that mention borrow checker in context of backend dev haven't done much backend dev in Rust. The nature of a web backend is to (most of the time) get data from the client, process, return a response. In this context you very rarely have to think about borrow checker and almost never use explicit lifetimes. > What unexpected nil pointers or zeros? It’s all easy and straightforward in Go If you forget to initialize a struct, you may end up with a nil pointer and you might not catch it until runtime.
- 4y ago
jeremychone 4y ago
I would differ that Rust would not be a better choice than Rust. Seeing Rust as a system programming language only is missing the bigger picture (IMO).
gofreddygo 4y ago
Or as Charlie Munger would invert, "What kind of startup would fail because it chose Rust ?" Then don't be.
richardwhiuk 4y ago
Not sure I agree with Go vs Rust. I think if you would choose Java or Python or C#, then Rust might not be the right choice.
- marcosdumay 4y ago
  Whatever the absolute merits (or lack of them) of Go, the fact is that if it's a good (enough) option for you, then it's almost certain that some language will fit your problem better than Rust.
- pleb_nz 4y ago
  I wouldn't group python with java and c# either. Quite different beasts
- ntonozzi 4y ago
  Go belongs in the exact same bucket as Java and C#.
  - galangalalgol 4y ago
    C# sure, but unless you are doing something pretty close to the core purpose of some giant java framework java is slow and verbose
    - tasubotadas 4y ago
      Slow and verbose compared to what?
    - ntonozzi 4y ago
      Java, Go and C# (and node) have very similar performance, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For all of them, the key to writing high performance code is avoiding allocations and boxing. Go and C# both do this slightly better than Java, but in most domains where these languages are used, this is not a big difference (and this is where you might use C/C++/Rust instead). I've found Go to be more verbose than Java, but I haven't used Go much since generics were released.
aisrael 4y ago
This is really great way of putting it. Node/Python/Go were the obvious alternatives for us.
galangalalgol 4y ago
Rust is a high development cost compared to node.js python or julia, but I'd say it is about the same as go or c#. Maybe a little better than all of those if you consider time getting test coverage. But if you are prototyping you probably aren't doing that. I'd say rust is a much lower development cost than c++ or java.
- adastra22 4y ago
  Golang absolutely has a faster development cycle than Rust. Unless you’re a Rust expert who never touches Go, but then it’s an issue of familiarity. Go devs hit the ground running and the ergonomics are streamlined, and the borrow checker and other rust restrictions don’t get in the way.
  - galangalalgol 4y ago
    Given my downvotes you seem to be with the consensus on this one. I had 30 years of c++ development going into rust and I never found myself fighting the borrow checker. Golang seemed the same, just started coding and stuff worked mostly. But, the complexity of rust was familar coming from c++ with generics and macros but without some of the footguns, so it just seemed like power, not clutter. I like go, but I wouldn't prototype in it, I'd pick julia or python. And if I'm familiar with the problem and want to code for production, rust really doesn't seem any slower to develop in than go to me and perhaps a bit less verbose. But in retrospect I think that is because of the direction I came at rust from means my habitual coding style lined up more closely with what rust expects. Its not a harder coding mindset, just a different one than someone who came from java would be used to.
    - lenkite 4y ago
      30 years of C++ development experience means you aren't going to find any PL difficult and therefore your views on easy/difficult a PL is to learn and get going cannot be taken seriously. :)
      - 4y ago
ozten 4y ago
NodeJS kind of muddies the waters. It ate a lot of use cases that would have previously been done in Java. That created conflict between backend teams that wanted statically typed code and a "boring" tech choice against "full stack" developers creating a backend service. I think Rust will see a lot of adoption in web services that are glorified CRUD APIs. It would have been a poor choice to do many of these workloads in this in C or C++ (despite the data point of Amazon 1.0 LOLz).
- dirheist 4y ago
  Wouldn't you just use go/python/node for a simple crud API? fastapi for python is pretty performative if you use gunicorn as your runtime and time to iterate is must faster than it is in rust.
  - mcronce 4y ago
    It depends exactly how simple that CRUD API is. If there's any business logic, I'd rather get all the cheap correctness guarantees that Rust provides. I don't find myself making many truly dumb CRUD APIs. Time to iterate is also only much faster in certain situations, e.g. local development; if you have to e.g. build a container image, push to a registry, and redeploy to a k8s cluster somewhere, those savings become somewhere between less significant and nonexistent.
    - nawgz 4y ago
      > Time to iterate is also only much faster in certain situations, e.g. local development; if you have to e.g. build a container image, push to a registry, and redeploy to a k8s cluster somewhere, those savings become somewhere between less significant and nonexistent. Can you expand on what you mean here? I know you're not implying Rust is faster to move thru a CICD pipeline, so can you tell me what you do mean? I seem to be unable to make a different reading
      - Frog0fWar 4y ago
        I think the point being made here is that all CI/CD/SDLC stuff is effectively slowing down development, so the difference in iteration speed between Python and Rust is less explicit. But I dare to disagree, I just can't connect the dots here, moving code further down the CICD pipeline doesn't mean we can't work on the code itself or think about project improvement ideas.
JamesSwift 4y ago
That really is a great way to think about it, and my previous experiences with the "wrong choice of Rust" seem so obvious when filtered through this lens.
avinassh 4y ago
Three months ago I had made exactly similar comment, it felt nice to me to see the same thought echoed! https://news.ycombinator.com/item?id=33845045 https://news.ycombinator.com/item?id=33845045
- deleted 4y ago
  [deleted]
drogus 4y ago
Most of the posts mentioning Rust not being the best choicce for a startup talk about iteration speed and prototyping. In that light I don't think this is the best heuristic. If you need to prototype quickly and search for a market fit, then by all means, choose whatever will make you go fastest (and I'd argue for a lot of use cases it would be Elixir with Phoenix's LiveView if you don't absolutely need an SPA or a mobile app), but if you're building sth that already has a market, Rust might be still a good choice even if it's not a C/C++ fit.

wyager 4y ago

Precisely. If you like what you see in Rust but you don't need to worry about extremely strict hardware/memory/realtime constraints (i.e. you could use a memory-managed language), consider Haskell instead.

Animats 4y ago

> If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. It ought to be used more for high-performance games, but the game infrastructure isn't there yet. Unreal Engine is C++ and Unity is C#. Rust has Bevy and Rend3, but they're not AAA title ready. Perhaps Rust is fighting the last war - the mess inside C++.

WJW 4y ago
There is probably a good space for Rust in writing the databases, caches and all sorts of proxies as well. I agree though, for most of the stuff I need for $DAYJOB the speed is nice but hardly required. It doesn't really matter if I can generate a HTTP response 50 microseconds quicker if the response then has to travel over the internet for 20+ milliseconds.
- zozbot234 4y ago
  It does matter if you're using cloud autoscaling FaaS (previously known as CGI) and paying for those HTTP responses by the microsecond (and by RAM usage as well, which is also typically quite low in Rust).
  - WJW 4y ago
    Not really, the connection won't close until you are done sending it all and have received the relevant TCP ACK messages from the other sides. Being on autoscaling FAAS or not does not matter for that. In any case, if you are trying to optimize microsecond usage in AWS lambda I hope you have a truly gargantuan amount of traffic and/or have incredibly cheap engineers or the money saved will barely match up to the cost of the engineering hours sunk into them.
    - steveklabnik 4y ago
      So here's a real-world case of where this actually does matter: https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-with-rust/ https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w... two minor follow-ups on that as well: * https://andre.arko.net/2019/01/11/parsing-logs-faster-with-rust-continued/ https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r... * https://andre.arko.net/2022/03/13/parsing-logs-faster-with-rust-revisited/ https://andre.arko.net/2022/03/13/parsing-logs-faster-with-r...
      - WJW 4y ago
        I appreciate that there might be use cases where performance absolutely does matter, and log parsing is indeed one of the sweet spots for that. But offline analytics is something quite different than HTTP request generation, even if you sometimes do both in an AWS lambda. Additionally for the case mentioned, the log parsing apparently already fit quite comfortably in the free tier of AWS lambda. Rubygems.org seems to get its developer time for free, so Andre can keep tuning this log parser as a hobby experiment (in the best sense of the word, nothing wrong with having fun). But TFA was about building a startup and most of those definitely don't manage to get their devs to work for free.
pcwalton 4y ago
> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actual Web app (I personally think it's a solid choice, but reasonable people can disagree). But for building, say, the Python cryptography library [1], which is used as a part of "webcrap", Jupyter notebooks, and in many other domains, Rust is clearly an excellent option. Nobody is going to build core Python infrastructure in Go or Node, and without the plumbing libraries none of the higher-level applications can function. [1]: https://github.com/pyca/cryptography https://github.com/pyca/cryptography
- huijzer 4y ago
  You mean to link against Rust binaries or can you make library files too? Compared to, say, SQLite as a single C file, I thought that Rust projects are not super easy to use as a dependency
  - ameliaquining 4y ago
    Rust can output library files that use the C calling convention, either static or dynamic. Doing this entirely by hand is pretty annoying, because your API surface has to be C-compatible (so can't contain a lot of Rust's useful language features) and because you still have to do the other half of the FFI to use the library from the other language. However, it's possible to develop automated language-specific tooling to make this easier, with PyO3 being a particularly impressive example.
  - f_devd 4y ago
    Depends on how you link rust, using PyO3 makes it arguably easier to do link python code to rust than any C construction I could think off. Linking a single C file into python is quite difficult (if not using JIT like cppyy) because you need to make bindings & conversion often on both sides for each exported function.
- 4y ago
lumb63 4y ago
They are out of the mainstream, but only because "systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge" "SOLVE THE BEAR MENACE" [0]. [0]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf https://www.usenix.org/system/files/1311_05-08_mickens.pdf
usgroup 4y ago
You're right. I think that it replaces C/C++ for many use cases. I'm a quant, and I use it to write fast algos for research. It won't be long until Rust has good high level SIMD primitives like the faster crate offered. I can't see myself using anything else thereafter for performant code. You may be underestimating the amount of need there is for performant code though. Its everywhere.
hot_gril 4y ago
> If you're building web backends, Rust is not a good choice This heuristic wouldn't work for my department because we build web backends in C++. I keep telling the most senior devs here that nobody does this and for good reasons (velocity etc), and their response is "who cares what the rest of the world does, they're just bad at C++."
- Animats 4y ago
  Google developed Go specifically so they didn't have to use C++ in high-volume web backends, which is what they did previously.
  - hot_gril 4y ago
    These aren't high-volume, they're just web interfaces used internally by hundreds of people. Golang wasn't well-received either in our dept. Java would've saved us a lot of headache, a phrase I never thought I'd say; adjacent teams use it for similar things.
  - Frog0fWar 4y ago
    Another (maybe even more) important motivation was to have simple, statically-typed language so that new hires can contribute to the codebase faster and the code itself is more standardized and easier to maintain at large scale.
    - hot_gril 4y ago
      They basically got there with Java + some frameworks. It's not the best (I'd like NodeJS), but it works and has a huge ecosystem already, and anyone can use it. Some people complain that Golang is designed specifically for its original use case of specialized web backends and isn't great otherwise, or that its main design goal was being "not C++."
  - pcwalton 4y ago
    Google absolutely uses lots of C++ in high-volume web backends today. Go didn't replace it.
Klonoar 4y ago
>I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. The thing here is that most web backends are basic CRUD bullshit, and you fundamentally will not hit the thread/async distinction, nor need to care about whether there's garbage collection or not. Microsoft has used actix-web in production as far as I know, it's not like the Rust web stack isn't battle tested. >Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. These are all the things that sit adjacent to a web framework, and once you step outside that CRUD happy path, Rust fits very well - and in this case just "bolts on". >It's not that useful for phone apps. This is more tangential but I know of more than a few companies who have written or are writing their cross-platform logic in Rust instead of C++. This is really akin to how some projects back Python modules with Rust: it's easy to have it backing things and it beats the hell out of dealing with C++. And look, I'm not even saying don't use Go/Python/JS/<insert your preferred language here>. You do you, your startup will live or die by so many other things than choice of programming language.
- satvikpendem 4y ago
  Exactly. And for phone apps, using Flutter with flutter_rust_bridge is a great choice for FFI.
FridgeSeal 4y ago
I’ve been writing data ETL pipelines in Rust and having a fantastic time. Most of my data, cost and performance requirements aren’t suited to the likes of FiveTran/etc, and whilst I could theoretically use Python, it’s far too slow, and the propensity to crash unexpectedly (meaning I have to spend extra time debugging) means the development velocity is actually worse than just writing it in Rust. Plus, most of the libs and tooling I’d use from Python are available in Rust. I’ve also written Rest and GRPC API’s in Rust (mostly for serving up data and being a query layer), and found it a far more pleasant experience than Python/Typescript/C#. Admittedly a somewhat ”smaller” use-case than a lot of what people would consider web-API’s but still.
- gregw2 4y ago
  How much of your ETL is rust vs SQL? I agree pandas for ETL isn’t the fastest but why not isn’t SQL faster still? Or don’t you find yourself in the situation where there is so little logic in the ETL that rust performance/safety isn’t that useful?
rixed 4y ago
> and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. Internally Google uses no web and most of the backends are in C++.
therockhead 4y ago
> It’s not that useful for phone apps. If you’re building a large complex app that needs to be shared across multiple platforms, C++ is a common choice. Not talking about games here, think Office, Facebook, Zoom, WebEx etc. It easy to see Rust replacing C++ in that stack. But as Rust is so much nicer that C++, I could see it becoming popular for smaller projects that want to share common logic, with a native UI on top.
pyuser583 4y ago
Oooh Rust gaming engines. Hadn’t thought of that. One of my favorite games is coincidentally named “Rust.”

Night_Thastus 4y ago

I think it's dismissive and overly simplistic to say that Rust is almost always a better option than C or C++. They're different languages with different strengths. One strength of C++ is that it is far more established than rust - and that comes with a lot of advantages: * It has a larger number of people who know how to work with it * It has a huge catalog of established, fully functional libraries for everything you could imagine from UI to game development to embedded systems to simulation to anything else * It has broad support in developer toolsets in general like editors and IDEs, static analysis tools, formatters, pre-commit hooks, etc If I'm starting a new project with C++, I can immediately know that there's a huge landscape of programming already carved up and ready to work with. I can't do that as easily in Rust. The language, the libraries, the tools are all younger. Some of it isn't as fully featured, some of it isn't nearly as stable. That will improve with time, but it's a huge advantage to C++ right now.

KMag 4y ago
That's not the argument the GP is making. The GP is basically saying that if C/C++ aren't your second choice of language, then it's a sign your reasons for picking Rust are suspect. They didn't say Rust is almost always better than C/C++. There's perhaps the implication there, but it's certainly not explicit in the GP's comments.
Animats 4y ago
> One strength of C++ is that it is far more established than Rust - and that comes with a lot of advantages: I'm painfully aware of this. Typical Rust problem, from a reply I made to a posting on Reddit: * WebGPU dev: WGPU updated to 0.15! * Me: Might want to hold off on upgrading for a bit. See (bug report on related package) * WebGPU dev: Good to know. I'll keep this in mind if someone has any issues when following my tutorial * Me: I'm using Egui/rend3/wgpu/winit/vulkan cross platform on Linux and Windows, with cross-compiling. Getting all those crates to play well together is not easy. Every time something in that stack changes, it's days or weeks of trouble.
bsder 4y ago
> That will improve with time, but it's a huge advantage to C++ right now. Sadly, it's not really an advantage anywhere that hasn't already eaten the grief and doesn't already use C++. Both C and C++ infrastructure are so horribly terrible that Zig is gaining traction simply by creating a better compiling infastructure totally indepdent of whether the language is better or not. That's one hell of a downvote.

jjnoakes 4y ago

I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness. I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe all it needs is time.

baby 4y ago
Yeah I would have recommended OCaml, the language seriously need more developers to contribute to the ecosystem. It could be much nicer.
jdlshore 4y ago
Have you looked at Node + TypeScript? I'm just starting to dig into TS, but its type system is one of the better ones I've seen. And Node is nice and mature with good async capabilities.
- jjnoakes 4y ago
  I'd prefer something with a more sound type system, and something that makes cleaning up resources easier and more ergonomic. This might help with cleanup: https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen... But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMAUBtARARgAyYBoACHfY0zAXXgFsBDAB1QboCcJYBJMAFwEo+AKCA https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...
  - jdlshore 4y ago
    > makes cleaning up resources easier I've never really had a problem with it, but I isolate such resources behind a wrapper, which makes cleanup easy. I just create a little higher-order function: function doSomethingThatNeedsCleanup(fn) { const thing = createTheThing(); try { return fn(thing); } finally { cleanUpTheThing(thing); } } > this drives me absolutely insane (console.log(["10", "10", "10"].map(parseInt) outputs [10, NaN, 2]) That's not really an issue with the type system, that's just coincidence and bad luck. The signature of parseInt is: parseInt(string: string, radix?: number | undefined): number And Array<string>.map(fn) takes a function with the signature: fn(element: string, index?: number | undefined, array?: string[] | undefined): any So parseInt coincidentally matches the signature Array<string>.map() is looking for. I'm not sure what you expect the type system to do here. It works just fine at catching an actual type error, such as this: console.log([10, 10, 10].map(parseInt) ...which correctly complains: Argument of type '(string: string, radix?: number | undefined) => number' is not assignable to parameter of type '(value: number, index: number, array: number[]) => number'. Types of parameters 'string' and 'value' are incompatible. Type 'number' is not assignable to type 'string'. (As I'm sure you know, this is the correct code: `console.log(["10", "10", "10"].map(s => parseInt(s))` .)

autophagian 4y ago

I feel like this is probably on the money, at least when it comes to building a startup. I often use Rust where before I would use Go/NodeJS/Python, but mostly because I like the type system and velocity on side-projects isn't as important.

andrepd 4y ago

I don't agree with this. If Rust doesn't exist you might have a choice between the pain and endless bugs of using C++ or the ease, but much slower performance, of js. Maybe you end up choosing js. But if Rust exists, suddenly you have a nicer-to-use high performance language, and you have a choice to use it.

jmmv 4y ago

On the contrary. I’ve been recently writing a web service in Go… and omg what a terrible experience. Sure, I could prototype something very quickly, but now it’s almost impossible to refactor any of it without introducing subtle breakage. And it’s sooooo verbose and redundant and fragile. I’m currently rewriting what I wrote in Rust to see how the prototypes compare and… I just feel so much at peace knowing that the type system and the borrow checker have my back and that I won’t encounter unexpected nil pointers or zero values. And I write this quickly as well. (Yes, I do have experience with both languages, so none of these exercises were new to me. But I’ve been favoring Rust over the last couple of years.)

jmaker 4y ago
Quite the opposite here. Go is very easy to refactor if need be. What kind “breakages” are you talking about? Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. In Go you have a garbage collector, no need for the borrow checker or reference counting on your side. What unexpected nil pointers or zeros? It’s all easy and straightforward in Go. If you’re referring to the handling of materialized interfaces, which one may encounter in form of concrete error types, and which is one of Go’s idiosyncrasies, then it might help to look deeper into learning how to handle Go’s interfaces.
- drogus 4y ago
  > Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. Maybe compared to C, Go is quite concise, but Go is nowhere near Rust's level of expressiveness, especially with poor generics support, much more verbose error handling etc. > no need for the borrow checker or reference counting on your side. I think that people that mention borrow checker in context of backend dev haven't done much backend dev in Rust. The nature of a web backend is to (most of the time) get data from the client, process, return a response. In this context you very rarely have to think about borrow checker and almost never use explicit lifetimes. > What unexpected nil pointers or zeros? It’s all easy and straightforward in Go If you forget to initialize a struct, you may end up with a nil pointer and you might not catch it until runtime.
4y ago

jeremychone 4y ago

I would differ that Rust would not be a better choice than Rust. Seeing Rust as a system programming language only is missing the bigger picture (IMO).

gofreddygo 4y ago

Or as Charlie Munger would invert, "What kind of startup would fail because it chose Rust ?" Then don't be.

richardwhiuk 4y ago

Not sure I agree with Go vs Rust. I think if you would choose Java or Python or C#, then Rust might not be the right choice.

marcosdumay 4y ago
Whatever the absolute merits (or lack of them) of Go, the fact is that if it's a good (enough) option for you, then it's almost certain that some language will fit your problem better than Rust.
pleb_nz 4y ago
I wouldn't group python with java and c# either. Quite different beasts
ntonozzi 4y ago
Go belongs in the exact same bucket as Java and C#.
- galangalalgol 4y ago
  C# sure, but unless you are doing something pretty close to the core purpose of some giant java framework java is slow and verbose
  - tasubotadas 4y ago
    Slow and verbose compared to what?
  - ntonozzi 4y ago
    Java, Go and C# (and node) have very similar performance, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For all of them, the key to writing high performance code is avoiding allocations and boxing. Go and C# both do this slightly better than Java, but in most domains where these languages are used, this is not a big difference (and this is where you might use C/C++/Rust instead). I've found Go to be more verbose than Java, but I haven't used Go much since generics were released.

aisrael 4y ago

This is really great way of putting it. Node/Python/Go were the obvious alternatives for us.

galangalalgol 4y ago

Rust is a high development cost compared to node.js python or julia, but I'd say it is about the same as go or c#. Maybe a little better than all of those if you consider time getting test coverage. But if you are prototyping you probably aren't doing that. I'd say rust is a much lower development cost than c++ or java.

adastra22 4y ago
Golang absolutely has a faster development cycle than Rust. Unless you’re a Rust expert who never touches Go, but then it’s an issue of familiarity. Go devs hit the ground running and the ergonomics are streamlined, and the borrow checker and other rust restrictions don’t get in the way.
- galangalalgol 4y ago
  Given my downvotes you seem to be with the consensus on this one. I had 30 years of c++ development going into rust and I never found myself fighting the borrow checker. Golang seemed the same, just started coding and stuff worked mostly. But, the complexity of rust was familar coming from c++ with generics and macros but without some of the footguns, so it just seemed like power, not clutter. I like go, but I wouldn't prototype in it, I'd pick julia or python. And if I'm familiar with the problem and want to code for production, rust really doesn't seem any slower to develop in than go to me and perhaps a bit less verbose. But in retrospect I think that is because of the direction I came at rust from means my habitual coding style lined up more closely with what rust expects. Its not a harder coding mindset, just a different one than someone who came from java would be used to.
  - lenkite 4y ago
    30 years of C++ development experience means you aren't going to find any PL difficult and therefore your views on easy/difficult a PL is to learn and get going cannot be taken seriously. :)
    - 4y ago

ozten 4y ago

NodeJS kind of muddies the waters. It ate a lot of use cases that would have previously been done in Java. That created conflict between backend teams that wanted statically typed code and a "boring" tech choice against "full stack" developers creating a backend service. I think Rust will see a lot of adoption in web services that are glorified CRUD APIs. It would have been a poor choice to do many of these workloads in this in C or C++ (despite the data point of Amazon 1.0 LOLz).

dirheist 4y ago
Wouldn't you just use go/python/node for a simple crud API? fastapi for python is pretty performative if you use gunicorn as your runtime and time to iterate is must faster than it is in rust.
- mcronce 4y ago
  It depends exactly how simple that CRUD API is. If there's any business logic, I'd rather get all the cheap correctness guarantees that Rust provides. I don't find myself making many truly dumb CRUD APIs. Time to iterate is also only much faster in certain situations, e.g. local development; if you have to e.g. build a container image, push to a registry, and redeploy to a k8s cluster somewhere, those savings become somewhere between less significant and nonexistent.
  - nawgz 4y ago
    > Time to iterate is also only much faster in certain situations, e.g. local development; if you have to e.g. build a container image, push to a registry, and redeploy to a k8s cluster somewhere, those savings become somewhere between less significant and nonexistent. Can you expand on what you mean here? I know you're not implying Rust is faster to move thru a CICD pipeline, so can you tell me what you do mean? I seem to be unable to make a different reading
    - Frog0fWar 4y ago
      I think the point being made here is that all CI/CD/SDLC stuff is effectively slowing down development, so the difference in iteration speed between Python and Rust is less explicit. But I dare to disagree, I just can't connect the dots here, moving code further down the CICD pipeline doesn't mean we can't work on the code itself or think about project improvement ideas.

JamesSwift 4y ago

That really is a great way to think about it, and my previous experiences with the "wrong choice of Rust" seem so obvious when filtered through this lens.

avinassh 4y ago

Three months ago I had made exactly similar comment, it felt nice to me to see the same thought echoed! https://news.ycombinator.com/item?id=33845045 https://news.ycombinator.com/item?id=33845045

deleted 4y ago
[deleted]

drogus 4y ago

Most of the posts mentioning Rust not being the best choicce for a startup talk about iteration speed and prototyping. In that light I don't think this is the best heuristic. If you need to prototype quickly and search for a market fit, then by all means, choose whatever will make you go fastest (and I'd argue for a lot of use cases it would be Elixir with Phoenix's LiveView if you don't absolutely need an SPA or a mobile app), but if you're building sth that already has a market, Rust might be still a good choice even if it's not a C/C++ fit.