Hacker News Reader

Comment by bamazizi | Hacker News Reader

I've tried Rust for a short while to get a good feel. I've been Go developer for nearly a decade. Unfortunately there's a bit of a forced and misleading Rust favoritism the days but from my experience in various startups, including my current one, Go is by far the best choice for backend development!

- Rust is not suitable for fast paste startup environment

- Rust is not suitable if the initial team members are not Rust experts

- Rust is not suitable if the startup doesn't have money (Rust devs are very expensive and scarce)

- Rust is not general hire friendly

- Rust is not ideal for iterative and high refactor potential of startup culture

- Rust is painful/heartbreaking when eventuality of a pivot approaches

- Rust is not an advantage in anything startup related

Go is the exact opposite of above points! Note: I didn't talk about performance, feature or whatever else ... both languages are very very close to each other!

View on HN

Having built our startup on Rust with no prior knowledge of it: These are not facts but subjective opinions that might be true for you but not for everyone.

We tried both Rust and Go

-Rust is very suitable for fast pace environments because I don't have to worry at all about a whole class of issues

- Almost all of us learned Rust on the job and it worked quite fine. The more you learn the better you get, same is probably true for other languages

- We found that Rust devs are not more expensive, quite the opposite. We have people willing to switch jobs just so they can develop in Rust

- We found that adding "rust" to the job adverts increases engagement by .. a lot

- The others are even more subjective and also not true for us

I don't doubt that this was your experience at all. This might even be a majority opinion even though I doubt it. But it is definitely not true for everybody.

Indeed, my web backend is in Rust and it's rock solid, no crashes even a single time in a few years, simply because Rust looks out for errors a lot more thoroughly than Go and others.

Rust is as high level and flexible as one wants, just clone everywhere when experimenting and clean it up when you arrive at the final solution.

If it works for you it's great, but for vast majority it's the wrong step forward. Biggest enemies of a startup are time and money. If you have both, great but vast majority have neither!

The sentiment of "our startup became a success because of Rust" is misleading. You're success is not attributed to choosing Rust over something else but rather the effort spent in gaining valuable expertise in years prior and understanding the product it takes to gain customers' attention/money/commitment.

You make all these claims but have not presented any proof apart from your anecdotes.

You equate Rust to "takes more time and money". Neither of those is true (for us) compared to Java and Go. Both of which are languages we initially tried.

But I do agree that the choice of programming language is largely irrelevant to the success of a company. Somehow you seem to think it does, or rather that Rust specifically is the one case where the above is not true.

Here is an opposing opinion from someone who used Rust in a startup but would not pick it again: https://www.propelauth.com/post/i-love-building-a-startup-in...

> Rust is not suitable if the initial team members are not Rust experts

This one is true, the others very much not!

Let's group them in two categories: HR and pace.

> - Rust is not suitable if the startup doesn't have money (Rust devs are very expensive and scarce)

> - Rust is not general hire friendly

Rust developers aren't plenty, but neither are Rust jobs so it's not harder to find candidates than with any other languages. And since we're still in the early-adopters stage, the candidate pool is of much higher quality in average. And people are in fact happy to be able to land a job in a language that they like so much, so they aren't particularly expensive either (a bit like video game developers).

> Rust is not suitable for fast paste startup environment

> Rust is not ideal for iterative and high refactor potential of startup culture

This is very much the opposite! Rust is arguably S-tier when it comes to refactoring, the strong typing making it almost impossible to cause regressions during refactoring, including concurrent and parallel code, this is probably its biggest strength overall and its unparalleled in any language I'm familiar with (that is C#, Java, JS, typescript and Go).

Overall it's a bit awkward to see that you're use two strengths of Rust as if it was liabilities.

You are making very strong assertions, some of which I would like to question/temper/gently push back against.

I am part of a small startup, an SaaS product with 2 Million MAU. Our initial code was in Python and we absolutely struggled with it once we hit scale. Refactoring and adding features were really scary prospects.

The choice of picking Rust was taken after much soul searching and double guessing. We had even ported over one of the services to Golang before we switched to Rust. Most importantly, the choice to use Rust was not mine, it was that of another colleague of mine.

Rust turned out to be the best technical bet we ever took. Of course, since we were in fintech, there was a huge emphasis on correctness which was near impossible to get right in Python.

In Golang, we got the performance we wanted but it just had too many footguns that repeatedly came back to bite us. For context, we have a large number of very stateful and computationally intensive services running. There's a lot of concurrent mutations of shared data we had to deal with. Doing this in Golang was an absolute nightmare. Even after religiously using golangci-lint and fixing issues, we kept running into data race issues.

Rust has never given us these issues. I'd much much rather fight an overzealous compiler pointing out all my bugs at compile time rather than running into a nuanced race related Heisenbug that I need to debug in production, with millions of users' money on the line.

As for developer productivity, devs in our team are desperately pushing to port over _everything_ to Rust because of the peace of mind it gives them, pushing to production. People groan at the prospect of having to update some of the yet to be rewritten Golang code and riot when asked to deal with the legacy Python services.

There's one important caveat I'd like to add to anyone reading this and reaching for Rust. No one else in our team (including me) except one of my colleagues knew Rust when we set off to try Rust. However, we had a big advantage. That one person who had proposed the Rust refactoring had expert level of Rust knowledge.

Not all companies might have this luxury and his expertise may have been what ended up getting over all the initial humps that may have derailed us initially as everyone else was coming to grips with Rust.

> Unfortunately there's a bit of a forced and misleading Rust favoritism the days

This had to be said, well done! It feels like you get bashed for criticizing Rust just a little nowadays.

>- Rust is not suitable for fast paste startup environment

Freudian slip ... copy pasta environment?

I filed that one under "text to speech or spellcheck mishap" after pondering a bit, myself.

Yes, I thought the same after reading the thread again myself; or maybe, autocorrect error.

I’d hire a Python developer any day of the week over either Go/Rust.

Need some data science work done, easy. Need a web server done, easy. Need things to be fast and relatively performant done, easy.

> Python

> fast

This is only true if you are relying mainly on compiled extensions to do the performance-critical work. Unassisted raw python is super slow compared to Go or Rust.

So what? That's how things are structured in Python. It's one of the advantages of the language. Sure it'd be nice to be like Common Lisp, where you can write dynamic/slow and optimised/fast code in the same language, depending on (declare). But Python is the next best thing.

If you want to write slow, dynamic, hacky code in Rust you have to write 'unwrap' and 'clone' all over the place, obscuring the logic.

Is it obscuring the logic to explicitly handle the cases where an item may not exist, or to tell an engineer when they are copying memory? In my opinion it's the opposite.

When you want to write some simple test code to solve a problem, then it is absolutely obscuring the logic to write out all the details of memory management.

Some people in this thread have made the claim that Rust is okay for quick hacky code to work out a solution to a problem, because you can just pepper your code with unwrap and clone and then factor them out later during optimisation. The point I am making is that even if that approach works[0], it heavily obscures your business logic to have it peppered with memory management details when you're just trying to figure out a basic algorithm to solve a problem.

The approach I much prefer is to Plan to Throw One Away[1]. I'd rather work out the solution to my problem in a slow and dynamic language like Python, and then either rewrite it entirely in C or, if possible, just rewrite some inner loop in C and call it from Python.

[0]: I don't think this approach actually works. You can't take a program that has been designed around copying data absolutely everywhere, all over the place, and make it very efficient. You can make it more efficient than it was originally, but I've never seen it done. You can only really work out the right way to manage memory when you know the algorithm, and you can only know the algorithm once you are done. Refactoring from one memory management strategy to another might be possible in theory but is awful in practice, even in Rust.

[1]: https://wiki.c2.com/?PlanToThrowOneAway

I know where you're at because I used to feel the same way. But what if rust was designed to make manual memory management as painless as possible? IE, it's the antithesis of a language like C because when you learn it's syntax all practical memory management is done by basically writing OCAML.

In rust there are two forms of memory management, 1. You write rust. 2. You write unsafe rust.

You never really have to refactor to suite a different style. Infact changing allocators is as simple as running "cargo install".

Rust isn't as bad as people make it out to be but you do have to invest some time to learning it.

But as far as throw one away goes... You can write it in rust, and then slightly adjust when you do things like clone so nothing gets thrown away unless you really botched it the first time you wrote it.

Orders of magnitude slower with few options for improvement except writing in another language in a lot of cases.

Yeah. The presence or absence of compiled extensions is a HUGE factor. Implementation design is also huge.

For example:

Geeqie is an image viewer/manager. It's a fork of the abandoned GQView and is apparently made in the image of Windows 9x-era ACDSee. It's written in C++ and uses GdkPixbuf.

My first prototype for re-creating Geeqie's collection view in PyQt so I could integrate it into a different kind of image management tool was twice as fast at loading thumbnails.

(Something on the order of 20s vs. 10s for loading somewhere around 7000 thumbnails on a 65W TDP dual-core Athlon from 2011.)

I tried quickly benchmarking GdkPixbuf, QImage, Pillow, and the Rust image crate against each other and found that, if anything, GdkPixbuf is a little faster than PyQt... but whatever Geeqie is doing cuts that performance in half.

(And that's with the Python version clamped to single-threaded image loading because I haven't yet written a smart I/O scheduler to allow parallelism on SSDs while avoiding thrashing rotating drives. Experiments with the QThreadPool-limiting line commented out show a speed-up from 10s to roughly 7s, consistent with how much of the overall system CPU capacity was taken up with other things like Firefox at the time.)

Good on you! You have to be product/solution focused not tech glitter!

Jobs to be done and the fastest/cheapest way to get there!

Need something maintainable and safe at run-time, not easy.

I'd also argue that python and performance is totally untrue. Python is probably only second to bitcoin mining in terms of wasted CPU time and global CO2 emissions. Every python programmer that switches to go or rust is the equivalent of removing 15 cars off of the road after all.

Having created and maintained python and go web servers, python never again if I have a choice. Web servers live on concurrency. It is also nice knowing what was passed into a function. Caching in memory is much more approachable in go; making that thread safe in python is a chore.

Oh, and performance. Not even close. Go is easily 20x performant in each case we've migrated.

You're not really talking about Python/Go/Rust developers, but about your preference for Python as a technology.

Also, Python is super slow comparatively and is only fast if it delegates to other languages.

It's a jack of all trades but a master of none. Nothing wrong with that until there is. Then you end up with two languages. This works fine for a while. Until you need 3... Next thing you know half your code was rewritten in other languages and cleaned up. Start realizing ya could have started your projects using different tools.

Not pooping on python it's... Fine. But I am not of the opinion that it's a great choice for all projects because technically "it can" do "anything".

That's actually one of my reasons for writing in Rust whenever possible.

The Rust ecosystem has a broad collection of tooling for using Rust to extend other languages, so there's minimal chance something I wrote in Rust will have to be rewritten to use it in a project in another language.

See https://www.hobofan.com/rust-interop/ and https://areweextendingyet.github.io/

In Python's case, there's also maturin, which aims to make building and publishing Rust-based wheels as easy as Cargo makes doing so for Rust-based crates.

...plus, in the worst case, Rust CLI tools start very quickly, so forking a Rust process for poor man's FFI is more viable, and Serde plus a JSON Schema generator like schemars will streamline microservice-based options.

Reply on news.ycombinator.com