Using Rust at a startup: A cautionary tale

Matt Welsh

Matt Welsh

·

Follow

10 min read

·

Nov 23, 2022

47

Rust is awesome, for certain things. But think twice before picking it up for a startup that needs to move fast.

I hesitated writing this post, because I don’t want to start, or get into, a holy war over programming languages. (Just to get the flame bait out of the way, Visual Basic is the best language ever!) But I’ve had a number of people ask me about my experience with Rust and whether they should pick up Rust for their projects. So, I’d like to share some of the pros and cons that I see of using Rust in a startup setting, where moving fast and scaling teams is really important.

I want to be clear that I am a fan of Rust for certain things. This post isn’t about how Rust is bad as a language or anything of the sort. What I do want to talk about, however, is how using Rust will almost certainly involve a nontrivial productivity hit that could be a major factor if you are trying to move fast. Weigh carefully whether the velocity impact is worth the benefits of the language for your company and product.

Right up front, I should say that Rust is very good at what it’s designed to do, and if your project needs the specific benefits of Rust (a systems language with high performance, super strong typing, no need for garbage collection, etc.) then Rust is a great choice. But I think that Rust is often used in situations where it’s not a great fit, and teams pay the price of Rust’s complexity and overhead without getting much benefit.

My primary experience from Rust comes from working with it for a little more than 2 years at a previous startup. This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices (themselves implemented in a combination of Rust and Python). Rust was used primarily because a couple of the founders of the company were Rust experts. Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well.

As the team and codebase grew, I felt that, over time, we were paying an increasingly heavy tax for continuing to use Rust. Development was sometimes sluggish, launching new features took longer than I would have expected, and the team was feeling a real productivity hit from that early decision to use Rust. Rewriting the code in another language would have, in the long run, made development much more nimble and sped up delivery time, but finding the time for the major rewrite work would have been exceedingly difficult. So we were kind of stuck with Rust unless we decided to bite the bullet and rewrite a large amount of the code.

Rust is supposed to be the best thing since sliced bread, so why was it not working so well for us?

Rust has a huge learning curve.

I’ve worked in dozens of languages in my career, and with few exceptions most modern, procedural languages (C++, Go, Python, Java, etc.) all very similar in terms of their basic concepts. Each language has its differences but usually it’s a matter of learning a few key patterns that differ across languages and then one can be productive pretty quickly.  entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages, and there is a pretty steep learning curve, even for experienced programmers.

Some of those “new” ideas are, of course, present in other languages — especially functional ones — but Rust brings them into a “mainstream” language setting, and hence will be new to many Rust newcomers.

Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below). We started having weekly “learn Rust” sessions for the team to help share knowledge and expertise. This was all a significant drain on the team’s productivity and morale as everyone felt the slow rate of development.

As a comparison point of what it looks like to adopt a new language on a software team, one of my teams at Google was one of the first to switch entirely from C++ to Go, and it took no more than about two weeks before the entire 15-odd-person team was quite comfortably coding in Go for the first time. With Rust, even after months of working daily in the language, most people on the team never felt fully competent. A number of devs told me they were often embarrassed that it was taking longer than they expected for their features to land and that they were spending so long trying to wrap their heads around Rust.

There are other ways to fix the problems that Rust is trying to solve.

As mentioned above, the service we were building was a fairly straightforward CRUD app. The expected load on this service was going to be on the order no more than a few queries per second, max, through the lifetime of this particular system. The service was a frontend to a fairly elaborate data-processing pipeline that could take many hours to run, so the service itself was not expected to be a performance bottleneck. There was no particular concern that a conventional language like Python would have any trouble delivering good performance. There were no special safety or concurrency needs beyond what any web-facing service needs to deal with. The only reason we were using Rust was because the original authors of the system were Rust experts, not because it was an especially good fit for building this kind of service.

Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations — like building code in an OS kernel, or for memory-constrained embedded systems — but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial. I am a pragmatist. I would much rather have my team sink time into debugging the occasional memory leak or type error for code written in, say, Python or Go, than have everyone on the team suffer a 4x productivity hit for using a language designed to avoid these problems entirely.

As I mentioned above, my team at Google built a service, entirely in Go, that over time grew to supporting more than 800 million users and something like 4x the QPS of Google Search at its peak. I can count on one hand the number of times we hit a problem that was caused by Go’s type system or garbage collector in the years building and running this service. Basically, the problems that Rust is designed to avoid can be solved in other ways — by good testing, good linting, good code review, and good monitoring. Of course, not all software projects have this luxury, so I can imagine that Rust may be a good choice in those other situations.

You will have a hard time hiring Rust developers.

We hired a ton of people during my time at this company, but only about two or three of the 60+ people that joined the engineering team had previous experience with Rust. This was not for want of trying to find Rust devs — they just aren’t out there. (By the same token we were hesitant to hire people who only wanted to code in Rust, since I think that’s a bad expectation to set in a startup setting where language and other technology choices need to be made in an agile way.) This paucity of Rust dev talent will change over time, as Rust becomes more mainstream, but building around Rust on the assumption you’ll be able to hire people who already know it seems risky.

Another secondary factor is that using Rust will almost certainly lead to a schism between the people on the team who know Rust and those who don’t. Because we had chosen an “esoteric” programming language for this service, the other engineers in the company who might have otherwise been helpful in building features, debugging production issues, and so forth were largely unable to help because they couldn’t make heads or tails of the Rust codebase. This lack of fungibility in the engineering team can be a real liability when you’re trying to move fast and harness the combined strengths of everyone on the team. In my experience, people generally have little difficulty moving between languages like C++ and Python, but Rust is new enough, and complex enough, that it presents a barrier to people working together.

Libraries and documentation are immature.

This is a problem that (I hope!) will be fixed over time, but compared to, say, Go, Rust’s library and documentation ecosystem are incredibly immature. Now, Go had the benefit that it was developed and supported by an entire dedicated team at Google before it was released to the world, so docs and the libraries were fairly polished. Rust, by comparison, has long felt like a work in progress. The docs for a lot of popular libraries are pretty sparse, and one often needs to read the source code of a given library to understand how to use it. This is bad.

Rust apologists on the team would often say things like “async/await are still really new” and “yeah the docs for that library are lacking” but these shortcomings impacted the team pretty significantly. We made a huge mistake early on by adopting Actix as the web framework for our service, a decision that led to tremendous amounts of pain and suffering as we ran into bugs and issues buried deep in the library that nobody could figure out how to fix. (To be fair, this was a few years ago and maybe things have improved by now.)

Of course, this kind of immaturity is not really specific to Rust, but it does amount to a tax that your team has to pay. No matter how great the core language documentation and tutorials are, if you can’t figure out how to use the libraries, it doesn’t much matter (unless you’re planning to write everything from scratch, of course).

Rust makes roughing out new features very hard.

I don’t know about anyone else, but at least for me, when I’m building a new feature I usually don’t have all the data types, APIs, and other fine details worked out up front. I’m often just farting out code trying to get some basic idea working and checking whether my assumptions about how things should work are more-or-less correct. Doing this in, say, Python is extremely easy, because you can play fast and loose with things like typing and not worry if certain code paths are broken while you rough out your idea. You can go back later and make it all tidy and fix all the type errors and write all the tests.

In Rust, this kind of “draft coding” is very difficult, because the compiler can and will complain about every goddamn thing that does not pass type and lifetime checking — as it is explicitly designed to do. This makes perfect sense when you need to build your final, production-ready implementation, but absolutely sucks when you’re trying to cruft something together to test an idea or get a basic foundation in place. The unimplemented! macro is helpful to a point, but still requires that everything typechecks up and down the stack before you can even compile.

What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again.

What is Rust good at?

There are definitely things I like about Rust, and features from Rust that I’d love to have in other languages. The match syntax is great. The Option, Result, and Error traits are really powerful, and the ? operator is an elegant way of handling errors. Many of these ideas have counterparts in other languages, but Rust’s approach with them is particularly elegant.

I would absolutely use Rust for projects that need a high level of performance and safety and for which I was not terribly worried about the need to rapidly evolve major parts of the code with a whole team that is growing fast. For individual projects, or very small (say, 2–3 person) teams, Rust would likely be just fine. Rust is a great choice for things like kernel modules, firmware, game engines, etc. where performance and safety are paramount, and in situations where it may be hard to do really thorough testing prior to shipping.

Okay, now that I’ve sufficiently pissed off half of the readership of Hacker News, I guess now is as good a time as any to announce the topic of my next article: Why nano is the superior text editor. See you next time!

Rust

MOST RELEVANT

ron

ron

10 months ago

I started a rust firmware project 3 years ago (oreboot) and have several very widely used Go projects (u-root). Both languages are nice in their place. Rust is not the universal language folks claim it is. It has its place, and in that place it is hard to beat. But I still find myself preferring to write Go. Even on bare metal, I now lean to using Tamago and tinygo when I can. Especially with Tamago, it's world-changing to have the full Go runtime in ARM EL3 and RISCV bare metal mode.

A big lesson learned recently was how easy it is to have storage leaks in Rust; another big lesson was fixing a bug in u-root that Rust would not have allowed to happen.

There's a LOT to be said for having concurrency and ipc primitives defined in the language. I've heard incredible horror stories about tokio and file IO ("we could only read the first 4k of a file for a while when we started using tokio"). I've seen 20-line Rust macros consume months of engineer time with no resolution. And, more than I like, I see a lot of Rust code that's not using the language at all -- it's C with Rust syntax. This tells me that fewer people are climbing the learning curve than we think.

Short form: great column, I really agree with you.

128

Hide replies

ron

ron

9 months ago

so one last note, something I just ran into. There's a libc::readlinkat. Suppose you want to just use an fd and an empty string? In C and go, looks like this:

readlinkat(fd, "", ...)

Simple, right?

My first attempt to call it was something like: libc::readlinkat(fd, vec!([0u8]).to_ptr(), ...)

Or something like that. I've gotten in the habit of using vec!() b/c it works well in lots of situations.

Well, that's pretty nasty looking as a replacement for "". And, it was pointed out to me that, while it works on x86_64, the 2nd argument has different type on arm: u8 vs. i8. Further, "you're using the heap with vec!"

I've gotten a bit spoiled with Go escape detection, I don't have to think about this stuff.

The eventual code? libc::readlinkat(fd, [0].to_ptr(), ...)

Rust works out what [0].to_ptr() should be, it's not my problem.

lesson 1: Rust's ability to figure out types is seriously impressive. It's very convenient.

lesson 2: Why should I care about what's on the heap,, vs. what is not? I thought that was the compiler's job

lesson 3: [0].to_ptr() is NOT nicer than "". And that's maybe the most important lesson.

1

The Software Pilgrim

The Software Pilgrim

9 months ago (edited)

Rust not being able to be used in self-referential data structures without kludge is another pimple, I should say.

1

Raymond E Peck III

Raymond E Peck III

10 months ago

I see a lot of Scala code that's not using the language at all - - it's Java with Scala syntax.

1

Hide replies

Jabir Minjibir

Jabir Minjibir

9 months ago

That is the whole point of Scala. To give a very soft landing to people familiar with OOP (especially Java), while giving providing exotic capabilities to more advanced programmers. That is why many people start using it as a better Java from the beginning.

1

The Software Pilgrim

The Software Pilgrim

9 months ago

Java/Kotlin is gradually hollowing out Scala, IMO.

1

Show more replies

Nicolae Mihalache

Nicolae Mihalache

10 months ago

I've been playing with Rust for a few months, so I'm far from being an expert.

Rust seems to me like a tool for craftsmen (and craftswomen). I compare it with woodworking: the best furniture is hand made with fine tuned handplanes and sharp chisels - it requires enormous effort but you get something approaching art.

If you need mass production however, you better turn on the table saw and the mortising machine .

73

Hide replies

Richard Pringle

Richard Pringle

10 months ago

Ageed!

Seems like every "succesful" startup I've seen has code that could NEVER be described as art. Most startups are looking (desperately) for product-market fit and have to pump out features that don't necessarily need to be stable. I heard some advice from YC partners that goes something like, "your product has to solve a problem that's painful enough that users are willing to put up with the bugs and instability". I tend to agree.

There are obviously exceptions to that rule, but it's not the common case!

59

hugozap

hugozap

10 months ago

"the problems that Rust is designed to avoid can be solved in other ways — by good testing, good linting, good code review, and good monitoring"

I don't think this is really true. All of those things won't prevent the memory issues and correctness that the Rust compiler provides. Specially for code that can't afford to fail, those checks are life saving.

52

Hide replies

Richard Pringle

Richard Pringle

10 months ago

I think the claim is that those things are sufficient in the majority of cases. The author states that he would rather one dev burn a day debugging something rather than the cost of slowing down everyone.

I don't think the complaints would be the…...

Read More

10

Richard Kenneth Eng

Richard Kenneth Eng

10 months ago

Thorough testing will eliminate the vast majority of bugs, including those due to memory issues. No programming language can guarantee zero software defects, not even Rust.

25

Tom Ritchford

Tom Ritchford

6 months ago

But Rust doesn't prevent bugs - it prevents safety bugs.

Your code can still generate the wrong answer.

And interpreted languages simply don't have the safety issues that Rust, C and C++ have.

Given we have finite time to develop, it would be better to…...

Read More

15

Pierz Newton-John

Pierz Newton-John

10 months ago

I couldn't agree more. Fantastic language in the right place, but it's overkill for a lot of standard-pattern web development.

67

Hide replies

Alderson

Alderson

9 months ago

🤟

funkyjoose

funkyjoose

10 months ago

"I would much rather have my team sink time into debugging the occasional memory leak or type error for code written in, say, Python or Go, than have everyone on the team suffer a 4x productivity hit for using a language designed to avoid these…...

Read More

54

6 replies

Nathaniel Ford

Nathaniel Ford

9 months ago

Almost every project ever to reach adolescence has felt this pain, and thought this was true, but it kinda isn't. The underlying friction is not a language issue. It's that you are not going to get it right on the first - or fifth - pass. I'm surprised having a 'microservice' architecture didn't shield you from some of this pain, though?

I'm not convinced you aren't comparing against data not in evidence. Sure, building a golang product at Google goes fast and serves '800 million' - but does it, really? That is, it is building on a metric ton of other code, some in Go, some in Python, some in C. Your project alone can't exist at Google without all of that (I know, too, as a Googler, and one who has dealt with obscure goroutine crashes and memory leaks). So many of one's individual problems are abstracted away at a huge company that are felt keenly at a startup.

Similarly, the assertion that the only thing you're protected against is memory safety isn't quite convincing. Strictly typed languages protect against a whole host of bugs. Throwing Python at the wall is great (at least, *I* think it's great!), but playing fast and loose with types generates a class of bugs that isn't trivial to find. 'A single dev day' per bug is, I think, wildly optimistic. Just as the fungibility between a C++ and Python developer is wildly optimistic. I'm sure your average C++ developer will write fine code in Python, but there is a reverse case there...

Finally, I find it odd that you say it's hard to find people who can code in rust, and then turn around and say you exclude those who *only* want to code in Rust - on the basis that you might need to change language. But you also underscored changing language wasn't an option. Putting specific language preference ahead of algorithmic skill, critical reasoning, communication and a host of other items seems odd for both management *and* potential employees.

While Rust deals with problems that have other solutions, that's like saying you might not need a car because, well, horses. I, for one, am not convinced the crux of your problem here lay in Rust. But, y'know, I'm in the cheap seats!

41

Hide replies

Mike Ver Hagen

Mike Ver Hagen

6 months ago (edited)

I like the generosity of bringing those facts in to back up your perspective. For sure, the OP probably had to leave out some pressure vectors that are unique to their exact situation, yet I do appreciate that the OP reminded us just how much the exact terrain of the app’s world grants it some leeway that isn’t otherwise good. In this way we avoid applying what are generally good principles where they don’t help.

That said, yes the OP presents a combination of factors that don’t add up, as presented, so maybe some of that is falling back to references to sound general principles as the OP strives to wander into generalized advice that doesn’t apply to them for that app.

5

Alderson

Alderson

9 months ago

good 🤘!!

1

Adrian Coutsoftides

Adrian Coutsoftides

10 months ago

While I agree with the statements in the article, I can’t help but feel it’s a bit outdated when compared to all the progress made in Rust 1.65. Compiler errors have come along significantly and the introduction of GATs (Generic Associated Types) into the stable release has opened the door for incredibly simple and elegant APIs.

I would argue that there are fewer Rust crates for any given use case because fewer are needed. If there are 50 JS crates just to manage timestamps, 43 will be either poorly written, have a bad devEx or extremely unoptimised. In Rust, theres only a limited number of ways to accomplish the same task, and the design philosophy behind the standard library (“could not be faster if you wrote it yourself”) means that typically, if someone write a crate to manage timestamps, it’s probably already pretty good and will stay that way! Especially given Rust’s backwards compatibility guarantees (unlike JS! or god forbid python 2 vs python 3)

21

Hide replies

Alderson

Alderson

9 months ago

😎

Tarun Elankath

Tarun Elankath

10 months ago

As more people begun to seriously use Rust, people will begin to rant about it more as its significant shortcomings are discovered. It will no longer be the "best loved" PL in the polls.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses".

44

Yacob Cohen-Arazi

Yacob Cohen-Arazi

10 months ago

Thanks for sharing it. I can understand everything that you said here. I'm myself playing with Rust for the past 1+ year and can relate to this experience.

11

Hide replies

Alderson

Alderson

9 months ago

agree

H Trahe

H Trahe

10 months ago

I get our point, I am kind of moving from python to rust and love it, nevertheless I know very well how much better the productivity and dev resources for e.g. python is.

So, but why don't you do the python plugin from the rust code, you want to be more productive, and then go on with python?

You still can later on move parts from the python code to the rust python module...

Writing python modules in rust is so easily done.

I'd always do the rust lib, and on top of that WASM / python module or static libs...

Where exactly do you feel locked up into rust?

11

Hide replies

Richard Kenneth Eng

Richard Kenneth Eng

10 months ago

Developers do this all the time. Users of Python, Java, Smalltalk, etc. regularly drop down into C/C++ for performance-critical pieces of code.

However, there are many software projects where performance is not a critical consideration. These projects may settle on one language and be done with it. No need to complicate matters with multiple languages.

2

Sertorbe

Sertorbe

10 months ago

100% right, Rust is way too strict when what you want is you to try something out, it makes me sad though that F#/OCaml isn't more mainstream.

8

Yue Zhou

Yue Zhou

10 months ago

Like you said, it is not the language issue by itself. It is the people resource problem. When technology involves faster. More resource will be trained on the application level rather than lower system level. Which make that learning curve become challenge for most of engineers. Simply just missing that knowledge. And the ecosystem is not splendid like others eg. javascript. Where people can find 50+ library do the same thing. So, they can just use it without write one for themselves. I think right tool for the right job is ideal. However, startup doesn't the luxury. So often it becomes use whatever resource you are available to make the ball rolling.

10

Glenn A Miller

Glenn A Miller

9 months ago

I converted a Laravel (Php) API to a Rust API using actix-web. Yes, it was painful (at first). The results, however, were excellent. The Rust API is fast, safe, containerized, and scaleable -- everything Laravel wasn't.

The next API I tackle will be much easier now that I have the hard-earned knowledge.

35

Hide replies

Alexander Staroselsky

Alexander Staroselsky

9 months ago

To play devils advocate, can you not containerize and scale Laravel or any other web framework?

2

1 reply

Alderson

Alderson

9 months ago

😃

1

Isaac

Isaac

10 months ago

The learning curve part may be ameliorated as more people actually learn it. Everything else you’ve said sounds spot-on, though.

11

Hide replies

Richard Kenneth Eng

Richard Kenneth Eng

10 months ago

That's not how it works. The difficulty of learning a language is not related to the number of users in the community.

C++ is a wickedly difficult language to learn for most people. Even if you have a million C++ programmers, this fact won't change.

1

Hide replies

Isaac

Isaac

10 months ago

By the “the learning curve part” I meant the fact that the learning curve itself will become less of an issue after more people have learned it. (Obviously, I didn’t mean the curve itself would change for any given individual).

So to take your example, people already do have startups using C++ (admittedly few, but there are other reasons C++ is difficult beyond just the initial curve that I’d argue Rust isn’t).

4

Alderson

Alderson

9 months ago

good

Romain Kelifa

Romain Kelifa

10 months ago

As much as I love Rust, there's sheer truths in your sayings. Cheers Matt, I really enjoyed reading from you !

7

Hide replies

Alderson

Alderson

9 months ago

correct 😎!

Yuri Budilov

Yuri Budilov

9 months ago

learning Rust borrowing and lifetimes is not hard, here is one short video that will help: https://www.youtube.com/watch?v=TJTDTyNdJdY

7

Matthew Willox

Matthew Willox

9 months ago

And vice versa! There are almost no Rust positions.

There aren't any entry-level positions for Rust either, so the talent pool never grows. Many Rust developers are self-made through their own or open-source projects. There is nothing wrong with that, but it's achingly slow.

It's sort of the old joke where the ONE job is looking for a person with X years of experience, but the technology has only existed for X-1 years.

I like using it. But the number of opportunities reminds me of WebGL in ~2012. Serious firepower that no one needed.

13

Hide replies

Mike Ver Hagen

Mike Ver Hagen

6 months ago

I have seen those ads

Alderson

Alderson

9 months ago

I agree 👌

Raymond E Peck III

Raymond E Peck III

10 months ago

cat old_post.txt | sed s/Scala/Rust/g > new_post.txt

4

Hide replies

Alderson

Alderson

9 months ago

good 😎

Srikanth Kandarp

Srikanth Kandarp

10 months ago

I agree dude !!

Rust is great but hard to build stuff on if you know your business logic and you are least dependent on crates then its great to build. No official gRPC support for rust and freaking "tokio" doesn't make sense at all (Why not just make it as a default library my rust analyser cries for it ) had a really hard time learning rust was actually building a CLI for my side project ( later after a week of writing rust code switched to Go when the project was almost done). Go makes everybody's live easier. I understand your pain as a fellow developer, It was a nice reading.

5

Thomas Shallenberger

Thomas Shallenberger

9 months ago

While I'm glad you shared this experience, I can't help but wonder what on earth was going through the teams minds during this decision.

You chose Rust for a CRUD app handling a handful of queries/second. As someone who was in a similar position, this was your first critical mistake. At the prototyping/design stage in a startup you should generally lean towards widely supported, team familiar languages/frameworks, with well established conventions and community, and an emphasis on deployability/monitoring/troubleshooting.

Still, this was a really good exercise in attempting to put a square peg through a round hole.

For future readers, Rails/Laravel/NestJS should be some of the only entries in your pool, unless your initial team members were coming from a Java/.Net background. Spring and DotnetCore are also viable backends. In the case of microservices, Go can also be considered. And in some cases, serverless is the way to go, if latency isn't too much of a concern.

3

Hide replies

Alderson

Alderson

9 months ago

🤘

Adam Fisher / fisher king (@therightstuff)

Adam Fisher / fisher king (@therightstuff)

10 months ago

Great article! This is one of the most important principles I've learned over the years - being able to put together a team that can do the work effectively is integral to a team's success, and often it comes down to making sure they're all comfortable with the language and framework choices.

I once worked on a codebase that was almost entirely PHP with a team that wasn't interested in any other languages, and was left picking up the pieces when a well-written piece of Python code fell apart - the author of the code had left the team long before and it had been working so well nobody even knew of its existence... as much as I don't enjoy working in PHP myself, it seemed pretty obvious that forcing a group of PHP devs who were anti-everything-else to maintain a Python project wasn't the right choice for the business.

3

Hide replies

Alderson

Alderson

9 months ago

🤘

Grigori Fursin

Grigori Fursin

10 months ago

Thank you for a great article, Matt! Startups need agility and a quick prototyping cycle that is tricky to achieve with Rust indeed ;) ...

3

Hide replies

Alderson

Alderson

9 months ago

😎

Abraham Samma

Abraham Samma

10 months ago

I couldn't agree more wrt picking up Go vs Rust. I'm learning Go and Rust in parallel at the moment and I can tell you it's like night and day. Go is elegant in its simplicity and easy learning curve. Rust is elegant in its design to avoid a good deal of common mistakes in programming, but at the cost of ease of learning.

3

Sayan Bhattacharyya

Sayan Bhattacharyya

3 months ago

In Rust, this kind of “draft coding” is very difficult, because the compiler can and will complain about every goddamn thing that does not pass type and lifetime checking — as it is explicitly designed to do.

How about this as a solution? https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

2

Ben Winters

Ben Winters

8 months ago

I’m a mobile developer with significant experience in Swift and React Native (TypeScript). Is there a good, type-safe server-side language and ecosystem for SaaS startups? Is TypeScript + Node/Express the best available?

2

Alain Chenier

Alain Chenier

9 months ago

Finally a serious, balanced, well thought-out, reasonable article about Rust.

Most Rust articles on Medium are written by inexperienced fanbois just wishing to put it on their CV and linking to a Medium article as 'proof' of their mastery, using the language in ways that would be just as suitable for C or C++ -- that is, not really using Rust features at all.

And, an extra clap for not using the word 'blazing'.

2

Dayne Mentier

Dayne Mentier

9 months ago

This reminds me of a similar debate that was had at a prior consulting firm I worked for. Except then it was scala Vs Java.

2

1 reply

Pranavhchandane

Pranavhchandane

9 months ago

Yo, I'm pissed off. How can nano be superior text editor?

2

applied.math.coding

applied.math.coding

9 months ago

Nice and true post! It is all about choosing the right language for the right task. In what airplane do you prefer to sit, in one that is built with Rust, or one that is built with JavaScript?

6

ksn

ksn

9 months ago

just to get the flame bait out of the way, Visual Basic is the best language ever! - Lovely disclaimer :)

2

1 reply

Blake McBride

Blake McBride

9 months ago

Thanks for the wonderful article.

I am the author of the Dynace OO extesion to the C language. (https://github.com/blakemcbride/Dynace) In a sense, it is a new language. Dynace is being used in commercial applications.

Unlike Rust, Dynace is very simple to learn and use, and it offers many advantages over straight C. In spite of this, however, I have experiences a great deal of resistance to the language.

I have tried to be open-minded about feedback I have received but after analysis of the feedback, I come to the conclusion that there really was one main problem.

Dynace is not a popular language. If you have X years experience with Dynace it doesn't help you get your next job. Programmers want to use languages that are popular for no reason other than to have a wide choice of job opportunities.

So, language popularity is extremely important, and it takes many years and a lot of luck to overcome.

In spite of the chicken and egg problem, chickens do exist!

2

Hide replies

Alderson

Alderson

9 months ago

good 😎

Antonio Cheong

Antonio Cheong

10 months ago

I tried to learn Rust a while ago. I gave up once I started trying to find the appropriate libraries. I am thankful I learnt Go instead.

8

Hide replies

aid

aid

9 months ago

Should you ever try Rust again; check out the following link which contains a curated list of many of Rust’s go-to crates: https://blessed.rs/crates

1

BC

BC

5 months ago

I think there are three main points here

Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations

OOF, I couldn't agree less. Safety means fewer crazy weird bugs that bite you when something changes after the original code authors are gone and nobody can figure it out. I've seen huge projects just junked for reasons like this.

Rust has a huge learning curve.

That's because it has introduced some radically new concepts to solve problems (memory management) that other languages solve in other ways (garbage collection). This might really take off, because handling memory management at compile time is a great idea. But, in the meantime, it sure does make a poor business case for using Rust in a startup.

Rust makes roughing out new features very hard.

Maybe. I kind of miss having an interpreter to play along with, the instant feedback from the compiler in my IDE is really good. But I haven't tried it on any large code bases, yet.

2

Tom Ritchford

Tom Ritchford

6 months ago

No, Rust has decided that safety and speed are more important than developer productivity.

Python or Javascript are "safe" in the sense that Rust is because you literally cannot address memory locations directly.

However, compiled languages will typically be between 3 and 30 times faster than interpreted language.

I can't imagine why your team did this to themselves (sorry, I know it wasn't your fault).

I enjoy programming in compiled languages, but the reason to do this is to get the blazing speed at the end: my feature productivity is halved. And more, it is considerably harder to find C++ or rust programmers than it is to find Python or JS programmers; and a mediocre programmer in a compiled language can do a lot more damage than a mediocre programmer in an interpreted language.

Good luck!

1

Alderson

Alderson

9 months ago

As awaited, an impressive effort. I genuinely appreciate your meticulous work

1

Denis Bredelet

Denis Bredelet

9 months ago

I applaud the mention of nano. Ha ha.

Rust is young, over time most of these troubles will go away. It is important the language focuses on being accessible though, without compromising on its strengths.

Maybe some good libraries will help bridge that gap.

1

1 reply

The Software Pilgrim

The Software Pilgrim

9 months ago

IMOH, this sounds more like premature optimization of constantly being interrupted by the compiler. I hit a similar frustrations with this after playing with it for 2-3 weeks.

In fact, I would be more productively with Golang or even C++.

A possible solution might be for Rust compiler to have a borrower check turn off or set to warning only during development and then set to strict during build for production deployment.

The other thing I found insanely confusing(at least to me) is Crates naming and layout conventions.

In Java or Golang its quite simple and obvious without any ambiquity.

Great article , btw!

7

Alexander Günsche

Alexander Günsche

9 months ago (edited)

Fully concur! I do love Rust; more for things like WebAssembly though. But, just like any other tool, it has its time and place. If you use it as your golden hammer, you will pay the price.

By the way, on shouldn't have to spend every other paragraph apologising for their opinion, especially when there is a solid reasoning behind it. Haters gonna hate, so what.

1

Jason Bell

Jason Bell

10 months ago

Emacs man! Emacs! :)

1

Mr Nameko

Mr Nameko

7 days ago

TypeScript + NodeJs [NestJs]:

https://nestjs.com

Is a great set up for REST API apps. Very easy to use with a variety of DBs. Fantastic community support and documentation. Huge amount of 3rd Party Libraries via NPM etc. And pretty much every Dev, knows how to use Javascript.

So, it is easy to find Devs.

And I am saying all this, with my primary server-side language, being Coldfusion [.cfm]. NodeJs is definitely a fail safe choice, despite its single threaded nature. 🙂

Mr Nameko

Mr Nameko

7 days ago (edited)

TypeScript + NodeJs [NestJs], is a great set up for REST API apps. Very easy to use with a variety of DBs. Fantastic community support and documentation. Huge amount of 3rd Party Libraries via NPM etc. And pretty much every Dev, knows how to use Javascript.

So, it is easy to find Devs.

And I am saying all this, with my primary server-side language, being Coldfusion [.cfm]. NodeJs is definitely a fail safe choice, despite its single threaded nature. 🙂

Pavel Buranov

Pavel Buranov

10 days ago

I honestly don't get the productivity arguments. Cargo check shows me an error instantly, I fix it and get to dealing with actual program logic. On the contrary I have to relaunch a python app, check into the relevant section of the app, click the button only to then find out I misspelled a keyword or variable. Then there is concurrency, which is fearless in Rust, while in other languages you have to kinda write something that feels right. The author brings up such "complicated" concepts like lifetimes, ownership and the borrow checker. By his own admission it's hard for him to grasp concepts like "where the variable goes" and "how much of the program will use it". Ok then, even if we admit that there's a ton of pythoners who don't really know coding and that programming has to be accessible to them, even like this they already filled up stack overflow and 50000 other forums with their basic questions, any problem is one google away.

Rust has actual issues, like irregular syntax and its static compilation/development model (not the typing! HM type systems are a blessing). Rust also isn't well suited for symbolic computation. This is the real limit of rust: dynamic symbolic computation. In any other cases it's just as good of a generic programming language as other languages, except you very rarely need to manually manage resources (which you have to do in C# too) and you are forced to use Option<T> when the return value might be null. So what's the issue? The issue is that programmers try to do insane things and hack piles of code onto each other instead of taking a systematic approach encouraged by the language. The pythonic «write whatever now and fix it later» doesn't work with rust, which deeply saddens the coders of shit software, oh well.

Luke Wilson

Luke Wilson

3 months ago

Awesome article. I’ve thought about rust in the past but I would certainly pick Go for maintainability any day.

Chris Hornberger

Chris Hornberger

6 months ago

There’s a reason it’s not mainstream. Yet. There’s a reason to work within the mainstream. Blaze your own trails later when you have F-U money.

Tom Ritchford

Tom Ritchford

6 months ago

But we have that in Python now!

Rabona Max

Rabona Max

9 months ago

If we are talking about startups, then I advise you https://digitalce.com/. There is a lot of competition now, but they will help you

Richard Kenneth Eng

Richard Kenneth Eng

10 months ago

Prof. Dave Mason, Chair of Computer Science at Toronto Metropolitan University, only uses two programming languages these days: Smalltalk and Rust.

Smalltalk is chosen for situations where productivity and speed of development are crucial. Rust is chosen for situations where performance and memory safety are crucial.