22 ms·

Why Rust is a great choice for startups

175 points by stevepeg 4y ago

WuxiFingerHold 4y ago
Many good points that I'm able to relate to. However, the post is too exaggerated, e.g.: > The amount of debugging required for Rust projects is an order of magnitude less than I’ve seen anywhere else. Sorry, that's just nonsense. I've done a large amount of .NET and Java and a good amount of Go and Rust. Stating that debugging effort in other languages is at least 10 time (which is an order of magnitude) higher is a huge exaggeration. Also, one absolute critical point is missing: The reliability of the ecosystem. That's the biggest weakness of Rust. Rust's NPM like ecosystem is just brittle and dangerous. There're enough examples of widely used crates that caused issues due to maintenance or that had malicious code. For all the undeniable benefits Rust brings, this single big disadvantage makes it actually not the best choice for startups. I sometime wish Rust and Go had a baby ...
- dijit 4y ago
  yeah, I love Rust but this rings hollow for me too. debugging python is a pleasure compared to Rust, and it makes sense that this is the case... Rust itself performs well because of the compilation stage to native code, but it gets harder to step through because of that.
jedisct1 4y ago
What matters for a startup is time to market. So, go with a boring technology that the existing team is already familiar with, and that fits your use case. There's nothing wrong with PHP, Python, Go, JavaScript or Java. Even modern "no code" tools such as Bubble can get a first version done in a minimum amount of time.
- eventhorizonpl 4y ago
  Time to market is important if you have an idea that replicates existing solutions. Or is easy to replicate by others.
ecmascript 4y ago
Two days ago I started to rewrite an api I made years ago in Nuxt3. The day after I finished it. Sure, I know javascript and I could reuse a small bit of code but if I would imagine switching to rust it would probably take me at least a month mostly because I don't know much about it. The times I've actually tried Rust out it's been a struggle, to say the least, and I am a programmer with over 10 years of experience. Ok if you are the VC-funded kind of startup that needs developer hype and can afford to hire people. But if you are a bootstrapped startup I barely can think of worse languages than Rust to start with unless you've extensive experience in it. The crates available seems sparse and of low quality. Getting back to my example, I would have to rewrite a parser from scratch most likely and only that would probably take me quite some time while in node I can just npm install it which have worked flawlessly for years. Unless you're in a market that requires the service or product to utilize every cent of performance or is in embedded industry I think Rust is a terrible choice for a startup.
fkrst 4y ago
When you're building a product you definitely want to spend your time fucking around with all the object lifetime concepts of Rust or the subtleties of its compiler... Just use any language with high-level features like a garbage collector, bignums by default and message passing concurrency (Racket, Erlang, whatever), and you will be more productive, and actually have more "fearless" / safe programming than you will ever have using Rust.
longrod 4y ago
The technical aspect of a startup hardly even matters as long as you get the job done. The first thing to understand before you start a startup is that it doesn't matter how much you love programming. It doesn't matter how beautiful your code is or how much time you spent writing it. What matters is marketing. You can use Rust or JavaScript or whatever language you want but if you want to be successful, you will spend more time thinking about how to market. Customers don't care what language a product is written in (unless it's a developer facing product). Customers care about getting the job done. I know the argument here is that Rust offers long term stability but if you are a startup, you will be changing the product so rapidly and adding more and more features, the sheer level of growth will make your product unstable. I am not against someone using Rust for their new startup IF they are already comfortable in it and know the ins and outs of Rust. Rust is way more complex than JS. The learning curve is considerably steeper. And that matters because if you use a great language and write it poorly, no matter what guarantees it offers, you won't get a better product than if you wrote it in a language you understood well. So if you are a startup, don't think about the language. Think about what will sell, how you will sell etc. If you can't sell it, it doesn't matter if you wrote it in a particular fancy language. The technical aspects of a product are rarely a sales increasing factor.
ahallock 4y ago
Unless Rust itself solves a problem specific to your startup, I'm not so sure. I like Rust, but the language seems very complex compared with Ruby or JS, so your talent pool will be considerably smaller and probably more expensive.
jcpst 4y ago
I’ve been using Rust as a hobbyist since 2015. I see what’s going on in the community, attend a meetup, and work on open source projects (mostly my own). I’m starting a side project, and after much consideration, I went with F# and AspNetCore. The maturity of the framework and solutions for web is hard to ignore. And then F# gives me a lot of what I like about Rust: union types, pattern matching, avoiding null… With less syntax, and without reasoning about lifetimes, which still takes me more effort than I would like. Don’t get me wrong, I love Rust. In this case, I was able to build out a web server a lot faster, while still getting _most_ of what I love about Rust.
- runevault 4y ago
  Are you using ASP.Net Core straight up or through something like Giraffe? Also are you using JS or Fable/etc to handle the front end? The F# web ecosystem is something that I've done light research on but haven't done a real project with yet, but still incredibly curious about it.
  - jcpst 4y ago
    I'm using Giraffe. Building everything in the request pipeline as composable handlers has been nice. For the front end, I have decided to do server-rendered pages, using Giraffe.ViewEngine. So the source for the HTML is all F# code too. For interactivity and updates without a full page reload, I am using htmx. This has been so nice that I feel “done” with SPAs as the default choice for a web UI. 99% of the JS I need is encapsulated in a library. If I ever need more, I can just incrementally adopt Vue or something similar on a page that needs it and go from there.
    - runevault 4y ago
      That sounds wonderful. I'll keep your thoughts in mind if I get back to F# for something to try out.
Wavelets 4y ago
Is there a mature, production ready library for deploying deep neural networks in Rust? Searches end up being all over the place and end with a library that hasn’t been maintained in years.
taylodl 4y ago
Rust is not a great choice for startups! In fact, NO LANGUAGE is a great choice for startups! You don't choose languages depending on whether you're a startup! You choose languages based of the problem you're trying to solve, how fit the language is for solving that particular problem, the ecosystem supporting that language, and the availability of developers who are experienced with that language. Rust just may be the best choice for your startup, but it's not necessarily the best choice for all startups - in fact it's probably not the best choice for most startups! That doesn't mean there's anything wrong with Rust, it just means Rust isn't the right tool for the job most startups are trying to tackle. If it is the right tool then absolutely you should use it!
- StefanHamminga 4y ago
  I've seen this in action: A startup I did consulting work for had a "genius" who convinced management that everything should be written in Haskell. As a consequence building a team was painfully slow, so slow that some guy in a weekend recreated in node.js what their 15 people team had painstaking put together in 3 months. Turns out doing a web service with tools meant for it was better than "everything should be functional".
  - omegalulw 4y ago
    I would love to hear that argument for Haskell for web dev.
  - taylodl 4y ago
    Unpopular opinion - Haskell was intended for research and learning, not so much for mainstream production code. I'm not saying you can't use Haskell for that purpose, but you should think long and hard before doing so. If the answer is still yes then go back and make sure you've thought long enough and hard enough! :)
    - JoelMcCracken 4y ago
      Haskell is fine for production code. You just need to know what you're doing, and not go crazy with abstraction.
torton 4y ago
I remember seeing probably the exact same discussion on HN maybe five years back s/Rust/Go. The more things change, the more they stay the same.
wly_cdgr 4y ago
Startups should hire the kind of people who are experts at both C++ and Javascript, then ask them to choose the right tools and languages for the task at hand. Which I am sure may end up sometimes including Rust.
labrador 4y ago
If I were the author I would retitle the article "Why Rust might be a great choice for your startup"
kokizzu2 4y ago
nsonha 4y ago
This is hilarious, it is a great choice for start ups, to do what? How is it that what you do isn't the first thing that affect your choice of technology, but the "type of company" you are is?
ncmncm 4y ago
Rust is a great choice for startups because most startups fold and so will not need to try to find people who know how to maintain it.
- eventhorizonpl 4y ago
  If you build a startup around bad ideas realized in crappy languages, than it's a great recipe for a disaster. If you have a good idea and you hire seasoned developers who can realize this idea you are at least on the good path.
  - ncmncm 4y ago
    Necessary, but not sufficient. Almost all the startups with bad implementations will fold. Almost all the startups with good implementations will fold.
    - quickthrower2 4y ago
      I worked for a company that used some crappy 2000s 4GL nocode tool to get started. Didn’t hurt them financially at all.
  - rwalle 4y ago
    Zuckerberg something...
- sshine 4y ago
  I would argue that Rust is a great choice for startups exactly because you can find people who will either take a pay cut or work in a hectic environment, just so they can use Rust. Rust has been on top of everyone's "want to learn" list for half a decade, and it feels quite mature.
  - deterministic 4y ago
    Nope not even close to being true. I am way more interested in more advanced languages (using dependent types).
chungus 4y ago
>(...) despite my experience and best intentions, I was in fact making mistakes with C. Subtle leaks, use-after-free,(...) Rust made it very clear that I was not the programmer I thought I was. This really resonated with me. I feel a lot more confident writing code in Rust than say in C or Java. However, in my opinion, it also comes with a downside: These days, whenever I use a 'more forgiving' programming language I find myself being much more paranoid of the code that I write. Even after double checking everything I still miss the memory guarantees that Rust brings, and end up spending a lot of time making sure things are behaving the way they should.
- eventhorizonpl 4y ago
  Do you pine for the nice days of C/C++, when men were men and spend hours on debugging segmentation faults?
  - p0nce 4y ago
    This is quite rare in C++ since C++11.
  - mbrodersen 4y ago
    I am a professional C++ programmer and I can’t even remember the last time I had a segfault. I also haven’t had a bug in production the last 5 years. But YMMV of course.
  - farseer 4y ago
    Sticking to STL in C++ and avoiding pointers unless really necessary will significantly cut down on segmentation faults.
  - ncmncm 4y ago
    It has been many years since I spent "hours debugging" a segfault. But I use C++, not C. (That said, I coded C from 2008 to 2012, and spent no hours on segfaults then, either.)
  - papito 4y ago
    Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters. Scala has the same problem. Stop writing your own DSLs!
ThePhysicist 4y ago
I started my first Rust project a month ago after working for years in Golang and before that Python (and before that Perl, C/C++ and Turbo Pascal). I really like the whole experience but I'm not sure if I'd recommend writing all your backend code in Rust as a startup. Rust definitely provides a pleasant experience and is very powerful. If you can stick to the standard library I think Rust is great, though the package ecosystem is still lacking in many respects and most packages seem immature and quite limited. So if you plan to build something that has sizeable external dependencies plan some time to either write that yourself or to spend a lot of time debugging and vetting external packages, many of which are maintained as side projects by single developers. Documentation often also seems to be subpar as compared to e.g. Python. I suppose that's due to the auto-generation of documentation which seems to lead to people mostly writing what I'd refer to as API documentation with very few tutorials. So is Rust worth it for a startup? Not so sure. I recently picked up Python again to write a simple REST API, and the process is just so much faster and (for me) enjoyable because of the "ad hocness" of the language and of course the great existing tooling around it (I still have to find an ORM as powerful as SQLAlchemy in Rust or Golang). And let's be honest it's also possible to write great scalable services in Python (or Ruby, or Javascript), as many scaleups still use these technologies. Onboarding of developers might be another issue: Yeah, everyone wants to be a Rust programmer, but for people that have little experience with systems programming the learning curve is quite steep, so you'll limit your candidate pool quite a bit and will need more time for hiring.
- drogus 4y ago
  > I recently picked up Python again to write a simple REST API, and the process is just so much faster For me it's much more important how will it work in the next few years, not how quickly you can write it. If I could, I would use Rust for pretty much everything just because I don't like getting paged in the middle of the night.
  - mikevm 4y ago
    I agree. This typing velocity argument is really weak. It may be faster to start, but talk to me once the project reaches 10K+ lines of code and we'll see how you fare with your scripting language.
lionside 4y ago
I’ve been working on an OS project to help people get on this bandwagon: create-rust-app [1]. The folks over at shuttle.rs also wrote a blogpost around a similar topic which was a very interesting read as a rust developer. [2] [1] https://github.com/Wulf/create-rust-app https://github.com/Wulf/create-rust-app [2] https://www.shuttle.rs/blog/2021/10/08/building-a-startup-with-rust https://www.shuttle.rs/blog/2021/10/08/building-a-startup-wi...
- chungus 4y ago
  This is great, it looks like it does a lot already and I really like the plugin system. I think you should definitely get the documentation written up. One thing, the "Walkthrough" video in your README is unwatchable, because it displays very small. I had to download it to be able to watch it properly.
T3RMINATED 4y ago
kasperni 4y ago
> it’s still orders of magnitude faster than Python, Ruby, Javascript and Java. Unsubstantiated claims like this, just makes me stop reading.
- igouy 4y ago
  What's your ballpark guestimate? aot language implementation based-on llvm, guess something like clang? Then guess it depends which Python and Ruby language implementations, what exactly we need to do and how much we can call C libs :-) https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html#chart-fastest https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- eventhorizonpl 4y ago
  https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
  - vegai_ 4y ago
    In these benchmarks Java is not that far from Rust's performance. In fact, it hits #1 in some tests.
- eventhorizonpl 4y ago
  https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/pidigits.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- lenkite 4y ago
  And also false claims of "orders of magnitude", esp wrt Java https://deepu.tech/concurrency-in-modern-languages-final/ https://deepu.tech/concurrency-in-modern-languages-final/
farseer 4y ago
>>Why Rust is a great choice for startups No mention of the type of problem the startup is trying to solve. A performance hungry desktop app? A web based SAS? Not all language choices are equal.
- stevepeg 4y ago
  Author here: didn't expect this to get on the front page, some kind of life goal achieved I guess. Here's a link to our Show HN from a week ago: https://news.ycombinator.com/item?id=31630604 https://news.ycombinator.com/item?id=31630604
  - dannersy 4y ago
    I may have significant input on a green field project, which is generically a web use case, but performance will be a factor. I'm interested in pitching it, as I know other teammates will be be, but none of us are particularly skilled in writing Rust. For instance, the largest thing I've written is still half baked which happens to be a basic REST API for a personal project. I have only begun to see some of the benefits you explain in your article. I'm curious if you feel that it's necessary to have an "expert" or experienced Rust developer on the team for it to be the technology of choice; or do you think Rust has sufficient guard rails for a team with basic understanding of mature packages and overall senior experience? The reason I ask is because I've known several teams pick up Go because of their interest in it, ultimately being happy with the choice, but have strong opinions about their initial implementations. Perhaps that's just the nature of software, but I would love your opinion.
    - stevepeg 4y ago
      No worries, here's my opinion (lots of lang-war stuff, so note "opinion"): I would say that it depends on your comfort with async code in Rust since much of the web ecosystem is built that way. If you're comfortable writing async Rust then go for it, the guard rails are there. People complain (especially here) but it's fine. Our entire web backend and our scheduler applications are overwhelmingly async. We have not hit the weird stuff you read about with lifetimes even once. However, it does expect you to know how it works. You need to understand what the async runtime does otherwise it will add friction. If you're not yet proficient with this part of Rust then you will benefit from having an "expert" on the team as you say, since they can guide the rest. Our team were all experienced in Rust already when hired so we didn't hit this. If you're uncomfortable then simply choose the language your team already knows. That's the pragmatic choice.
235235235235 4y ago
What does Rust offer over modern C++ with smart pointers and RAII?
- deleted 4y ago
  [deleted]
- unixhero 4y ago
  Rustian Safety Rustian Garbage collection
  - ur-whale 4y ago
    > Rustian Garbage collection Genuinely curious here: the Java GC (still in 2022) is often a major headache in production wrt latency when system is under load. How's the Rust GC in that regard?
    - tialaramex 4y ago
      Rust isn't a Garbage Collected language. However, because Rust cares about who owns things, it gets to have all the benefits you get with say RAII types in C++ except seamlessly (in safe Rust anyway). Imagine you make a Doodad, like you call a constructor for it maybe, or there's some call somewhere that gives you a Doodad. OK. Now you put the Doodad in a Hashtable of Doodads. Well, is that still your Doodad? Are you responsible for ensuring it is properly cleaned up at some point? Or does the Hashtable now take responsibility for it? If somebody looks in the Hashtable, do they get back the Doodad? Now is it no longer the Hashtable's responsibility? Rust systematically has answers to all these questions, which permeates the language and its ethos, in exchange it gets to have really nice properties.
    - kaba0 4y ago
      > the Java GC (still in 2022) is often a major headache in production wrt latency when system is under load. Can you say a bit more about your experience regarding this? In my experience, it is either not due to GC, because it is really hard to make the G1 GC miss its target pause time, or there is an easily debuggable function creating way too much object, and the fix is often trivial. Like, the JVM has the state-of-the art GC implementations.
jasfi 4y ago
What about Nim? An in-progress full-stack framework for Nim: https://github.com/jfilby/nexus https://github.com/jfilby/nexus
- deleted 4y ago
  [deleted]
Zababa 4y ago
> But you really don’t need much more engineer time than using another language, and you get the lower overhead when you actually run your program. That seems like an extraordinary claim to me. That would imply that when picking something like Django, Rails or Spring over Rust, there's no difference in engineer time taken to add a new feature.
matsemann 4y ago
I guess it works for a fully remote company, as you have a large pool of possible candidates. But in my area, I'd say it would be easiest to recruit using java. Next python or node/js, but still a vastly smaller group compared to java devs.
- mwcampbell 4y ago
  That sounds to me like a strong argument for any new startups founded by people in your area being remote-first.
  - matsemann 4y ago
    That's a good point, but I'm actually not so sure about it. I think that perhaps most startups need a tighter group and alignment than what remote can provide. While I'm a fan of remote work, I'm not sure if early stages is the correct time? Also, it can also be a pitfall that people want to work for you based on the cool tech, and nothing else. Which means they might be quicker to jump ship to the next cool thing and not in it for the long run? Just speculation on my part.
stevepeg 4y ago
Author here: lots of usual language-war type comments here. Just thought I'd add my own little bit of water (hopefully). In my post notice that aside from my personal background with programming I didn't go into detail about memory safety, which seems to be what many are debating. Frankly, it's not even one of my top reasons for praising the language. If I had to pick three these are what I'd choose: 1. Strong features for describing real-world issues in software. Here I'm talking about things like tagged unions (enums). They let you describe so much very cleanly. Use a match expression on it and you can be sure you've handled it pretty well. These lead into the stdlib's Result and Option types which extend what I said further. 2. Excellent performance without any fancy language stuff like annotating lifetimes. Using the Iterator trait you can chain up a really nice operation FP-style and get ridiculous performance. It takes fewer lines than idiomatic Python. 3. Excellent tooling. Cargo is easily the best package manager I've used (yet, someone show me better!). When doing async work the tracing crate is great, it automatically handles all the entry and exit points of the state machine that gets generated. You can also use tools like tokio-console on it, or export via opentelemetry.
- pg_bot 4y ago
  For point #3, take a look at Hex[0] which is a package manager for the erlang/elixir ecosystem. [0] https://github.com/hexpm/hex https://github.com/hexpm/hex
- pjmlp 4y ago
  So, F# with NuGet/Fake, Scala or Kotlin with Maven/Gradle, OCaml with OPAM. Those points are hardly Rust specific and apply to any compiled language with ML influences.
  - drogus 4y ago
    These comments are still in context of using the language in a startup. Good luck with finding Ocaml, F# or Scala devs.
    - kaba0 4y ago
amelius 4y ago
If prototyping speed and time-to-market are important, better choose a different language: one with a garbage collector. This applies to most startups.
butterfly771 4y ago
For startups, java (script)? Is the best, from a manpower market point of view.
gary17the 4y ago
Actually, I think Rust is a godsend to startups for the following reasons: 1.) startups rarely have time, expertise or budget for extensive unit tests, mock-up tests, UI-automation tests or paid third-party Q/A services, 2.) software product users these days have a strong tendency never to submit bug reports or work with product support, but instead just leave negative reviews and/or just move on to the competition, 3.) when an MVP actually does get a chance to grow in size and complexity, startups hit the growing pains of efficient problem report accumulation, recognition (troubleshooting, often with a non-technical third-party), prioritization and resolution. Every programmer who has ever maintained a product of 100,000+ lines-of-code will tell you the same thing: shift as much responsibility as possible on the compiler (and the API consumption boundaries). Fixing code due to a bug with memory management, unexpected mutation, multi-threading, etc. will cost you 10 times the effort required to write that code in the first place. Just IMHO.
- nerdponx 4y ago
  What makes Rust better for these attributes than any other statically typed language with immutable data structures? It sounds like Ocaml would do just as good of a job here.
  - Icathian 4y ago
    Ocaml is absolutely playing in similar spaces as rust. I see the tradeoff there as one of runtime performance (Rust) against less syntax / dev effort (Ocaml). If you don't need your code to go fast, Ocaml is probably just fine for you to use. Hell, Jane Street famously does so and has talked in great detail on their podcast and in articles about the many strengths and tradeoffs involved here.
    - giraffe_lady 4y ago
      It's more like "if you need your code to go extremely fast" though, which is honestly pretty rare in my experience. Ocaml is no slouch and people regularly build great products on much slower languages and that's rarely the limiting factor.
jmartin2683 4y ago
Rust is the one ring to rule them all. Embedded? Got it. Huge web app? No problem… straight to wasm. It’s hard to imagine a problem outside of machine learning (where library support is all that matters) where I’d ever feel a desire to use anything else. Other languages feel primitive, slow and/or unreliable after using rust for a while.
- kaba0 4y ago
  > Other languages feel primitive, slow and/or unreliable after using rust for a while. But the fact is that that is just feelings. Rust is a cool language, as well as a litany of others. It is unique in the low-level PL domain, but at most places managed languages can be used just fine, and I would wager that they are a better fit for regular old CRUD apps.
spaintech 4y ago
Startups are about cost, time to market, and a high level of efficiency to deliver on a promises ( product ) to sell or get to market. A language selection should consider two things, talent pool and maturity of the tools. When you go hire developers, I want a strong pool to be able to be selective in finding attitude with the right aptitude, and I want them to be productive ASAP, so that means that we might bring in GNU protects that we are extending, tooling from other sources and high level knowledge of the code… this is where maturity comes in, not the language that matters, it’s the package you get on the product you are developing. I love rust, it will get there, but in a startup environment, it could end up been “not the best fit” all things considered.
- synergy20 4y ago
  Exactly, I did startup before, and my take is: Rust is absolutely the worst choice for startups. to survive startup, you need a large pool of talents, mature and verified and boring stack, easy to find tutorials, etc. The least thing you want is to spend cycles on fancy new bleeding unstable languages to build your earth shaking product.
  - Curious_Furious 4y ago
    >you need a large pool of talents Forgive me if I'm quoting you out of context but the article mentions receiving 4000 applicants over 8 weeks time. I've hired (primarily) for Java and DBA positions, and we would be absolutely thrilled if we got even 40 applicants.
    - linkdd 4y ago
      "pool of talents" vs "pool of people who jumped on the hype train 2 weeks ago" Many people are searching for Rust jobs, but few have a really strong experience with it.
    - synergy20 4y ago
      "Many didn’t actually have Rust experience at all and that’s fine, they were just interested in the idea" -- to me, that's _not_ fine. startup needs to move fast to stay above the water, it's not the best place to learn 'coding in Rust 101' IMHO
olalonde 4y ago
> Once I started working on more complex systems such as a distributed job queue with asynchronous behavior or an embedded system interfacing with an FPGA, the gains started to come. This makes me take the advice with a grain of salt because it's not very representative of the kind of software development most startups will require. I'd be more interested to hear about startups using Rust for CRUD apps for example.
ekidd 4y ago
I have also used Rust in a startup. With one major exception, it has been a huge win. Rust makes it incredibly easy to write fast CLI tools and special purpose servers. They're solid and pleasant to maintain. Refactoring is easy, and if code compiles, it's normally correct. The biggest drawback we encountered was when we used Rust for business logic. Business logic tends to be high level and change frequently, and many different people need to touch it. So we ended up with a split: Most of our business logic is written in popular high-level languages. But for those things which aren't specific to our business, we write lots of open source Rust.
dncornholio 4y ago
I don't think startups should focus on performance. They should focus on features. Rust will probably delay and hold back new features. The language is fucking great. But the ecosystem isn't there yet and you have to re-invent the wheel again and again.
pkrumins 4y ago
Hahahahahahaha what!!!! Hahaha. It’s good for never shipping because every expression is a syntax error.
- eventhorizonpl 4y ago
  It's true that Rust is not for everyone. But if you are average+ programmer you should be able to learn it.
  - pkrumins 4y ago
    Hahshaaaaa
yesimahuman 4y ago
I’m new to Rust and partly evaluating it for future projects at a startup, and I think I could definitely see using it selectively where it’s strengths really show. We use Go in that way as well but stick to dynamic languages in other areas. I would hesitate to go all-in on Rust given hiring is already one of the biggest challenges startups will face, but I believe Rust is going to be hugely successful and the pipeline will grow considerably in the coming years.
wooque 4y ago
Blog post is just rationalization for their choice. Rust is actually terrible choice for startups. It will take 2x more time to develop same thing than using something like TypeScript/Python and you will have much smaller and more expensive talent pool. Startups usually have to make, at least minimum viable, product quickly and start selling it before funds dry out. That means using familiar tech with big ecosystem. Also choice of tech is probably least important thing contributing to startup success. That knows anyone who worked in terrible codebases that were generating multi-million revenue. Customers don't care about your tech. Simple as.
- drogus 4y ago
  Depends on what you're doing. There are apps that can be written in Rust much more quickly than in other services, cause you don't have to worry about a lot of stuff (like for example it's hard to keep an open connection for every client and process everything real time in Ruby on Rails).
- cxx 4y ago
  I write Rust and C++ for a living and completely agree with this. While I do like Rust in general, the language is so complicated that anything other than trivial programs is going to take way longer to implement than in any other language. Testing code in Rust is also half baked at best, I find that any other popular language has better capabilities than Rust in this aspect, including C++. I'd even go as far as saying that for a startup I'd use C++ before Rust if performance was a feature, otherwise I'd just go with something that has batteries included like Python or Golang.
- dimgl 4y ago
  One of the few sensible comments here. As long as your product works well for your customers, they won't care what stack you used.
pornel 4y ago
I'd say with a caveat it depends if you know what you need to build. You can have 0 bugs, but if you also have 0 users, it's not going to end well. If you've already built a slow or not-so-reliable prototype in a scripting language, and have users pushing it beyond its limits, then go ahead and make the proper version in Rust.
kevincox 4y ago
As someone using Rust for a "startup" (not hyper-growth but slow and steady) there are definitely upsides and downsides. The biggest upside is that the stricter compiler does catch bugs. It makes changing existing code easier and it makes it easier to add invariants across the code via the type system. It makes an extensive test suite much less necessary, generally unit tests for pure parts of the code and some form of simple dev/staging environment will suffice. This can defer the need for expensive and slow integration tests running on every change. Performance is also nice but it doesn't matter much. My service is running with 10m cores and 50MiB of memory, 10x those wouldn't be a major concern. I think that in 99% of cases performance only really matters when you are trying to optimize running costs and that is generally only the case when the operational costs matter relative to the cost of an employee. The performance of your application is very rarely related to the performance of your application code, usually it lies more in the database and network calls that you perform while serving requests. I think for many startups the cost of actually running your code tends to be tiny compared to staff and other infrastructure. The docker image is 160 MiB (with debug symbols) which is probably smaller than most Java/Python projects but not tiny anyways. There are definitely cases where Rust is more verbose than Python (over Java I actually find Rust more productive) but even if you can write very high-level code with Rust part of the problem is that it doesn't necessarily encourage you to do so. With things like explicit `.clone()` calls and reference counting you are very aware of every time you make a performance tradeoff. It takes the right attitude and personality to say "that's fine" for most of these cases and leave the optimization to when it matters. (When you do want to optimize it is very clear where all of these expensive operations are which is nice.) But something like Python where these slow operations are completely hidden is definitely nice for focusing on the business logic. Overall I think it is legitimately a close call. I definitely spent more time worrying about unimportant details with Rust but I likely would have shipped more bugs and had a harder time making wider changes. I would also be much less confident with the stability of the current code which is very important to me as this is running as basically a side-project without a 24/7 oncall. Also the more cross-cutting features I add the happier I am with the type checking. I think Python (with a type checker) or TypeScript would have been slightly more productive but I think the investment of Rust was worth it. The fact that I can see the path forward with no rewrites or the need to break off expensive components into microservices in higher performing languages is a really nice outlook.
dgb23 4y ago
> What does this have to do with startups though? Well, high performance means fewer servers, fewer servers means less operational overhead. As a startup your runway burns up pretty fast if you start spending it on web servers that can only support a few hundred requests per second each. This is the most interesting part for me. Not the specific numbers, but the general notion of "performance actually matters". There's impact on ROI, UX, complexity and sometimes it lets you do things that you wouldn't otherwise consider. There was a post fairly recently on here, where they showed a deployment architecture of a small business or startup. It was a simple thing, with a couple of app servers, databases and load balancers. Something like that. The app servers were written in Python/Django I think. The essence was that "this is a simple architecture on relatively cheap VPS instances with minimal complexity and it handles a ton of traffic", I think the bill was a couple hundred or a month maybe 1/2k max. I liked it. But even then I thought that there has to be some overhead that can be cut there. If your app server plus database performs well _enough_ you can run them on just one instance, you can cut several load balancers. All you need is a backup machine if you care about downtime, especially during deployments. That would roughly cost you maybe 5x less. Then you might actually be able to cut down the performance of the machine, another factor of 2. Now your bills are 10x less, you have fewer things to worry about, possibly less complex tools needed. So let's say a single developer can save them 1k (EUR/$) monthly, that would be 5-10h work hours gross, or just say a day of billable work, every month that they get out of it. And this is not considering the gains from reducing the complexity and setting themselves up for finer grained improvements and other benefits that were not possible before. I'm not considering the downsides and the estimates are shaky at best. But there might be something to this, even for fairly small teams and companies.
- chungus 4y ago
  Amazon did a nice write-up this year related to your comment : "Sustainability with Rust"[1]. The cost savings are there, both for a tiny startup, like you calculated, but also for giant companies with 1000+ instances. [1] https://aws.amazon.com/blogs/opensource/sustainability-with-rust/ https://aws.amazon.com/blogs/opensource/sustainability-with-...
FpUser 4y ago
>"have found ourselves with nothing short of a world-class engineering team" I think this is what actually makes your development efforts go smoothly. Not a language choice.

175 points by stevepeg 4y ago

Many good points that I'm able to relate to. However, the post is too exaggerated, e.g.: > The amount of debugging required for Rust projects is an order of magnitude less than I’ve seen anywhere else. Sorry, that's just nonsense. I've done a large amount of .NET and Java and a good amount of Go and Rust. Stating that debugging effort in other languages is at least 10 time (which is an order of magnitude) higher is a huge exaggeration. Also, one absolute critical point is missing: The reliability of the ecosystem. That's the biggest weakness of Rust. Rust's NPM like ecosystem is just brittle and dangerous. There're enough examples of widely used crates that caused issues due to maintenance or that had malicious code. For all the undeniable benefits Rust brings, this single big disadvantage makes it actually not the best choice for startups. I sometime wish Rust and Go had a baby ...

dijit 4y ago
yeah, I love Rust but this rings hollow for me too. debugging python is a pleasure compared to Rust, and it makes sense that this is the case... Rust itself performs well because of the compilation stage to native code, but it gets harder to step through because of that.

jedisct1 4y ago

What matters for a startup is time to market. So, go with a boring technology that the existing team is already familiar with, and that fits your use case. There's nothing wrong with PHP, Python, Go, JavaScript or Java. Even modern "no code" tools such as Bubble can get a first version done in a minimum amount of time.

eventhorizonpl 4y ago
Time to market is important if you have an idea that replicates existing solutions. Or is easy to replicate by others.

ecmascript 4y ago

Two days ago I started to rewrite an api I made years ago in Nuxt3. The day after I finished it. Sure, I know javascript and I could reuse a small bit of code but if I would imagine switching to rust it would probably take me at least a month mostly because I don't know much about it. The times I've actually tried Rust out it's been a struggle, to say the least, and I am a programmer with over 10 years of experience. Ok if you are the VC-funded kind of startup that needs developer hype and can afford to hire people. But if you are a bootstrapped startup I barely can think of worse languages than Rust to start with unless you've extensive experience in it. The crates available seems sparse and of low quality. Getting back to my example, I would have to rewrite a parser from scratch most likely and only that would probably take me quite some time while in node I can just npm install it which have worked flawlessly for years. Unless you're in a market that requires the service or product to utilize every cent of performance or is in embedded industry I think Rust is a terrible choice for a startup.

fkrst 4y ago

When you're building a product you definitely want to spend your time fucking around with all the object lifetime concepts of Rust or the subtleties of its compiler... Just use any language with high-level features like a garbage collector, bignums by default and message passing concurrency (Racket, Erlang, whatever), and you will be more productive, and actually have more "fearless" / safe programming than you will ever have using Rust.

longrod 4y ago

The technical aspect of a startup hardly even matters as long as you get the job done. The first thing to understand before you start a startup is that it doesn't matter how much you love programming. It doesn't matter how beautiful your code is or how much time you spent writing it. What matters is marketing. You can use Rust or JavaScript or whatever language you want but if you want to be successful, you will spend more time thinking about how to market. Customers don't care what language a product is written in (unless it's a developer facing product). Customers care about getting the job done. I know the argument here is that Rust offers long term stability but if you are a startup, you will be changing the product so rapidly and adding more and more features, the sheer level of growth will make your product unstable. I am not against someone using Rust for their new startup IF they are already comfortable in it and know the ins and outs of Rust. Rust is way more complex than JS. The learning curve is considerably steeper. And that matters because if you use a great language and write it poorly, no matter what guarantees it offers, you won't get a better product than if you wrote it in a language you understood well. So if you are a startup, don't think about the language. Think about what will sell, how you will sell etc. If you can't sell it, it doesn't matter if you wrote it in a particular fancy language. The technical aspects of a product are rarely a sales increasing factor.

ahallock 4y ago

Unless Rust itself solves a problem specific to your startup, I'm not so sure. I like Rust, but the language seems very complex compared with Ruby or JS, so your talent pool will be considerably smaller and probably more expensive.

jcpst 4y ago

I’ve been using Rust as a hobbyist since 2015. I see what’s going on in the community, attend a meetup, and work on open source projects (mostly my own). I’m starting a side project, and after much consideration, I went with F# and AspNetCore. The maturity of the framework and solutions for web is hard to ignore. And then F# gives me a lot of what I like about Rust: union types, pattern matching, avoiding null… With less syntax, and without reasoning about lifetimes, which still takes me more effort than I would like. Don’t get me wrong, I love Rust. In this case, I was able to build out a web server a lot faster, while still getting _most_ of what I love about Rust.

runevault 4y ago
Are you using ASP.Net Core straight up or through something like Giraffe? Also are you using JS or Fable/etc to handle the front end? The F# web ecosystem is something that I've done light research on but haven't done a real project with yet, but still incredibly curious about it.
- jcpst 4y ago
  I'm using Giraffe. Building everything in the request pipeline as composable handlers has been nice. For the front end, I have decided to do server-rendered pages, using Giraffe.ViewEngine. So the source for the HTML is all F# code too. For interactivity and updates without a full page reload, I am using htmx. This has been so nice that I feel “done” with SPAs as the default choice for a web UI. 99% of the JS I need is encapsulated in a library. If I ever need more, I can just incrementally adopt Vue or something similar on a page that needs it and go from there.
  - runevault 4y ago
    That sounds wonderful. I'll keep your thoughts in mind if I get back to F# for something to try out.

Wavelets 4y ago

Is there a mature, production ready library for deploying deep neural networks in Rust? Searches end up being all over the place and end with a library that hasn’t been maintained in years.

taylodl 4y ago

Rust is not a great choice for startups! In fact, NO LANGUAGE is a great choice for startups! You don't choose languages depending on whether you're a startup! You choose languages based of the problem you're trying to solve, how fit the language is for solving that particular problem, the ecosystem supporting that language, and the availability of developers who are experienced with that language. Rust just may be the best choice for your startup, but it's not necessarily the best choice for all startups - in fact it's probably not the best choice for most startups! That doesn't mean there's anything wrong with Rust, it just means Rust isn't the right tool for the job most startups are trying to tackle. If it is the right tool then absolutely you should use it!

StefanHamminga 4y ago
I've seen this in action: A startup I did consulting work for had a "genius" who convinced management that everything should be written in Haskell. As a consequence building a team was painfully slow, so slow that some guy in a weekend recreated in node.js what their 15 people team had painstaking put together in 3 months. Turns out doing a web service with tools meant for it was better than "everything should be functional".
- omegalulw 4y ago
  I would love to hear that argument for Haskell for web dev.
- taylodl 4y ago
  Unpopular opinion - Haskell was intended for research and learning, not so much for mainstream production code. I'm not saying you can't use Haskell for that purpose, but you should think long and hard before doing so. If the answer is still yes then go back and make sure you've thought long enough and hard enough! :)
  - JoelMcCracken 4y ago
    Haskell is fine for production code. You just need to know what you're doing, and not go crazy with abstraction.

torton 4y ago

I remember seeing probably the exact same discussion on HN maybe five years back s/Rust/Go. The more things change, the more they stay the same.

wly_cdgr 4y ago

Startups should hire the kind of people who are experts at both C++ and Javascript, then ask them to choose the right tools and languages for the task at hand. Which I am sure may end up sometimes including Rust.

labrador 4y ago

If I were the author I would retitle the article "Why Rust might be a great choice for your startup"

kokizzu2 4y ago

nsonha 4y ago

This is hilarious, it is a great choice for start ups, to do what? How is it that what you do isn't the first thing that affect your choice of technology, but the "type of company" you are is?

ncmncm 4y ago

Rust is a great choice for startups because most startups fold and so will not need to try to find people who know how to maintain it.

eventhorizonpl 4y ago
If you build a startup around bad ideas realized in crappy languages, than it's a great recipe for a disaster. If you have a good idea and you hire seasoned developers who can realize this idea you are at least on the good path.
- ncmncm 4y ago
  Necessary, but not sufficient. Almost all the startups with bad implementations will fold. Almost all the startups with good implementations will fold.
  - quickthrower2 4y ago
    I worked for a company that used some crappy 2000s 4GL nocode tool to get started. Didn’t hurt them financially at all.
- rwalle 4y ago
  Zuckerberg something...
sshine 4y ago
I would argue that Rust is a great choice for startups exactly because you can find people who will either take a pay cut or work in a hectic environment, just so they can use Rust. Rust has been on top of everyone's "want to learn" list for half a decade, and it feels quite mature.
- deterministic 4y ago
  Nope not even close to being true. I am way more interested in more advanced languages (using dependent types).

chungus 4y ago

>(...) despite my experience and best intentions, I was in fact making mistakes with C. Subtle leaks, use-after-free,(...) Rust made it very clear that I was not the programmer I thought I was. This really resonated with me. I feel a lot more confident writing code in Rust than say in C or Java. However, in my opinion, it also comes with a downside: These days, whenever I use a 'more forgiving' programming language I find myself being much more paranoid of the code that I write. Even after double checking everything I still miss the memory guarantees that Rust brings, and end up spending a lot of time making sure things are behaving the way they should.

eventhorizonpl 4y ago
Do you pine for the nice days of C/C++, when men were men and spend hours on debugging segmentation faults?
- p0nce 4y ago
  This is quite rare in C++ since C++11.
- mbrodersen 4y ago
  I am a professional C++ programmer and I can’t even remember the last time I had a segfault. I also haven’t had a bug in production the last 5 years. But YMMV of course.
- farseer 4y ago
  Sticking to STL in C++ and avoiding pointers unless really necessary will significantly cut down on segmentation faults.
- ncmncm 4y ago
  It has been many years since I spent "hours debugging" a segfault. But I use C++, not C. (That said, I coded C from 2008 to 2012, and spent no hours on segfaults then, either.)
- papito 4y ago
  Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters. Scala has the same problem. Stop writing your own DSLs!

ThePhysicist 4y ago

I started my first Rust project a month ago after working for years in Golang and before that Python (and before that Perl, C/C++ and Turbo Pascal). I really like the whole experience but I'm not sure if I'd recommend writing all your backend code in Rust as a startup. Rust definitely provides a pleasant experience and is very powerful. If you can stick to the standard library I think Rust is great, though the package ecosystem is still lacking in many respects and most packages seem immature and quite limited. So if you plan to build something that has sizeable external dependencies plan some time to either write that yourself or to spend a lot of time debugging and vetting external packages, many of which are maintained as side projects by single developers. Documentation often also seems to be subpar as compared to e.g. Python. I suppose that's due to the auto-generation of documentation which seems to lead to people mostly writing what I'd refer to as API documentation with very few tutorials. So is Rust worth it for a startup? Not so sure. I recently picked up Python again to write a simple REST API, and the process is just so much faster and (for me) enjoyable because of the "ad hocness" of the language and of course the great existing tooling around it (I still have to find an ORM as powerful as SQLAlchemy in Rust or Golang). And let's be honest it's also possible to write great scalable services in Python (or Ruby, or Javascript), as many scaleups still use these technologies. Onboarding of developers might be another issue: Yeah, everyone wants to be a Rust programmer, but for people that have little experience with systems programming the learning curve is quite steep, so you'll limit your candidate pool quite a bit and will need more time for hiring.

drogus 4y ago
> I recently picked up Python again to write a simple REST API, and the process is just so much faster For me it's much more important how will it work in the next few years, not how quickly you can write it. If I could, I would use Rust for pretty much everything just because I don't like getting paged in the middle of the night.
- mikevm 4y ago
  I agree. This typing velocity argument is really weak. It may be faster to start, but talk to me once the project reaches 10K+ lines of code and we'll see how you fare with your scripting language.

lionside 4y ago

I’ve been working on an OS project to help people get on this bandwagon: create-rust-app [1]. The folks over at shuttle.rs also wrote a blogpost around a similar topic which was a very interesting read as a rust developer. [2] [1] https://github.com/Wulf/create-rust-app https://github.com/Wulf/create-rust-app [2] https://www.shuttle.rs/blog/2021/10/08/building-a-startup-with-rust https://www.shuttle.rs/blog/2021/10/08/building-a-startup-wi...

chungus 4y ago
This is great, it looks like it does a lot already and I really like the plugin system. I think you should definitely get the documentation written up. One thing, the "Walkthrough" video in your README is unwatchable, because it displays very small. I had to download it to be able to watch it properly.

T3RMINATED 4y ago

kasperni 4y ago

> it’s still orders of magnitude faster than Python, Ruby, Javascript and Java. Unsubstantiated claims like this, just makes me stop reading.

igouy 4y ago
What's your ballpark guestimate? aot language implementation based-on llvm, guess something like clang? Then guess it depends which Python and Ruby language implementations, what exactly we need to do and how much we can call C libs :-) https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html#chart-fastest https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
eventhorizonpl 4y ago
https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
- vegai_ 4y ago
  In these benchmarks Java is not that far from Rust's performance. In fact, it hits #1 in some tests.
eventhorizonpl 4y ago
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/pidigits.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
lenkite 4y ago
And also false claims of "orders of magnitude", esp wrt Java https://deepu.tech/concurrency-in-modern-languages-final/ https://deepu.tech/concurrency-in-modern-languages-final/

farseer 4y ago

>>Why Rust is a great choice for startups No mention of the type of problem the startup is trying to solve. A performance hungry desktop app? A web based SAS? Not all language choices are equal.

stevepeg 4y ago
Author here: didn't expect this to get on the front page, some kind of life goal achieved I guess. Here's a link to our Show HN from a week ago: https://news.ycombinator.com/item?id=31630604 https://news.ycombinator.com/item?id=31630604
- dannersy 4y ago
  I may have significant input on a green field project, which is generically a web use case, but performance will be a factor. I'm interested in pitching it, as I know other teammates will be be, but none of us are particularly skilled in writing Rust. For instance, the largest thing I've written is still half baked which happens to be a basic REST API for a personal project. I have only begun to see some of the benefits you explain in your article. I'm curious if you feel that it's necessary to have an "expert" or experienced Rust developer on the team for it to be the technology of choice; or do you think Rust has sufficient guard rails for a team with basic understanding of mature packages and overall senior experience? The reason I ask is because I've known several teams pick up Go because of their interest in it, ultimately being happy with the choice, but have strong opinions about their initial implementations. Perhaps that's just the nature of software, but I would love your opinion.
  - stevepeg 4y ago
    No worries, here's my opinion (lots of lang-war stuff, so note "opinion"): I would say that it depends on your comfort with async code in Rust since much of the web ecosystem is built that way. If you're comfortable writing async Rust then go for it, the guard rails are there. People complain (especially here) but it's fine. Our entire web backend and our scheduler applications are overwhelmingly async. We have not hit the weird stuff you read about with lifetimes even once. However, it does expect you to know how it works. You need to understand what the async runtime does otherwise it will add friction. If you're not yet proficient with this part of Rust then you will benefit from having an "expert" on the team as you say, since they can guide the rest. Our team were all experienced in Rust already when hired so we didn't hit this. If you're uncomfortable then simply choose the language your team already knows. That's the pragmatic choice.

235235235235 4y ago

What does Rust offer over modern C++ with smart pointers and RAII?

deleted 4y ago
[deleted]
unixhero 4y ago
Rustian Safety Rustian Garbage collection
- ur-whale 4y ago
  > Rustian Garbage collection Genuinely curious here: the Java GC (still in 2022) is often a major headache in production wrt latency when system is under load. How's the Rust GC in that regard?
  - tialaramex 4y ago
    Rust isn't a Garbage Collected language. However, because Rust cares about who owns things, it gets to have all the benefits you get with say RAII types in C++ except seamlessly (in safe Rust anyway). Imagine you make a Doodad, like you call a constructor for it maybe, or there's some call somewhere that gives you a Doodad. OK. Now you put the Doodad in a Hashtable of Doodads. Well, is that still your Doodad? Are you responsible for ensuring it is properly cleaned up at some point? Or does the Hashtable now take responsibility for it? If somebody looks in the Hashtable, do they get back the Doodad? Now is it no longer the Hashtable's responsibility? Rust systematically has answers to all these questions, which permeates the language and its ethos, in exchange it gets to have really nice properties.
  - kaba0 4y ago
    > the Java GC (still in 2022) is often a major headache in production wrt latency when system is under load. Can you say a bit more about your experience regarding this? In my experience, it is either not due to GC, because it is really hard to make the G1 GC miss its target pause time, or there is an easily debuggable function creating way too much object, and the fix is often trivial. Like, the JVM has the state-of-the art GC implementations.

jasfi 4y ago

What about Nim? An in-progress full-stack framework for Nim: https://github.com/jfilby/nexus https://github.com/jfilby/nexus

deleted 4y ago
[deleted]

Zababa 4y ago

> But you really don’t need much more engineer time than using another language, and you get the lower overhead when you actually run your program. That seems like an extraordinary claim to me. That would imply that when picking something like Django, Rails or Spring over Rust, there's no difference in engineer time taken to add a new feature.

matsemann 4y ago

I guess it works for a fully remote company, as you have a large pool of possible candidates. But in my area, I'd say it would be easiest to recruit using java. Next python or node/js, but still a vastly smaller group compared to java devs.

mwcampbell 4y ago
That sounds to me like a strong argument for any new startups founded by people in your area being remote-first.
- matsemann 4y ago
  That's a good point, but I'm actually not so sure about it. I think that perhaps most startups need a tighter group and alignment than what remote can provide. While I'm a fan of remote work, I'm not sure if early stages is the correct time? Also, it can also be a pitfall that people want to work for you based on the cool tech, and nothing else. Which means they might be quicker to jump ship to the next cool thing and not in it for the long run? Just speculation on my part.

stevepeg 4y ago

Author here: lots of usual language-war type comments here. Just thought I'd add my own little bit of water (hopefully). In my post notice that aside from my personal background with programming I didn't go into detail about memory safety, which seems to be what many are debating. Frankly, it's not even one of my top reasons for praising the language. If I had to pick three these are what I'd choose: 1. Strong features for describing real-world issues in software. Here I'm talking about things like tagged unions (enums). They let you describe so much very cleanly. Use a match expression on it and you can be sure you've handled it pretty well. These lead into the stdlib's Result and Option types which extend what I said further. 2. Excellent performance without any fancy language stuff like annotating lifetimes. Using the Iterator trait you can chain up a really nice operation FP-style and get ridiculous performance. It takes fewer lines than idiomatic Python. 3. Excellent tooling. Cargo is easily the best package manager I've used (yet, someone show me better!). When doing async work the tracing crate is great, it automatically handles all the entry and exit points of the state machine that gets generated. You can also use tools like tokio-console on it, or export via opentelemetry.

pg_bot 4y ago
For point #3, take a look at Hex[0] which is a package manager for the erlang/elixir ecosystem. [0] https://github.com/hexpm/hex https://github.com/hexpm/hex
pjmlp 4y ago
So, F# with NuGet/Fake, Scala or Kotlin with Maven/Gradle, OCaml with OPAM. Those points are hardly Rust specific and apply to any compiled language with ML influences.
- drogus 4y ago
  These comments are still in context of using the language in a startup. Good luck with finding Ocaml, F# or Scala devs.
  - kaba0 4y ago

amelius 4y ago

If prototyping speed and time-to-market are important, better choose a different language: one with a garbage collector. This applies to most startups.

butterfly771 4y ago

For startups, java (script)? Is the best, from a manpower market point of view.

gary17the 4y ago

Actually, I think Rust is a godsend to startups for the following reasons: 1.) startups rarely have time, expertise or budget for extensive unit tests, mock-up tests, UI-automation tests or paid third-party Q/A services, 2.) software product users these days have a strong tendency never to submit bug reports or work with product support, but instead just leave negative reviews and/or just move on to the competition, 3.) when an MVP actually does get a chance to grow in size and complexity, startups hit the growing pains of efficient problem report accumulation, recognition (troubleshooting, often with a non-technical third-party), prioritization and resolution. Every programmer who has ever maintained a product of 100,000+ lines-of-code will tell you the same thing: shift as much responsibility as possible on the compiler (and the API consumption boundaries). Fixing code due to a bug with memory management, unexpected mutation, multi-threading, etc. will cost you 10 times the effort required to write that code in the first place. Just IMHO.

nerdponx 4y ago
What makes Rust better for these attributes than any other statically typed language with immutable data structures? It sounds like Ocaml would do just as good of a job here.
- Icathian 4y ago
  Ocaml is absolutely playing in similar spaces as rust. I see the tradeoff there as one of runtime performance (Rust) against less syntax / dev effort (Ocaml). If you don't need your code to go fast, Ocaml is probably just fine for you to use. Hell, Jane Street famously does so and has talked in great detail on their podcast and in articles about the many strengths and tradeoffs involved here.
  - giraffe_lady 4y ago
    It's more like "if you need your code to go extremely fast" though, which is honestly pretty rare in my experience. Ocaml is no slouch and people regularly build great products on much slower languages and that's rarely the limiting factor.

jmartin2683 4y ago

Rust is the one ring to rule them all. Embedded? Got it. Huge web app? No problem… straight to wasm. It’s hard to imagine a problem outside of machine learning (where library support is all that matters) where I’d ever feel a desire to use anything else. Other languages feel primitive, slow and/or unreliable after using rust for a while.

kaba0 4y ago
> Other languages feel primitive, slow and/or unreliable after using rust for a while. But the fact is that that is just feelings. Rust is a cool language, as well as a litany of others. It is unique in the low-level PL domain, but at most places managed languages can be used just fine, and I would wager that they are a better fit for regular old CRUD apps.

spaintech 4y ago

Startups are about cost, time to market, and a high level of efficiency to deliver on a promises ( product ) to sell or get to market. A language selection should consider two things, talent pool and maturity of the tools. When you go hire developers, I want a strong pool to be able to be selective in finding attitude with the right aptitude, and I want them to be productive ASAP, so that means that we might bring in GNU protects that we are extending, tooling from other sources and high level knowledge of the code… this is where maturity comes in, not the language that matters, it’s the package you get on the product you are developing. I love rust, it will get there, but in a startup environment, it could end up been “not the best fit” all things considered.

synergy20 4y ago
Exactly, I did startup before, and my take is: Rust is absolutely the worst choice for startups. to survive startup, you need a large pool of talents, mature and verified and boring stack, easy to find tutorials, etc. The least thing you want is to spend cycles on fancy new bleeding unstable languages to build your earth shaking product.
- Curious_Furious 4y ago
  >you need a large pool of talents Forgive me if I'm quoting you out of context but the article mentions receiving 4000 applicants over 8 weeks time. I've hired (primarily) for Java and DBA positions, and we would be absolutely thrilled if we got even 40 applicants.
  - linkdd 4y ago
    "pool of talents" vs "pool of people who jumped on the hype train 2 weeks ago" Many people are searching for Rust jobs, but few have a really strong experience with it.
  - synergy20 4y ago
    "Many didn’t actually have Rust experience at all and that’s fine, they were just interested in the idea" -- to me, that's _not_ fine. startup needs to move fast to stay above the water, it's not the best place to learn 'coding in Rust 101' IMHO

olalonde 4y ago

> Once I started working on more complex systems such as a distributed job queue with asynchronous behavior or an embedded system interfacing with an FPGA, the gains started to come. This makes me take the advice with a grain of salt because it's not very representative of the kind of software development most startups will require. I'd be more interested to hear about startups using Rust for CRUD apps for example.

ekidd 4y ago

I have also used Rust in a startup. With one major exception, it has been a huge win. Rust makes it incredibly easy to write fast CLI tools and special purpose servers. They're solid and pleasant to maintain. Refactoring is easy, and if code compiles, it's normally correct. The biggest drawback we encountered was when we used Rust for business logic. Business logic tends to be high level and change frequently, and many different people need to touch it. So we ended up with a split: Most of our business logic is written in popular high-level languages. But for those things which aren't specific to our business, we write lots of open source Rust.

dncornholio 4y ago

I don't think startups should focus on performance. They should focus on features. Rust will probably delay and hold back new features. The language is fucking great. But the ecosystem isn't there yet and you have to re-invent the wheel again and again.

pkrumins 4y ago

Hahahahahahaha what!!!! Hahaha. It’s good for never shipping because every expression is a syntax error.

eventhorizonpl 4y ago
It's true that Rust is not for everyone. But if you are average+ programmer you should be able to learn it.
- pkrumins 4y ago
  Hahshaaaaa

yesimahuman 4y ago

I’m new to Rust and partly evaluating it for future projects at a startup, and I think I could definitely see using it selectively where it’s strengths really show. We use Go in that way as well but stick to dynamic languages in other areas. I would hesitate to go all-in on Rust given hiring is already one of the biggest challenges startups will face, but I believe Rust is going to be hugely successful and the pipeline will grow considerably in the coming years.

wooque 4y ago

Blog post is just rationalization for their choice. Rust is actually terrible choice for startups. It will take 2x more time to develop same thing than using something like TypeScript/Python and you will have much smaller and more expensive talent pool. Startups usually have to make, at least minimum viable, product quickly and start selling it before funds dry out. That means using familiar tech with big ecosystem. Also choice of tech is probably least important thing contributing to startup success. That knows anyone who worked in terrible codebases that were generating multi-million revenue. Customers don't care about your tech. Simple as.

drogus 4y ago
Depends on what you're doing. There are apps that can be written in Rust much more quickly than in other services, cause you don't have to worry about a lot of stuff (like for example it's hard to keep an open connection for every client and process everything real time in Ruby on Rails).
cxx 4y ago
I write Rust and C++ for a living and completely agree with this. While I do like Rust in general, the language is so complicated that anything other than trivial programs is going to take way longer to implement than in any other language. Testing code in Rust is also half baked at best, I find that any other popular language has better capabilities than Rust in this aspect, including C++. I'd even go as far as saying that for a startup I'd use C++ before Rust if performance was a feature, otherwise I'd just go with something that has batteries included like Python or Golang.
dimgl 4y ago
One of the few sensible comments here. As long as your product works well for your customers, they won't care what stack you used.

pornel 4y ago

I'd say with a caveat it depends if you know what you need to build. You can have 0 bugs, but if you also have 0 users, it's not going to end well. If you've already built a slow or not-so-reliable prototype in a scripting language, and have users pushing it beyond its limits, then go ahead and make the proper version in Rust.

kevincox 4y ago

As someone using Rust for a "startup" (not hyper-growth but slow and steady) there are definitely upsides and downsides. The biggest upside is that the stricter compiler does catch bugs. It makes changing existing code easier and it makes it easier to add invariants across the code via the type system. It makes an extensive test suite much less necessary, generally unit tests for pure parts of the code and some form of simple dev/staging environment will suffice. This can defer the need for expensive and slow integration tests running on every change. Performance is also nice but it doesn't matter much. My service is running with 10m cores and 50MiB of memory, 10x those wouldn't be a major concern. I think that in 99% of cases performance only really matters when you are trying to optimize running costs and that is generally only the case when the operational costs matter relative to the cost of an employee. The performance of your application is very rarely related to the performance of your application code, usually it lies more in the database and network calls that you perform while serving requests. I think for many startups the cost of actually running your code tends to be tiny compared to staff and other infrastructure. The docker image is 160 MiB (with debug symbols) which is probably smaller than most Java/Python projects but not tiny anyways. There are definitely cases where Rust is more verbose than Python (over Java I actually find Rust more productive) but even if you can write very high-level code with Rust part of the problem is that it doesn't necessarily encourage you to do so. With things like explicit `.clone()` calls and reference counting you are very aware of every time you make a performance tradeoff. It takes the right attitude and personality to say "that's fine" for most of these cases and leave the optimization to when it matters. (When you do want to optimize it is very clear where all of these expensive operations are which is nice.) But something like Python where these slow operations are completely hidden is definitely nice for focusing on the business logic. Overall I think it is legitimately a close call. I definitely spent more time worrying about unimportant details with Rust but I likely would have shipped more bugs and had a harder time making wider changes. I would also be much less confident with the stability of the current code which is very important to me as this is running as basically a side-project without a 24/7 oncall. Also the more cross-cutting features I add the happier I am with the type checking. I think Python (with a type checker) or TypeScript would have been slightly more productive but I think the investment of Rust was worth it. The fact that I can see the path forward with no rewrites or the need to break off expensive components into microservices in higher performing languages is a really nice outlook.

dgb23 4y ago

> What does this have to do with startups though? Well, high performance means fewer servers, fewer servers means less operational overhead. As a startup your runway burns up pretty fast if you start spending it on web servers that can only support a few hundred requests per second each. This is the most interesting part for me. Not the specific numbers, but the general notion of "performance actually matters". There's impact on ROI, UX, complexity and sometimes it lets you do things that you wouldn't otherwise consider. There was a post fairly recently on here, where they showed a deployment architecture of a small business or startup. It was a simple thing, with a couple of app servers, databases and load balancers. Something like that. The app servers were written in Python/Django I think. The essence was that "this is a simple architecture on relatively cheap VPS instances with minimal complexity and it handles a ton of traffic", I think the bill was a couple hundred or a month maybe 1/2k max. I liked it. But even then I thought that there has to be some overhead that can be cut there. If your app server plus database performs well _enough_ you can run them on just one instance, you can cut several load balancers. All you need is a backup machine if you care about downtime, especially during deployments. That would roughly cost you maybe 5x less. Then you might actually be able to cut down the performance of the machine, another factor of 2. Now your bills are 10x less, you have fewer things to worry about, possibly less complex tools needed. So let's say a single developer can save them 1k (EUR/$) monthly, that would be 5-10h work hours gross, or just say a day of billable work, every month that they get out of it. And this is not considering the gains from reducing the complexity and setting themselves up for finer grained improvements and other benefits that were not possible before. I'm not considering the downsides and the estimates are shaky at best. But there might be something to this, even for fairly small teams and companies.

chungus 4y ago
Amazon did a nice write-up this year related to your comment : "Sustainability with Rust"[1]. The cost savings are there, both for a tiny startup, like you calculated, but also for giant companies with 1000+ instances. [1] https://aws.amazon.com/blogs/opensource/sustainability-with-rust/ https://aws.amazon.com/blogs/opensource/sustainability-with-...

FpUser 4y ago

>"have found ourselves with nothing short of a world-class engineering team" I think this is what actually makes your development efforts go smoothly. Not a language choice.