23 ms·

I love building a startup in Rust but wouldn't pick it again

253 points by aisrael 4y ago

alfor 4y ago
Performance of language is almost never a big concern, but it’s so interesting for a technical person.
hardwaregeek 4y ago
I write a lot of Rust. I think you can do a startup in rust but you need to explicitly go against the natural inclinations of rust. Rust is a great language partially because it cares about the details. It’ll do stuff like distinguish between Path and String because it treats the edgecases as important. In a startup that’s not really a priority. In fact focusing on edgecases and doing things the “right” way is completely not the point of writing code in a startup. Rust is also a great language to refactor, something that’s also not ideal for a startup to be spending cycles on. Would I do a startup in rust? Maybe. It’d depend on the idea. But I’d take measures to avoid the natural orthodoxy of Rust.
Aissen 4y ago
Crazy to think that cloud credits, in addition to distorting the hosting competition, might also distort the language choice competition…
- ReflectedImage 4y ago
  The first hit of cloud is free but once they have you hooked they charge an arm and a leg afterwards.
dmillar 4y ago
Perhaps not the case here, but there are a couple of things I would add to this sentiment. First, if you love Rust uniquely, I'd argue it might still make sense to use Rust to build your first product iterations. If your initial team commonly loves Rust, and can't agree on "love" for another common language, perhaps Rust is the best language. Burnout will happen exponentially faster if developers are lamenting the language (n.b. Rust is commonly lamented). I think there are enough language/platform options these days for this to be an unlikely scenario, but this is to say don't discount your passion for a language because it doesn't iterate fast enough. Second, if the problem your startup is trying to solve is solidly in the performance and security realm, it makes sense to start in Rust. If your pitch is something like "pandas but fast and memory efficient" it also makes sense to start your project in something like Rust.
andrewstuart 4y ago
"I find myself missing match in pretty much every other language I go to." Python has match, is this the same thing? https://blog.teclado.com/python-match-case/ https://blog.teclado.com/python-match-case/
shmerl 4y ago
That has a catch 22. If you aren't going to start with Rust from the beginning, switching to it later becomes too costly and too difficult, which defeats the argument of it being useful in general. Most often what's used in the beginning as "prototyping" is cemented into the system to the point that it's hard to change it. So yeah, better to deal with complexities in the beginning and save on switching later, than not to use it all.
japhib 4y ago
For pattern matching and expressiveness in a backend language that lets you iterate quickly, I'd highly recommend Elixir.
- innocentoldguy 4y ago
  I would reach for Elixir, Phoenix, and LiveView for any new web development. We were using Java before and were running into major productivity issues. After extensive testing with Elixir, Node, Clojure, Go, and a handful of other languages, Elixir won out, we rewrote our entire stack, and our productivity skyrocketed. I can’t say enough good about it.
mixmastamyk 4y ago
Yes, many times "typing supremacists" and pedantic folks will recommend this course of action but it is not a great idea much of the time as the piece illustrates. Getting things perfect on a code-level up front is rarely what a new project needs. A more effective strategy for business is to instead prototype in something like Python—that's what it's for. This was known back in the 90s, and been somewhat forgotten. Django too. Like a flexible clay to rapidly sculpt to a first approximation. Then: 1) Get to product market fit, keep iterating until you do. Do not go to step 2 until that happens. 2) Get the fundamental data models right, get your fundamental software design right. Keep iterating until you do. Do not go to step 3 until that happens. This stuff is easier in Python as it gets out of your way. Yes use pyflakes, a few tests, and a code formatter to keep you honest. But not much more that that. Pycharm for example, if you need a helping hand. 3) When step 1 and 2 are a looking good, then rebuild the foundation of your gleaming skyscraper with the steel girders of rust, java, and/or other bdsm languages with an already good product and design. Step three may not even be needed if you have a CRUDdy project. Complete the typing at that time.
eYrKEC2 4y ago
We love using rust on the backend at https://mayhem4api.forallsecure.com/ https://mayhem4api.forallsecure.com/ and in our CLI. If I were the decider, I'd choose it again. Rust is a hurdle to learn, but the confidence you gain from the type system is fantastic. I've worked in other projects with different, looser-type'd languages (no names! no flames!) and despite good testing coverage, the confidence on release to prod is not as high.
AceJohnny2 4y ago
> Perf is easy when you have AWS credits. I get that the point of this article is that launching > sustaining. But I have a horror story about AWS credits for startups: a friend's startup got their account suspended for a couple days when their Credits ran out, they started getting billed 5 digits (as they expected), and Amazon's fraud detection detected this as an anomalous billing pattern and suspended them! For transitioning from AWS credits to billing!? Considering all their operations were running in AWS, and they were providing a HW-critical service to their customers, it was bad. This was late last year. This was despite getting reassurances from their AWS rep that the transition would be smooth.
- ISL 4y ago
  If those reassurances are in unmistakable writing, a letter from the startup's corporate attorney may yield a quick refund and compensation.
  - AceJohnny2 4y ago
    Sure, but in the life of a startup that's just one extra thing they'd rather not have to deal with, and the damage isn't just financial.
legerdemain 4y ago
In my experience with Palantir "alums," none of the crotchety perfectionists I knew ended up working with Rust after leaving. I guess AI (as the author of this post is affectionately known) beat the trend by starting his own company!
twsted 4y ago
"Building a startup in Rust". I know the hype around Rust, but this is really exaggerated: you build a startup for creating a product or giving a service, not to have something written in Rust. Your customers should care about what you are offering, much more than about which language do you use.
julianeon 4y ago
I find it mystifying that one of the reasons you can supposedly pass over Rust, and avoid performance concerns, is to "take the free money." Literally. That is, the free money, in credits, that allows you to not worry about performance for a while. The obvious problem being... "What happens when the free money runs out?" It's not addressed, but the implied answer seems to be "Well, by then it'll be six months later, and..." And? And what? It's still a problem! It didn't go away. The money deflected the perf concerns for some time, maybe a year - but then it's back, bigger and badder than ever. Rust solves that by not requiring that outlay ever, by being more efficient. Seems like a very poor reason to not choose Rust, to me.
- globalreset 4y ago
  At that point startup has revenue so can pay or is dead so it doesn't matter.
- nazka 4y ago
  I am a Rust fanboy but using it to start a startup hmm unless it’s for a specific use case. No. Why? Because the biggest bill you will have to pay at first in a startup and for a long time won’t be AWS but all the (devs) salaries. And compare to what you will pay to AWS that’s a lot of money. So a gain in performance won’t matter as much as in your success (and survivability) than speed in developing new feature every week. Depending what you do but it’s usually the case that performance won’t matter until mid late game. I saw a startup at +300M valuation still not having to worry about performance for a long time. And a cut in the AWS bill thanks to using a more performant language like Rust won’t make that much a difference compare to how much they had to pay devs. So you just want a language where you can ship features fast. Also the hiring pool is still very small.
cultofmetatron 4y ago
Reading this makes me reaffirm my decision to build my startup in elixir. At the time, it came down to 3 compelling choices 1. typescript - I already had 6 years of full stack js experience. The ecosystemis full of issues but its all issues I'm used to. 2. rust - new kid on the block. the type system and speed were compelling but it was still being developed and the learning curve was brutal. Plus I was under the gun to get the mvp up. we needed to get a working piece of software up and test out business assumptions. In the end I went with elixir. Realtime sync was a huge killer feature we were aiming for and phoenix came with the best out of the box support for it. Overall productivity was on par with javascript while the functional aspects made certain types of bugs non issues in elixir. runtime performance has been more that adequate. after 3 years in production, we have only recently rolled out rate limiting and caching and only as a precaution as we've been expanding quickly. Echoing the author's sentiments, I can definitely see places where rust could be better and thanks to tools like rustler, we'll be able to bring those in piecemeal as needed. I'm sure our product would be even faster and more efficient on resources if we did it in rust but I'm pretty sure we would have more likely run out of runway before that happenned.
Matthias247 4y ago
> We have extractors for different user requirements to make adding APIs very straightforward. We have middleware for scoping requests per customer. In most languages, this is pretty standard, but in Rust, for our use case, they both require at least a rough understanding of pinning. This is more about "async Rust" and the way that the most common web frameworks for Rust are utilizing it. It should be totally possible to write much easier to understand frameworks and code - potentially with the limitation of using a classical thread per request architecture which avoids most of the async/lifetime/pinning pitfalls. The main drawback seems that such frameworks seem out of favor in Rust and thereby not available or not very well maintained.
Nevin1901 4y ago
For apps where performance is key, I found you can get by using go for an MVP. Apart from the spikes in cou usage because of the garbage collector, go is fast and allows you to iterate quickly.
jeremychone 4y ago
Well, we are doing just that, building a new venture with Rust because we think it is transformative in our field. Will post our findings in a year or so.
aman262 4y ago
I don't understand the rust fandom. You probably just don't need it.
PaulHoule 4y ago
I can't get it why people would prefer to add "?" to everything instead of just having exceptions which automate that behavior. In the bad old days of C there were two kinds of programs: programs without correct error handling, and programs where half the loc are unhappy paths that do what exceptions do... with a huge amount of work. Today people are repeating the same mistakes of the past, putting a "?" on everything is a lot better than what you had to do in C, but why do that when you can just use a language with exceptions? It is like somebody showed cavemen fire (exceptions) and they decided it wasn't worth anything and went to go screw around with other things.
- marcosdumay 4y ago
  > It is like somebody showed cavemen fire (exceptions) and they decided it wasn't worth anything Oh, it absolutely can not be that the Rust way is more powerful and you didn't understand it yet. No way. It's all those other people that don't understand the old concept that almost all of them know.
- jeremychone 4y ago
  After a couple of years of coding Rust, I found the error system, including the ?, well thought out. It is explicit and clear that the error is or maps to the function return error. The only thing is that Rust rightfully uses the ? to return early system on option as well, which removed the ability to have None coalescing with "?". This was the right choice from a language point of view, but I wish there would be a None coalescing syntax in Rust.
- nemothekid 4y ago
  I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.
  - jb1991 4y ago
    In Swift, at least, the possibility that a function can throw must be marked as part of its signature, and the exception cannot be ignored if it is thrown so the call requires explicit syntax as well, so there is no way to miss that something could "blow up" when reading the code.
mrichman 4y ago
So in his opinion, choosing Rust is a premature optimization?
- aisrael 4y ago
  Author here - yeah, that's how I feel about it, at least for startups specifically.
  - jeromenerf 4y ago
    ... then however, how do you feel about tech debt with Rust? My feeling was that go, rust and such left a lighter burden on the future than say ruby. Do you think you will need a major rewrite soon?
    - aisrael 4y ago
      To me, the language agnostic answer to reducing tech debt is having a good test suite so refactoring is easier. We're pretty good on that front. We have definitely done large refactors before, and I'm sure we'll have more in the future, but I don't think we need a major rewrite or anything like that.
    - ReflectedImage 4y ago
      As long as you know what you are doing Ruby won't leave you with more technical debt than Go or Rust. How many people know how to effectively program in languages like Ruby is another question altogether...
  - mrichman 4y ago
    What if your startup is in the embedded systems space, for example? I don't think you'd be doing your MVP in Python.
    - distcs 4y ago
      Why impose the "embedded systems" space requirement on the OP? The OP does not work in embedded systems space. So it is not relevant to this article. The OP is telling us what they would do, not what you should do and definitely not what embedded systems startups should do.
draw_down 4y ago
The doc about pinning seems really good. But I don’t understand what about it is necessary for something like middleware. Glad Rust is working for others, and I find it interesting to read about. but I don’t know if I could or would ever use it myself.
newaccount2021 4y ago
[dead]
TuringTest 4y ago
Rust is a systems language, not a business language. If you're building an operating system or a software platform, to for it; the robustness will pay for itself in time to fix hard-to-find errors. But if you're iterating fast to find out what the program should be about to begin with, use a prototype-friendly language instead. With garbage collection.
- drdaeman 4y ago
  Well, I had some difficulties writing a tiny init program for a container because process and signal handling are currently in a pretty weird place in Rust.
- rrishi 4y ago
  I think if you've captured the essence of the discussion on the usability of Rust really well.
rattray 4y ago
This is something I hear a lot from other founders. Spinup time of new engineers is like 6mo+, some devs who can churn out normal CRUD product work just fine in Rails or React ~never become productive with Rust, and hiring skilled Rust devs is just crazy hard (though maybe now that Blockchain/Solidity things have cooled there may be more supply).
- rozgo 4y ago
  6mo+ is spot on. This is true for most dev work that deviates from the CRUD path. Like gaming, simulation, robotics. We might as well use the time to train them in Rust too.
- dochtman 4y ago
  N = 1, but at startup scale we have definitely not had a hard time hiring skilled Rust devs. Just go on /r/rust and advertise your (non-crypto) job and get a lot of inbound. (We were specifically looking for remote folks near EU time zones, maybe local in SF is harder?)
- unshavedyak 4y ago
  > and hiring skilled Rust devs is just crazy hard (though maybe now that Blockchain/Solidity things have cooled there may be more supply). Sidenote, we hire Rust at a small shop (~30 devs?). Ironically i've found it _easier_ to hire for Rust. You're totally not wrong, BUT, the quality of the candidates that apply is quite high in our experience. I suspect it's because we get a lot of passionate people. We don't have to weed out as many candidates. With that said we don't aim for super senior devs. We're happy to hire a junior, etc. I care much more about the quality of the person than raw experience. With that said traditional hiring avenues have not been fruitful for us. Word of mouth, Rust community job posting, etc have been most fruitful by far. Probably due to exactly what you said.
  - secondcoming 4y ago
    > With that said we don't aim for super senior devs. We're happy to hire a junior, etc. I care much more about the quality of the person than raw experience. Being young and cheap is a good quality, I suppose. Experience is overrated.
dom96 4y ago
I have the same impression of Rust: great for software that is well scoped/defined and needs to be stable and efficient, not so much for quick iterations (which for startups is important) and software that doesn't need top performance. I think in general that the Rust hype has outgrown what it's good for. If you're writing a web app in Rust then you may want to ask yourself if you're making the right choice.
- tcfhgj 4y ago
  > If you're writing a web app in Rust then you may want to ask yourself if you're making the right choice. ok, I did ask myself this, still going with Rust there ;-)
- jeroenhd 4y ago
  For simple applications, Rust is actually pretty easy to work with in my experience. You don't get a lot of comforts other languages provide, but you don't always need those. The performance difference between a Rust server and other languages are incredible, especially in terms of RAM usage and concurrent connections per second. That said, if your program is going to need tons of entities stored in a database, I wouldn't even consider a language or framework without a solid ORM. Rust has some ORM-lite libraries but I'd end up picking a garbage collected language in practice just because of the difficulties that low level programming bring to such middleware. Iterating in Rust isn't that hard as long as you don't try to cheat your way out. Instead of returning null for methods that you haven't implemented, add a todo!, etcetera. You have to do things somewhat right the first time. I think that's good, because there's nothing as permanent as a temporary proof of concept. You can clone/copy your way out of most annoying Rust restrictions at the cost of performance you'd otherwise sacrifice by picking a higher level language anyway. If your startup doesn't know what it's building, you have bigger problems than the language you choose.
  - dom96 4y ago
    > The performance difference between a Rust server and other languages are incredible, especially in terms of RAM usage and concurrent connections per second. Really depends on what "other languages" are here. If you're comparing against Python then sure, but if you're comparing against Go then the difference isn't that incredible. > That said, if your program is going to need tons of entities stored in a database, I wouldn't even consider a language or framework without a solid ORM. This is actually what I used Rust for recently and honestly the ORM situation is pretty good. The language itself is just too rigid for this kind of work for too little payoff. > If your startup doesn't know what it's building, you have bigger problems than the language you choose. That's true at a high-level, but iterating on small features/changes fast is what makes or breaks most startups.
bayesian_horse 4y ago
How much more performance do you need to get from Rust over Python (even Cython, PyPy, Numba, etc) to justify the extra development cost? A 2x gain is certainly not worth it. A 10x gain? Maybe. But that is hard to achieve when much of your "compute" is spent on the DB side of things. How many startups actually scale out of needing a few non-db instances?
- soggybutter 4y ago
  My team helps run and deploy a python service that is entirely CPU bound. It accepts an input, performs some computation, and returns a result without any sort of I/O outside of the initiating HTTP request. In the past week it's averaged around 144 req/s with a p95 latency of ~1s. We average ~80 "instances" to maintain this level of performance. I have very little doubt that, if given the opportunity to rewrite this in rust, we could smash 10x perf improvements. Could we also get more perf out of tuning our python code better? Definitely. Do I think there's 10-20x improvement waiting to be uncovered? No. Unfortunately (fortunately?) we're at a stage that it makes more sense to throw ludicrous sums of money at it than it does to ground up rewrite.
- adastra22 4y ago
  Rust easily gets 10x improvement in performance over Python in a lot of applications. This is absolutely my experience. A better statement is that it doesn’t get 10x improvement over Go, or other ergonomic compiled languages.
  - steveklabnik 4y ago
    Also in the context of cloud spend: way way way less RAM, which can translate directly to dollars.
    - cozzyd 4y ago
      Yeah, I just wrote a simple daemon in C that had no performance requirements ( listening to a udp socket and dumping stuff into a pgsql db once a minute) because the Python program would use like at least 20x the RAM. When you're running a bunch of things on a resource constrained place (e.g. a single computer that has to do a ton of things sitting on a rack on the Greenland ice sheet), even just the base Python memory usage from a new process adds up...
rozgo 4y ago
In startups and projects where Rust is a premature optimization this makes sense. But, some startups and projects are all about the competitive advantage created by optimizing from day one. In these cases, choosing Rust and other early optimizations is the main enabler of a unique product.
tegiddrone 4y ago
I worked with a shop that wanted to use Rust for their shiny new MVP. And they did... and yes we were not really good at training nor could prioritize/attract rust-experienced devs. The Lead rust dev left due to personal reasons and then we were left with a codebase nobody really had the knowledge/insights to support while rapidly iterating. We smiled and rewrote it in node.js. I think devs get burned when the MVP turns into forever code and somehow are not given room to refactor/rewrite once validated... or they are surrounded by devs who are used to pain/bug-cycle and they (or the business) will accept doing things haphazardly as a cost of doing business. Fred Brook's Second-System effect comes to mind. Ah ha! Rust! Now we HAVE to write good code because rust has so many protections!!
- tijsvd 4y ago
  Never combine new tech with new functionality. If you want to learn new tech, use it to rewrite an old project that was due anyway. If you want to build new functionality, use tech that you know. This has nothing to do with Rust. I've seen the exact same thing happening with golang in a C++ only environment. Long project, took forever, failed slowly, took a week to rewrite in C++.
- jeroenhd 4y ago
  I can't fathom why a company would write code in a language that most of its developers aren't at least somewhat experienced in. If you're writing a program in Rust, hire Rust devs or invest heavily in educating the devs you do have first.
unshavedyak 4y ago
So.. i'm going to disagree, Rust (or any language!) is fine for prototyping. The trick is don't experiment when you're needing to rush a product out. Pick what you and your team is most comfortable in. Avoiding allocations in Rust, on purpose, and being uncomfortable with how to solve design challenges caused by hyper optimizing your code .. is not a Rust problem. Or an any language problem. Rust gave you rope and you hung yourself with it. If you're stubborn and you want to use Rust but aren't familiar with the ways to avoid this; Allocate. Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages. Some might reply "Well then why use Rust!?", to which i would reply because i like it! I love Rust, but if i'm prototyping code i'm not going to write insanely abstract generics either. Why would i? I don't know the problem i'm solving yet, so how can i write truly generic abstractions to solve said problems? Performance is similar. I'll use lifetimes will prototyping in the simple cases, which is most to be honest, but beyond that don't hyper optimize. To summarize: Choose your favorite language at crunch time. Even if your favorite language gives you rope to hang yourself with you probably don't need to.
- dgb23 4y ago
  > Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages. I very much doubt that. It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes.
  - maleldil 4y ago
    > It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes. What are you comparing it to? I believe parent meant that even if you clone everywhere, your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java. One thing to note is that C++ code tends to allocate all over the place from copy assignment and constructors, and it's still very fast. Rust only forces you to be explicit when cloning, but memcpy is still a fast operation, unless you're cloning large structs.
    - 4y ago
ParetoOptimal 4y ago
> I can't get it why people would prefer to add "?" to everything instead of just having exceptions which automate that behavior. Good question... Maybe... Because with exceptions it's easy to end up with missing cases or unhelpful catch-all exceptions. Typically with optional values I find that this is not the case for some reason. Other interesting links I've yet to consume that may help us get closer to an answer this: https://news.ycombinator.com/item?id=22225170 https://news.ycombinator.com/item?id=22225170 - "You're better off using exceptions" https://softwareengineering.stackexchange.com/questions/405038/result-object-vs-throwing-exceptions https://softwareengineering.stackexchange.com/questions/4050... https://dannyvanheumen.nl/post/why-i-prefer-error-values-over-exceptions/ https://dannyvanheumen.nl/post/why-i-prefer-error-values-ove...
weavie 4y ago
I've been writing Rust professionally for a few years now and if there's one thing I've learned it's that if you ever write a function that takes a parameter of `impl Fn(&Vec<&'a str>) -> &'a str` you are going to be in for some pain. Just make it `impl Fn(&Vec<&str>) -> String`. It is highly unlikely that the extra allocation is ever going to be noticed in the performance. Just because Rust pretty much forces you to be explicit about your allocations doesn't mean you have to avoid them at all costs.
- BaculumMeumEst 4y ago
  [flagged]
  - bruce343434 4y ago
    thanks for running this through chatgpt for me
    - BaculumMeumEst 4y ago
      [flagged]
- jossclimb 4y ago
  A lot of programmers will look at '`impl Fn(&Vec<&'a str>) -> &'a str`' and think what the hell is that, alien hieroglyphics?
  - nequo 4y ago
    Loosely speaking, it’s a type signature for a function that 1. takes an immutable reference to a vector of strings and 2. returns an immutable reference to a string, 3. with the constraint that the strings in the input vector must not be freed before the result is freed. It’s a reasonably concise way of saying all that.
    - kazinator 4y ago
deleted 4y ago
[deleted]
zeroxfe 4y ago
If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a fantastic language for many purposes, but it has a very high development cost.
- wyager 4y ago
  Precisely. If you like what you see in Rust but you don't need to worry about extremely strict hardware/memory/realtime constraints (i.e. you could use a memory-managed language), consider Haskell instead.
- Animats 4y ago
  > If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. It ought to be used more for high-performance games, but the game infrastructure isn't there yet. Unreal Engine is C++ and Unity is C#. Rust has Bevy and Rend3, but they're not AAA title ready. Perhaps Rust is fighting the last war - the mess inside C++.
  - WJW 4y ago
    There is probably a good space for Rust in writing the databases, caches and all sorts of proxies as well. I agree though, for most of the stuff I need for $DAYJOB the speed is nice but hardly required. It doesn't really matter if I can generate a HTTP response 50 microseconds quicker if the response then has to travel over the internet for 20+ milliseconds.
RcouF1uZ4gsC 4y ago
Question for HN, all things being equal (you are not more familiar with one language/framework) what language would you choose to build a startup in?
- orthecreedence 4y ago
  The language you're most proficient in that has a somewhat decent community.
- adastra22 4y ago
  Go. Swift if it was Apple ecosystem. Rust only for very specific tooling as required.
- alfalfasprout 4y ago
  The one appropriate for what you're trying to build. It may mean multiple languages. Not everything is a CRUD mobile app trying to be the next tinder for cats.
- marcosdumay 4y ago
  That's not a good question. There is no reason to pick one language over another if you don't even know what software you will write.
- ParetoOptimal 4y ago
  Edit: Had just woken up and didn't notice "you are not more familiar with one or the other". Hm, will have to think on that one. Haskell. I know it best and know at least 10 people I could hire that also know it. I can be as safe or as unsafe as needed where it's needed and get good performance without thinking about it most of the time.
- abledon 4y ago
  typescript
- distcs 4y ago
  Python or Go or a mix of both. I have seen new devs with no experience in either get get up to speed quickly in both. For a startup, velocity is critical.
it 4y ago
You can also get match in any variant of Erlang or ML, and those don't force you to jump through hoops for borrow checking.
- david_allison 4y ago
  Also Kotlin: `when` or `with...when` for more complex matches
ReflectedImage 4y ago
If you are writing high performance code use Rust. (Slow development times, high performance) If you are writing a typical business application use Python. (Fast development times, low performance) Or if you want to be clever do a hybrid of both. Create Rust modules for your Python code. This is just about selecting the right tool for the right job.
- pjmlp 4y ago
  I would rephrase it as follows, If you are writing high performance code where a tracing GC isn't an option, and there are SDKs available use Rust. Otherwise an AOT compiled language is a better option, and if not, and there are only C and C++ SDKs available, also factor in the development cost of creating wrappers in Rust, before doing the actual development activities. If there is too much money being burned in wrapper libraries, maybe that isn't the best option as well.
- npn 4y ago
  I picked Crystal so I didn't have to choose.
  - ReflectedImage 4y ago
    That's in the C / C++ / Rust bucket due to the typing system.
synergy20 4y ago
Maybe nowadays we should all use glue-script + compiled-ffi to iterate fast while keep performance under control? e.g python+cffi, or python+pyo3(for rust), or even lua+capi? do we really need code everything in compiled language these days? the cold path can be dealt with by scripting languages, and let the c/c++/rust/etc to handle the performance critical path instead.
- pjmlp 4y ago
  Nowadays? That is how AOLServer used to be, and all the other scripting languages developed as Apache plugins, back in the 2000's .com wave, like mod_perl and PHP.
  - synergy20 4y ago
    Maybe scripting language was overused down the road? i.e. to use it for everything, and use them like a compiled language(ruby in rails, php framework, django,etc) that made things slow? point here is that to restrict script languages to glue logic for the most part, and always remember to use ffi for heavy lifting, not sure how to balance both yet.
    - cneu 4y ago
      The main reason why server-side stuff is slow is poor use of the database. Doing e.g. nested loops in a compiled language uses way less CPU than a scripting language, but it should be done in the DB in the first place.
    - pjmlp 4y ago
      That is why PHP eventually got a JIT, initially thanks to Facebook experiments compiling to C++, and later the JIT proving being capable to generate similar performance. The problem was exactly that overused, without JIT/AOT in the box, with many people shying away from writing native extensions, instead adding more boxes. The difference between doing JavaScript in node with native extensions in 2023, and Perl/TCL with native extensions in 2000, is exactly that, a JIT.
pjmlp 4y ago
Really, unless one needs deployment scenarios where any kind of automatic memory management is not an option, there are several compiled languages with Rust like type systems and much better workflows. Go pick OCaml, Haskell, Scala or Kotlin with GraalVM or OpenJ9, F# with NativeAOT, Swift, Nim, D, whatever.
rwaksmunski 4y ago
I don't know, I haven't had a fight with the compiler in a long while now. On the other hand a $42 dedicated box benchmarked my project's REST API at 270,000req/s. I don't even use a DB, just structs serialized in JSON to a disk and a NAS once every few seconds. One pet IPv6 only server to manage + CloudFlare (Domain, DNS, Cache). Beats today's peak complexity setups, hands down.
royjacobs 4y ago
My biggest pain point with Rust (in a startup context) is that Rust works really well, until you get to anything related to threading or async. Yes, the claim is "fearless concurrency" but you'll still deadlocking mutexes and once you're heavily into async you need to start using language constructs that feel REALLY awkward, like pinning, runtime checks like RefCell, and so on. IMO if Rust could make that whole aspect of the language more elegant, it'd be much easier to scale up to a larger org.
- dcow 4y ago
  I honestly think Swift nailed it. Swift's async/await is a pleasure to work with and has the required language/runtime/stdlib support to feel natural and empowering instead of ridiculous and suffocating.
bryanlarsen 4y ago
I disagree, I believe that Rust is a fabulous language for early prototypes. Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that. Instead your prototype evolves into your product and early expedient decisions you made that were appropriate for a prototype aren't appropriate for your product and you have a significant refactor. And Rust is the best language I have ever encountered for refactoring. Just bang away changing the code until it compiles, and it's quite likely that once it compiles it actually works. That's not an experience I've had in any other language. Usually a significant refactor exposes some foot-guns that don't fire until significantly later. So you avoid refactoring and your code ends up a right mess.
- crispinb 4y ago
  > But nobody ever does that. Please don't report your own experience samples as plain universal facts. It is one of the more common means by which falsehoods spread. I have no doubt that's not your intention, and you believe what you write, but you cannot have a basis for such a bald statement, and it happens to be false. I have seen prototypes built and discarded very frequently. Indeed in an earlier incarnation it was my own professional focus. I have no idea how common it is in your country, or globally, or in specific industrial sectors. Usable stats in tech are hard to come by (in large part because of its ubiquity). But your statement is just false, and commonly repeated.
- mike_hearn 4y ago
  Have you tried something like Kotlin? It has the same experience IMO of being very easy to refactor, especially because the IDE can do so many refactorings for you very fast, and because the compile turnaround time is so low.
- jay-barronville 4y ago
  > Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that. You can’t be serious. I’ve seen prototypes get thrown away all the time, especially at startups. In fact, I’d say that’s more common than not.
- 4y ago
throwawaygal7 4y ago
People who are really interested in rust tend to be top-tier developers. I don't think they're consciously lying about their experiences working with the language but they may not hit the speed bumps that normal people would. My personal abilities make me competent in golang, ruby, python, java, c++. I love the quasi-functional styling of rust but whenever I've tried to build small projects in it I've gotten bogged down in fighting with the compiler in ways I never do in the former. It is fast as all get out tho!
throwawaygal7 4y ago
Die hard rust fans often minimize the very real developer difficulty incurred by their language of choice. Even major library maintainers in rust have criticisms of various language features because of their difficulty to use. These are real and substantiative concerns that would affect any development team not made of expert rustaceans. Just look at basic dynamic programming implementations in a normal language versus rust for say popular leap code questions and you'll see the difference in basic developer productivity.
steveklabnik 4y ago
Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (embedded) but we use it for web backend cases as well. Iteration time hasn’t been an issue, but compile times can be annoying. Though obviously compile time is related to iteration time. Of course, all of these things are anecdotal. Collecting anecdotes is how you develop evidence, of course…
- efficax 4y ago
  I'm also at a startup using rust. It's true that the feedback loop can sometimes feel bit slower. One thing that helps here is being test driven so that you're not waiting for compiles just so you can click through to confirm a small change in behavior. But in general I think my velocity is not much slower than it was at a previous company using a node backend. The hardest part of software isn't typing in the code and making sure it runs. It's thinking about what it should do and how it should do it in the first place. And really, Rust's type system is a force multiplier. We can prototype really fast, throw out things and rework them with confidence because with well thought out typing and tests to confirm logical behavior we have strong safety guarantees. It lets you experiment and investigate alternative implementations fearlessly.
- faitswulff 4y ago
  Do you mind my asking what frameworks you're using in Rust on the backend, if any?
  - steveklabnik 4y ago
    We ended up building one https://crates.io/crates/dropshot https://crates.io/crates/dropshot Happy to talk about anything!
    - faitswulff 4y ago
      Oh this supports OpenAPI! That's exciting. I'll definitely check this out when I have a chance. Thanks!
rdtsc 4y ago
It's great when wanting to play with cool new technology combines with implementing a viable product to sell to customers. But those two things don't necessarily go together. Quite often they are at odds with each other, and then you have to pick one or the other: either we spend resources playing with cool technology, or deliver a product customers will buy. Neither is wrong if it's your own resources, it's just important to understand that there is a trade-off involved.
- dcow 4y ago
  Exactly. "Rust wasn't the right choice because we spent too much time and resources playing with it." is not an argument against Rust. It's an argument against learning a new technology while looking for PMF. There's nothing inherent about Rust that makes it a poor choice to build a first iteration of a product with.
jakswa 4y ago
I remember reading about PropelAuth somewhere and thinking that Rust might slow down development -- something I wanted to be proven wrong about since I've been learning rust off and on, and like some things about it. It seems it's ending up up a mixed bag, and the negatives in the bag are still light enough that you're carrying it forward. Thank you for this blog post!
mamcx 4y ago
> Perf is easy when you have AWS credits. One reason that you might pick Rust is for overall performance. Interesting: Rust save money but that mean effort!
- marcosdumay 4y ago
  Even on the cloud, Rust will only save you money if you have enough users. But the effort is upfront. Unfortunately, the cloud isn't a very good environment for mixed-languages deployments (unless you stick to the most basic services), so you have to make a decision on the very beginning and stay with it.
dhbradshaw 4y ago
We have a fairly complex app with a front end in Typescript and a back end in Rust backed by Postgres on AWS. My favorite part of the job is coding in Rust and we do a lot of cool things in that backend code. Unfortunately, most often the Rust code is the fastest and easiest part of a change, which means that I spend most of my time solving problems either on the front end with Typescript or on CI and infra type things rather than the Rust part. It's a bit sad: if something just works, you spend less time on it than on the hairier things.
- EVa5I7bHFq9mnYK 4y ago
  Backend code is simpler because is has two limited well defined surfaces (API for the frontend on one side and database on the other side). Frontend is harder because it has to interface with those impolite hairy meat creatures ...
  - dcow 4y ago
    Frontend code has two as well: the input methods (mouse, keyboard, screen) and the API surface. > Backend code is simpler I hear this every once in awhile and think it's mostly a front end happy hour misrepresentation that makes everyone feel good so it gets repeated. The service layer of an application is very often far more complicated than, or to be fair, at least as complicated as, the user interface. Front end devs just typically aren't good at chopping up their problem into nice interfaces and therefore struggle to test it reliably or make large broad changes efficiently. This is where the complexity comes in. That's not a stab at FE devs, it's just not a skill that often gets rewarded in FE work so it's not very prevalent, which I find sad. The service layer has to deal with enforcing the correctness of business logic despite the infinite ways the meat monkeys can interact with it. It does this by defining clear boundaries on the outside and by ensuring the transactional correctness of logic on the inside. While front end folks have to figure out the correct UX to use to successfully communicate with with a user, service layer folks have to figure out all the implications of a single action the user wishes to take and make sure it happens correctly. Data validation, data modeling, transactions, errors, queuing, retries, scaling, monitoring, etc. are all things that would probably make the average FE dev explode if thrust upon them.
jmull 4y ago
Since safety was the first reason given for using rust, I'll just point out: There are other safe languages. I think it's a really useful thing to have from day one, but it doesn't particularly point you to rust. Also, performance is really about learning what your bottle-necks are, profiling them and optimizing them. You probably have no idea what those are when you start, so it's not really the right time to try to solve it. (There's a decent chance, e.g., that your inner loops won't even be in code you write, like the database.) Probably the best thing you can do for long-term performance up-front is to try to stay flexible, and try to keep your architecture simple.
- ReflectedImage 4y ago
  Rust does a bit more on the safety front than typical programming languages.
  - dcow 4y ago
    Really? I guess if your typical programming languages are C and C++. Otherwise Rust just has semantics that allow more control over memory, as is often needed in lower level programs, while preventing pointer aliasing. The majority of languages in existence are memory safe--some even more so than Rust. They're just not as flexible.
    - ReflectedImage 4y ago
      It's much better than Java, Kotlin and C#. The borrow checker detects the majority (~95%) of concurrency problems. We don't have that many single core CPUs lying around anymore. It's got a story on high performance, high concurrency programs which is significantly better than anything else I've seen so far.
      - dcow 4y ago
        I'll give you that. The reason I questioned is because in my experience with those languages the 95% problem is not the actual data consistency rather it's locking and synchronization hell that results from needing to make your program threadsafe to ensure data consistency. Rust says, don't get yourself in a situations where you need to do that in the first place, it's not safe. Just clone the data or leak it read only or Cow it. What Rust does is great, it sets you up so you're never sharing references across threads unless you try really really hard. And that's the source of needing manual synchronization the majority of the time. However, when you do need locks, Rust doesn't do anything to help. In other words, if you copied a Java program to Rust with object instance pointers all over the place, I bet it would feel just as bad in Rust. So I tend to think of that more as "thread safety" than "memory safety". But we might just be arguing semantics at this point. I agree Rust is far more of a pleasure to work in than Java and C#.
estebank 4y ago
I find it surprising that so many people are arguing about the benefits and drawbacks of `?`, when in my experience the handling of Result and Option haven't been an issue in practice on the consuming side (`?`, `.unwrap()`, `.map()`, `.ok()`, if let, match, let chains, let else, etc. help a lot), but where all the pain comes from is having to declare the appropriate error type itself. Libraries like `anyhow` takes some of the pain away, but declaring an appropriate struct or particularly an enum in the right places, and the boilerplate for all the type conversions (From/Into impls) are where, during development, I have frustration. What I do then is either use Result<T, ()> or a single `struct Error(String);`, and go back once I have all the scaffolding in place and pry the implicit error tree back into the type system. Anonymous enums like typescript (`A | B | C`) could presumably help here.
- lenkite 4y ago
  All these workarounds for easier Result handling truly make me wonder whether Rust will eventually evolve exceptions as a feature - of-course without explicitly terming them so.
  - steveklabnik 4y ago
    The community would revolt. Not going to happen. Proposals to make the existing syntax and semantics even look more like exceptions were met with lots of hostility.
    - FpUser 4y ago
      Revolt how? Go back to C++ or whatever language/s they were using?
      - steveklabnik 4y ago
        I don't know exactly, but it's never pretty when a project's leadership makes an unpopular decision. Lots of complaining, for sure.
  - 4y ago
Ylmaz 4y ago
I like this quote from 'The art of Unix Programming' published in 2003 "While it still makes sense to write system programs and time-critical kernels of applications in C or C++, the world has changed a great deal since these languages came to prominence in the 1980s. In 2003, processors are a thousand times faster, memories are a thousand times larger, and disks are a factor of ten thousand larger, for roughly constant dollars. These plunging costs change the economics of programming in a fundamental way. Under most circumstances it no longer makes sense to try to be as sparing of machine resources as C permits. Instead, the economically optimal choice is to minimize debugging time and maximize the long-term maintainability of the code by human beings. Most sorts of implementation (including application prototyping) are therefore better served by the newer generation of interpreted and scripting languages. This transition exactly parallels the conditions that, last time around the wheel, led to the rise of C/C++ and the eclipse of assembler programming."
- apozem 4y ago
  That's a great way of looking at it. Languages all have benefits and drawbacks, but you have to consider whether they help you for your problem. One time, I met a guy who wrote firmware for Seagate hard drives. Any new feature he added had a budget measured in microseconds. Obviously he wrote nothing but C++.
- dilippkumar 4y ago
  In a benchmark of how many fortune responses are returned by various web frameworks[0], nodejs returned 80k odd fortunes per second. The fastest c++ framework compared here returned 616k odd fortunes per second. Assuming that my application scales by the same amount (big assumption, yes), I could cut AWS costs by 7.7 times (!!!) by using the C++ implementation. I'm pretty sure that maintaining a C++ codebase is less than 7.7 times more expensive than Node, even if you throw in extra development time etc. This also ignores the decades worth of excellent tooling we've built up for C++ (static analyzers, fuzzers, etc). At a startup, when building things fast matters more than costs, sure. I buy the argument for Node or Python or any other interpreted backend. But once you start to scale, things change after some threshold. Unless you're facebook[1]. [0]. https://www.techempower.com/benchmarks/#section=data-r21 https://www.techempower.com/benchmarks/#section=data-r21 [1]. https://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/ https://developers.facebook.com/blog/post/2010/02/02/hiphop-...
kilgnad 4y ago
Rust is weird. It has high level features that make is superior to high level languages like go and python. But the low level features like default move semantics inevitably make it harder. IMO there is merit in making a language that is equivalent to garbage collected rust by default with ownership rules similar to python. Then the classic rust based ownership and allocation schemes are all opt-in syntax-wise in the same way Box is opt-in.
frodowtf 4y ago
The reason why people would like to pick Rust is because of its ergonomic features like sum types, streams and of course the toolchain. But here is a claim: Most business-level programmers are not ready for dealing with the borrowing and ownership concept. They don't want to care about reference vs. value types. They can't do memory management efficiently, because most of them have never used a language without GC. With Rust you would need to care more about memory which is not necessary for most use cases in startups.
dcow 4y ago
I don't agree. I think the author is conflating two things: 1. learning Rust, and 2. using Rust. If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early. The iteration time issue with Rust is solved by experience. We use Rust and our iteration times are average. What we gain is not performance, that's not a reason we use Rust (for an early stage startup, totally agree you burn credits until you can afford to care). We gain correctness. And at an early stage, correctness without paying for a massive QA team is a huge boon. There are definitely more mature tools for quickly standing up CRUD APIs. If you want a framework that can bootstrap you into an OpenAPI with docgen, swagger, all the bells and whistles, Rust doesn't do that. But Rust will help force you to write correct code that never crashes and handles edge cases it's easy to forget about when moving fast in a duck typed language. The only language we seriously considered over Rust was Swift. But Swift's just wasn't quite there yet. It might be today. If I was starting something from ground zero today, I'd probably lean towards Swift and need to be argued down back to Rust or Python.
- Sodman 4y ago
  The author touches on why it matters in the article - either you have to restrict hiring to folks who are already rust experts (much smaller hiring pool, also usually meaning higher comp expectations) - or you have to consider the cost of training new/existing staff on Rust. Rust has a notoriously difficult learning curve, especially to folks who don't have a background in C/C++. As the author mentions, you may be looking at 6+ month ramp up time until new hires can comfortably write non-throwaway tech-debt free production code. For many startups looking to iterate quickly, that's just too slow. Conversely if you are looking to hire Java folks, you'll have an enormous pool to pick from, or if you need to train somebody in eg Go - you can do that significantly quicker than you could with Rust.
  - dcow 4y ago
    I was putting that argument aside because that's an argument you can make for any language and it changes depending on who you know, what circles you're in, etc. It's and externality not specific to Rust. You can say the same for Erlang, or Swift, or C#, or ...insert language that isn't JavaScript. What I'm saying is that, disregarding the externalities, I've found Rust to be quite a boon and not inherently a bad fit for an early stage. YMMV.

253 points by aisrael 4y ago

Performance of language is almost never a big concern, but it’s so interesting for a technical person.

I write a lot of Rust. I think you can do a startup in rust but you need to explicitly go against the natural inclinations of rust. Rust is a great language partially because it cares about the details. It’ll do stuff like distinguish between Path and String because it treats the edgecases as important. In a startup that’s not really a priority. In fact focusing on edgecases and doing things the “right” way is completely not the point of writing code in a startup. Rust is also a great language to refactor, something that’s also not ideal for a startup to be spending cycles on. Would I do a startup in rust? Maybe. It’d depend on the idea. But I’d take measures to avoid the natural orthodoxy of Rust.

Aissen 4y ago

Crazy to think that cloud credits, in addition to distorting the hosting competition, might also distort the language choice competition…

ReflectedImage 4y ago
The first hit of cloud is free but once they have you hooked they charge an arm and a leg afterwards.

dmillar 4y ago

Perhaps not the case here, but there are a couple of things I would add to this sentiment. First, if you love Rust uniquely, I'd argue it might still make sense to use Rust to build your first product iterations. If your initial team commonly loves Rust, and can't agree on "love" for another common language, perhaps Rust is the best language. Burnout will happen exponentially faster if developers are lamenting the language (n.b. Rust is commonly lamented). I think there are enough language/platform options these days for this to be an unlikely scenario, but this is to say don't discount your passion for a language because it doesn't iterate fast enough. Second, if the problem your startup is trying to solve is solidly in the performance and security realm, it makes sense to start in Rust. If your pitch is something like "pandas but fast and memory efficient" it also makes sense to start your project in something like Rust.

andrewstuart 4y ago

"I find myself missing match in pretty much every other language I go to." Python has match, is this the same thing? https://blog.teclado.com/python-match-case/ https://blog.teclado.com/python-match-case/

shmerl 4y ago

That has a catch 22. If you aren't going to start with Rust from the beginning, switching to it later becomes too costly and too difficult, which defeats the argument of it being useful in general. Most often what's used in the beginning as "prototyping" is cemented into the system to the point that it's hard to change it. So yeah, better to deal with complexities in the beginning and save on switching later, than not to use it all.

japhib 4y ago

For pattern matching and expressiveness in a backend language that lets you iterate quickly, I'd highly recommend Elixir.

innocentoldguy 4y ago
I would reach for Elixir, Phoenix, and LiveView for any new web development. We were using Java before and were running into major productivity issues. After extensive testing with Elixir, Node, Clojure, Go, and a handful of other languages, Elixir won out, we rewrote our entire stack, and our productivity skyrocketed. I can’t say enough good about it.

mixmastamyk 4y ago

Yes, many times "typing supremacists" and pedantic folks will recommend this course of action but it is not a great idea much of the time as the piece illustrates. Getting things perfect on a code-level up front is rarely what a new project needs. A more effective strategy for business is to instead prototype in something like Python—that's what it's for. This was known back in the 90s, and been somewhat forgotten. Django too. Like a flexible clay to rapidly sculpt to a first approximation. Then: 1) Get to product market fit, keep iterating until you do. Do not go to step 2 until that happens. 2) Get the fundamental data models right, get your fundamental software design right. Keep iterating until you do. Do not go to step 3 until that happens. This stuff is easier in Python as it gets out of your way. Yes use pyflakes, a few tests, and a code formatter to keep you honest. But not much more that that. Pycharm for example, if you need a helping hand. 3) When step 1 and 2 are a looking good, then rebuild the foundation of your gleaming skyscraper with the steel girders of rust, java, and/or other bdsm languages with an already good product and design. Step three may not even be needed if you have a CRUDdy project. Complete the typing at that time.

eYrKEC2 4y ago

We love using rust on the backend at https://mayhem4api.forallsecure.com/ https://mayhem4api.forallsecure.com/ and in our CLI. If I were the decider, I'd choose it again. Rust is a hurdle to learn, but the confidence you gain from the type system is fantastic. I've worked in other projects with different, looser-type'd languages (no names! no flames!) and despite good testing coverage, the confidence on release to prod is not as high.

AceJohnny2 4y ago

> Perf is easy when you have AWS credits. I get that the point of this article is that launching > sustaining. But I have a horror story about AWS credits for startups: a friend's startup got their account suspended for a couple days when their Credits ran out, they started getting billed 5 digits (as they expected), and Amazon's fraud detection detected this as an anomalous billing pattern and suspended them! For transitioning from AWS credits to billing!? Considering all their operations were running in AWS, and they were providing a HW-critical service to their customers, it was bad. This was late last year. This was despite getting reassurances from their AWS rep that the transition would be smooth.

ISL 4y ago
If those reassurances are in unmistakable writing, a letter from the startup's corporate attorney may yield a quick refund and compensation.
- AceJohnny2 4y ago
  Sure, but in the life of a startup that's just one extra thing they'd rather not have to deal with, and the damage isn't just financial.

legerdemain 4y ago

In my experience with Palantir "alums," none of the crotchety perfectionists I knew ended up working with Rust after leaving. I guess AI (as the author of this post is affectionately known) beat the trend by starting his own company!

twsted 4y ago

"Building a startup in Rust". I know the hype around Rust, but this is really exaggerated: you build a startup for creating a product or giving a service, not to have something written in Rust. Your customers should care about what you are offering, much more than about which language do you use.

julianeon 4y ago

I find it mystifying that one of the reasons you can supposedly pass over Rust, and avoid performance concerns, is to "take the free money." Literally. That is, the free money, in credits, that allows you to not worry about performance for a while. The obvious problem being... "What happens when the free money runs out?" It's not addressed, but the implied answer seems to be "Well, by then it'll be six months later, and..." And? And what? It's still a problem! It didn't go away. The money deflected the perf concerns for some time, maybe a year - but then it's back, bigger and badder than ever. Rust solves that by not requiring that outlay ever, by being more efficient. Seems like a very poor reason to not choose Rust, to me.

globalreset 4y ago
At that point startup has revenue so can pay or is dead so it doesn't matter.
nazka 4y ago
I am a Rust fanboy but using it to start a startup hmm unless it’s for a specific use case. No. Why? Because the biggest bill you will have to pay at first in a startup and for a long time won’t be AWS but all the (devs) salaries. And compare to what you will pay to AWS that’s a lot of money. So a gain in performance won’t matter as much as in your success (and survivability) than speed in developing new feature every week. Depending what you do but it’s usually the case that performance won’t matter until mid late game. I saw a startup at +300M valuation still not having to worry about performance for a long time. And a cut in the AWS bill thanks to using a more performant language like Rust won’t make that much a difference compare to how much they had to pay devs. So you just want a language where you can ship features fast. Also the hiring pool is still very small.

cultofmetatron 4y ago

Reading this makes me reaffirm my decision to build my startup in elixir. At the time, it came down to 3 compelling choices 1. typescript - I already had 6 years of full stack js experience. The ecosystemis full of issues but its all issues I'm used to. 2. rust - new kid on the block. the type system and speed were compelling but it was still being developed and the learning curve was brutal. Plus I was under the gun to get the mvp up. we needed to get a working piece of software up and test out business assumptions. In the end I went with elixir. Realtime sync was a huge killer feature we were aiming for and phoenix came with the best out of the box support for it. Overall productivity was on par with javascript while the functional aspects made certain types of bugs non issues in elixir. runtime performance has been more that adequate. after 3 years in production, we have only recently rolled out rate limiting and caching and only as a precaution as we've been expanding quickly. Echoing the author's sentiments, I can definitely see places where rust could be better and thanks to tools like rustler, we'll be able to bring those in piecemeal as needed. I'm sure our product would be even faster and more efficient on resources if we did it in rust but I'm pretty sure we would have more likely run out of runway before that happenned.

Matthias247 4y ago

> We have extractors for different user requirements to make adding APIs very straightforward. We have middleware for scoping requests per customer. In most languages, this is pretty standard, but in Rust, for our use case, they both require at least a rough understanding of pinning. This is more about "async Rust" and the way that the most common web frameworks for Rust are utilizing it. It should be totally possible to write much easier to understand frameworks and code - potentially with the limitation of using a classical thread per request architecture which avoids most of the async/lifetime/pinning pitfalls. The main drawback seems that such frameworks seem out of favor in Rust and thereby not available or not very well maintained.

Nevin1901 4y ago

For apps where performance is key, I found you can get by using go for an MVP. Apart from the spikes in cou usage because of the garbage collector, go is fast and allows you to iterate quickly.

jeremychone 4y ago

Well, we are doing just that, building a new venture with Rust because we think it is transformative in our field. Will post our findings in a year or so.

aman262 4y ago

I don't understand the rust fandom. You probably just don't need it.

PaulHoule 4y ago

I can't get it why people would prefer to add "?" to everything instead of just having exceptions which automate that behavior. In the bad old days of C there were two kinds of programs: programs without correct error handling, and programs where half the loc are unhappy paths that do what exceptions do... with a huge amount of work. Today people are repeating the same mistakes of the past, putting a "?" on everything is a lot better than what you had to do in C, but why do that when you can just use a language with exceptions? It is like somebody showed cavemen fire (exceptions) and they decided it wasn't worth anything and went to go screw around with other things.

marcosdumay 4y ago
> It is like somebody showed cavemen fire (exceptions) and they decided it wasn't worth anything Oh, it absolutely can not be that the Rust way is more powerful and you didn't understand it yet. No way. It's all those other people that don't understand the old concept that almost all of them know.
jeremychone 4y ago
After a couple of years of coding Rust, I found the error system, including the ?, well thought out. It is explicit and clear that the error is or maps to the function return error. The only thing is that Rust rightfully uses the ? to return early system on option as well, which removed the ability to have None coalescing with "?". This was the right choice from a language point of view, but I wish there would be a None coalescing syntax in Rust.
nemothekid 4y ago
I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.
- jb1991 4y ago
  In Swift, at least, the possibility that a function can throw must be marked as part of its signature, and the exception cannot be ignored if it is thrown so the call requires explicit syntax as well, so there is no way to miss that something could "blow up" when reading the code.

mrichman 4y ago

So in his opinion, choosing Rust is a premature optimization?

aisrael 4y ago
Author here - yeah, that's how I feel about it, at least for startups specifically.
- jeromenerf 4y ago
  ... then however, how do you feel about tech debt with Rust? My feeling was that go, rust and such left a lighter burden on the future than say ruby. Do you think you will need a major rewrite soon?
  - aisrael 4y ago
    To me, the language agnostic answer to reducing tech debt is having a good test suite so refactoring is easier. We're pretty good on that front. We have definitely done large refactors before, and I'm sure we'll have more in the future, but I don't think we need a major rewrite or anything like that.
  - ReflectedImage 4y ago
    As long as you know what you are doing Ruby won't leave you with more technical debt than Go or Rust. How many people know how to effectively program in languages like Ruby is another question altogether...
- mrichman 4y ago
  What if your startup is in the embedded systems space, for example? I don't think you'd be doing your MVP in Python.
  - distcs 4y ago
    Why impose the "embedded systems" space requirement on the OP? The OP does not work in embedded systems space. So it is not relevant to this article. The OP is telling us what they would do, not what you should do and definitely not what embedded systems startups should do.

draw_down 4y ago

The doc about pinning seems really good. But I don’t understand what about it is necessary for something like middleware. Glad Rust is working for others, and I find it interesting to read about. but I don’t know if I could or would ever use it myself.

newaccount2021 4y ago

[dead]

TuringTest 4y ago

Rust is a systems language, not a business language. If you're building an operating system or a software platform, to for it; the robustness will pay for itself in time to fix hard-to-find errors. But if you're iterating fast to find out what the program should be about to begin with, use a prototype-friendly language instead. With garbage collection.

drdaeman 4y ago
Well, I had some difficulties writing a tiny init program for a container because process and signal handling are currently in a pretty weird place in Rust.
rrishi 4y ago
I think if you've captured the essence of the discussion on the usability of Rust really well.

rattray 4y ago

This is something I hear a lot from other founders. Spinup time of new engineers is like 6mo+, some devs who can churn out normal CRUD product work just fine in Rails or React ~never become productive with Rust, and hiring skilled Rust devs is just crazy hard (though maybe now that Blockchain/Solidity things have cooled there may be more supply).

rozgo 4y ago
6mo+ is spot on. This is true for most dev work that deviates from the CRUD path. Like gaming, simulation, robotics. We might as well use the time to train them in Rust too.
dochtman 4y ago
N = 1, but at startup scale we have definitely not had a hard time hiring skilled Rust devs. Just go on /r/rust and advertise your (non-crypto) job and get a lot of inbound. (We were specifically looking for remote folks near EU time zones, maybe local in SF is harder?)
unshavedyak 4y ago
> and hiring skilled Rust devs is just crazy hard (though maybe now that Blockchain/Solidity things have cooled there may be more supply). Sidenote, we hire Rust at a small shop (~30 devs?). Ironically i've found it _easier_ to hire for Rust. You're totally not wrong, BUT, the quality of the candidates that apply is quite high in our experience. I suspect it's because we get a lot of passionate people. We don't have to weed out as many candidates. With that said we don't aim for super senior devs. We're happy to hire a junior, etc. I care much more about the quality of the person than raw experience. With that said traditional hiring avenues have not been fruitful for us. Word of mouth, Rust community job posting, etc have been most fruitful by far. Probably due to exactly what you said.
- secondcoming 4y ago
  > With that said we don't aim for super senior devs. We're happy to hire a junior, etc. I care much more about the quality of the person than raw experience. Being young and cheap is a good quality, I suppose. Experience is overrated.

dom96 4y ago

I have the same impression of Rust: great for software that is well scoped/defined and needs to be stable and efficient, not so much for quick iterations (which for startups is important) and software that doesn't need top performance. I think in general that the Rust hype has outgrown what it's good for. If you're writing a web app in Rust then you may want to ask yourself if you're making the right choice.

tcfhgj 4y ago
> If you're writing a web app in Rust then you may want to ask yourself if you're making the right choice. ok, I did ask myself this, still going with Rust there ;-)
jeroenhd 4y ago
For simple applications, Rust is actually pretty easy to work with in my experience. You don't get a lot of comforts other languages provide, but you don't always need those. The performance difference between a Rust server and other languages are incredible, especially in terms of RAM usage and concurrent connections per second. That said, if your program is going to need tons of entities stored in a database, I wouldn't even consider a language or framework without a solid ORM. Rust has some ORM-lite libraries but I'd end up picking a garbage collected language in practice just because of the difficulties that low level programming bring to such middleware. Iterating in Rust isn't that hard as long as you don't try to cheat your way out. Instead of returning null for methods that you haven't implemented, add a todo!, etcetera. You have to do things somewhat right the first time. I think that's good, because there's nothing as permanent as a temporary proof of concept. You can clone/copy your way out of most annoying Rust restrictions at the cost of performance you'd otherwise sacrifice by picking a higher level language anyway. If your startup doesn't know what it's building, you have bigger problems than the language you choose.
- dom96 4y ago
  > The performance difference between a Rust server and other languages are incredible, especially in terms of RAM usage and concurrent connections per second. Really depends on what "other languages" are here. If you're comparing against Python then sure, but if you're comparing against Go then the difference isn't that incredible. > That said, if your program is going to need tons of entities stored in a database, I wouldn't even consider a language or framework without a solid ORM. This is actually what I used Rust for recently and honestly the ORM situation is pretty good. The language itself is just too rigid for this kind of work for too little payoff. > If your startup doesn't know what it's building, you have bigger problems than the language you choose. That's true at a high-level, but iterating on small features/changes fast is what makes or breaks most startups.

bayesian_horse 4y ago

How much more performance do you need to get from Rust over Python (even Cython, PyPy, Numba, etc) to justify the extra development cost? A 2x gain is certainly not worth it. A 10x gain? Maybe. But that is hard to achieve when much of your "compute" is spent on the DB side of things. How many startups actually scale out of needing a few non-db instances?

soggybutter 4y ago
My team helps run and deploy a python service that is entirely CPU bound. It accepts an input, performs some computation, and returns a result without any sort of I/O outside of the initiating HTTP request. In the past week it's averaged around 144 req/s with a p95 latency of ~1s. We average ~80 "instances" to maintain this level of performance. I have very little doubt that, if given the opportunity to rewrite this in rust, we could smash 10x perf improvements. Could we also get more perf out of tuning our python code better? Definitely. Do I think there's 10-20x improvement waiting to be uncovered? No. Unfortunately (fortunately?) we're at a stage that it makes more sense to throw ludicrous sums of money at it than it does to ground up rewrite.
adastra22 4y ago
Rust easily gets 10x improvement in performance over Python in a lot of applications. This is absolutely my experience. A better statement is that it doesn’t get 10x improvement over Go, or other ergonomic compiled languages.
- steveklabnik 4y ago
  Also in the context of cloud spend: way way way less RAM, which can translate directly to dollars.
  - cozzyd 4y ago
    Yeah, I just wrote a simple daemon in C that had no performance requirements ( listening to a udp socket and dumping stuff into a pgsql db once a minute) because the Python program would use like at least 20x the RAM. When you're running a bunch of things on a resource constrained place (e.g. a single computer that has to do a ton of things sitting on a rack on the Greenland ice sheet), even just the base Python memory usage from a new process adds up...

rozgo 4y ago

In startups and projects where Rust is a premature optimization this makes sense. But, some startups and projects are all about the competitive advantage created by optimizing from day one. In these cases, choosing Rust and other early optimizations is the main enabler of a unique product.

tegiddrone 4y ago

I worked with a shop that wanted to use Rust for their shiny new MVP. And they did... and yes we were not really good at training nor could prioritize/attract rust-experienced devs. The Lead rust dev left due to personal reasons and then we were left with a codebase nobody really had the knowledge/insights to support while rapidly iterating. We smiled and rewrote it in node.js. I think devs get burned when the MVP turns into forever code and somehow are not given room to refactor/rewrite once validated... or they are surrounded by devs who are used to pain/bug-cycle and they (or the business) will accept doing things haphazardly as a cost of doing business. Fred Brook's Second-System effect comes to mind. Ah ha! Rust! Now we HAVE to write good code because rust has so many protections!!

tijsvd 4y ago
Never combine new tech with new functionality. If you want to learn new tech, use it to rewrite an old project that was due anyway. If you want to build new functionality, use tech that you know. This has nothing to do with Rust. I've seen the exact same thing happening with golang in a C++ only environment. Long project, took forever, failed slowly, took a week to rewrite in C++.
jeroenhd 4y ago
I can't fathom why a company would write code in a language that most of its developers aren't at least somewhat experienced in. If you're writing a program in Rust, hire Rust devs or invest heavily in educating the devs you do have first.

unshavedyak 4y ago

So.. i'm going to disagree, Rust (or any language!) is fine for prototyping. The trick is don't experiment when you're needing to rush a product out. Pick what you and your team is most comfortable in. Avoiding allocations in Rust, on purpose, and being uncomfortable with how to solve design challenges caused by hyper optimizing your code .. is not a Rust problem. Or an any language problem. Rust gave you rope and you hung yourself with it. If you're stubborn and you want to use Rust but aren't familiar with the ways to avoid this; Allocate. Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages. Some might reply "Well then why use Rust!?", to which i would reply because i like it! I love Rust, but if i'm prototyping code i'm not going to write insanely abstract generics either. Why would i? I don't know the problem i'm solving yet, so how can i write truly generic abstractions to solve said problems? Performance is similar. I'll use lifetimes will prototyping in the simple cases, which is most to be honest, but beyond that don't hyper optimize. To summarize: Choose your favorite language at crunch time. Even if your favorite language gives you rope to hang yourself with you probably don't need to.

dgb23 4y ago
> Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages. I very much doubt that. It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes.
- maleldil 4y ago
  > It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes. What are you comparing it to? I believe parent meant that even if you clone everywhere, your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java. One thing to note is that C++ code tends to allocate all over the place from copy assignment and constructors, and it's still very fast. Rust only forces you to be explicit when cloning, but memcpy is still a fast operation, unless you're cloning large structs.
  - 4y ago

ParetoOptimal 4y ago

> I can't get it why people would prefer to add "?" to everything instead of just having exceptions which automate that behavior. Good question... Maybe... Because with exceptions it's easy to end up with missing cases or unhelpful catch-all exceptions. Typically with optional values I find that this is not the case for some reason. Other interesting links I've yet to consume that may help us get closer to an answer this: https://news.ycombinator.com/item?id=22225170 https://news.ycombinator.com/item?id=22225170 - "You're better off using exceptions" https://softwareengineering.stackexchange.com/questions/405038/result-object-vs-throwing-exceptions https://softwareengineering.stackexchange.com/questions/4050... https://dannyvanheumen.nl/post/why-i-prefer-error-values-over-exceptions/ https://dannyvanheumen.nl/post/why-i-prefer-error-values-ove...

weavie 4y ago

I've been writing Rust professionally for a few years now and if there's one thing I've learned it's that if you ever write a function that takes a parameter of `impl Fn(&Vec<&'a str>) -> &'a str` you are going to be in for some pain. Just make it `impl Fn(&Vec<&str>) -> String`. It is highly unlikely that the extra allocation is ever going to be noticed in the performance. Just because Rust pretty much forces you to be explicit about your allocations doesn't mean you have to avoid them at all costs.

BaculumMeumEst 4y ago
[flagged]
- bruce343434 4y ago
  thanks for running this through chatgpt for me
  - BaculumMeumEst 4y ago
    [flagged]
jossclimb 4y ago
A lot of programmers will look at '`impl Fn(&Vec<&'a str>) -> &'a str`' and think what the hell is that, alien hieroglyphics?
- nequo 4y ago
  Loosely speaking, it’s a type signature for a function that 1. takes an immutable reference to a vector of strings and 2. returns an immutable reference to a string, 3. with the constraint that the strings in the input vector must not be freed before the result is freed. It’s a reasonably concise way of saying all that.
  - kazinator 4y ago

deleted 4y ago

[deleted]

zeroxfe 4y ago

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

wyager 4y ago
Precisely. If you like what you see in Rust but you don't need to worry about extremely strict hardware/memory/realtime constraints (i.e. you could use a memory-managed language), consider Haskell instead.
Animats 4y ago
> If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. It ought to be used more for high-performance games, but the game infrastructure isn't there yet. Unreal Engine is C++ and Unity is C#. Rust has Bevy and Rend3, but they're not AAA title ready. Perhaps Rust is fighting the last war - the mess inside C++.
- WJW 4y ago
  There is probably a good space for Rust in writing the databases, caches and all sorts of proxies as well. I agree though, for most of the stuff I need for $DAYJOB the speed is nice but hardly required. It doesn't really matter if I can generate a HTTP response 50 microseconds quicker if the response then has to travel over the internet for 20+ milliseconds.

RcouF1uZ4gsC 4y ago

Question for HN, all things being equal (you are not more familiar with one language/framework) what language would you choose to build a startup in?

orthecreedence 4y ago
The language you're most proficient in that has a somewhat decent community.
adastra22 4y ago
Go. Swift if it was Apple ecosystem. Rust only for very specific tooling as required.
alfalfasprout 4y ago
The one appropriate for what you're trying to build. It may mean multiple languages. Not everything is a CRUD mobile app trying to be the next tinder for cats.
marcosdumay 4y ago
That's not a good question. There is no reason to pick one language over another if you don't even know what software you will write.
ParetoOptimal 4y ago
Edit: Had just woken up and didn't notice "you are not more familiar with one or the other". Hm, will have to think on that one. Haskell. I know it best and know at least 10 people I could hire that also know it. I can be as safe or as unsafe as needed where it's needed and get good performance without thinking about it most of the time.
abledon 4y ago
typescript
distcs 4y ago
Python or Go or a mix of both. I have seen new devs with no experience in either get get up to speed quickly in both. For a startup, velocity is critical.

it 4y ago

You can also get match in any variant of Erlang or ML, and those don't force you to jump through hoops for borrow checking.

david_allison 4y ago
Also Kotlin: `when` or `with...when` for more complex matches

ReflectedImage 4y ago

If you are writing high performance code use Rust. (Slow development times, high performance) If you are writing a typical business application use Python. (Fast development times, low performance) Or if you want to be clever do a hybrid of both. Create Rust modules for your Python code. This is just about selecting the right tool for the right job.

pjmlp 4y ago
I would rephrase it as follows, If you are writing high performance code where a tracing GC isn't an option, and there are SDKs available use Rust. Otherwise an AOT compiled language is a better option, and if not, and there are only C and C++ SDKs available, also factor in the development cost of creating wrappers in Rust, before doing the actual development activities. If there is too much money being burned in wrapper libraries, maybe that isn't the best option as well.
npn 4y ago
I picked Crystal so I didn't have to choose.
- ReflectedImage 4y ago
  That's in the C / C++ / Rust bucket due to the typing system.

synergy20 4y ago

Maybe nowadays we should all use glue-script + compiled-ffi to iterate fast while keep performance under control? e.g python+cffi, or python+pyo3(for rust), or even lua+capi? do we really need code everything in compiled language these days? the cold path can be dealt with by scripting languages, and let the c/c++/rust/etc to handle the performance critical path instead.

pjmlp 4y ago
Nowadays? That is how AOLServer used to be, and all the other scripting languages developed as Apache plugins, back in the 2000's .com wave, like mod_perl and PHP.
- synergy20 4y ago
  Maybe scripting language was overused down the road? i.e. to use it for everything, and use them like a compiled language(ruby in rails, php framework, django,etc) that made things slow? point here is that to restrict script languages to glue logic for the most part, and always remember to use ffi for heavy lifting, not sure how to balance both yet.
  - cneu 4y ago
    The main reason why server-side stuff is slow is poor use of the database. Doing e.g. nested loops in a compiled language uses way less CPU than a scripting language, but it should be done in the DB in the first place.
  - pjmlp 4y ago
    That is why PHP eventually got a JIT, initially thanks to Facebook experiments compiling to C++, and later the JIT proving being capable to generate similar performance. The problem was exactly that overused, without JIT/AOT in the box, with many people shying away from writing native extensions, instead adding more boxes. The difference between doing JavaScript in node with native extensions in 2023, and Perl/TCL with native extensions in 2000, is exactly that, a JIT.

pjmlp 4y ago

Really, unless one needs deployment scenarios where any kind of automatic memory management is not an option, there are several compiled languages with Rust like type systems and much better workflows. Go pick OCaml, Haskell, Scala or Kotlin with GraalVM or OpenJ9, F# with NativeAOT, Swift, Nim, D, whatever.

rwaksmunski 4y ago

I don't know, I haven't had a fight with the compiler in a long while now. On the other hand a $42 dedicated box benchmarked my project's REST API at 270,000req/s. I don't even use a DB, just structs serialized in JSON to a disk and a NAS once every few seconds. One pet IPv6 only server to manage + CloudFlare (Domain, DNS, Cache). Beats today's peak complexity setups, hands down.

royjacobs 4y ago

My biggest pain point with Rust (in a startup context) is that Rust works really well, until you get to anything related to threading or async. Yes, the claim is "fearless concurrency" but you'll still deadlocking mutexes and once you're heavily into async you need to start using language constructs that feel REALLY awkward, like pinning, runtime checks like RefCell, and so on. IMO if Rust could make that whole aspect of the language more elegant, it'd be much easier to scale up to a larger org.

dcow 4y ago
I honestly think Swift nailed it. Swift's async/await is a pleasure to work with and has the required language/runtime/stdlib support to feel natural and empowering instead of ridiculous and suffocating.

bryanlarsen 4y ago

I disagree, I believe that Rust is a fabulous language for early prototypes. Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that. Instead your prototype evolves into your product and early expedient decisions you made that were appropriate for a prototype aren't appropriate for your product and you have a significant refactor. And Rust is the best language I have ever encountered for refactoring. Just bang away changing the code until it compiles, and it's quite likely that once it compiles it actually works. That's not an experience I've had in any other language. Usually a significant refactor exposes some foot-guns that don't fire until significantly later. So you avoid refactoring and your code ends up a right mess.

crispinb 4y ago
> But nobody ever does that. Please don't report your own experience samples as plain universal facts. It is one of the more common means by which falsehoods spread. I have no doubt that's not your intention, and you believe what you write, but you cannot have a basis for such a bald statement, and it happens to be false. I have seen prototypes built and discarded very frequently. Indeed in an earlier incarnation it was my own professional focus. I have no idea how common it is in your country, or globally, or in specific industrial sectors. Usable stats in tech are hard to come by (in large part because of its ubiquity). But your statement is just false, and commonly repeated.
mike_hearn 4y ago
Have you tried something like Kotlin? It has the same experience IMO of being very easy to refactor, especially because the IDE can do so many refactorings for you very fast, and because the compile turnaround time is so low.
jay-barronville 4y ago
> Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that. You can’t be serious. I’ve seen prototypes get thrown away all the time, especially at startups. In fact, I’d say that’s more common than not.
4y ago

throwawaygal7 4y ago

People who are really interested in rust tend to be top-tier developers. I don't think they're consciously lying about their experiences working with the language but they may not hit the speed bumps that normal people would. My personal abilities make me competent in golang, ruby, python, java, c++. I love the quasi-functional styling of rust but whenever I've tried to build small projects in it I've gotten bogged down in fighting with the compiler in ways I never do in the former. It is fast as all get out tho!

throwawaygal7 4y ago

Die hard rust fans often minimize the very real developer difficulty incurred by their language of choice. Even major library maintainers in rust have criticisms of various language features because of their difficulty to use. These are real and substantiative concerns that would affect any development team not made of expert rustaceans. Just look at basic dynamic programming implementations in a normal language versus rust for say popular leap code questions and you'll see the difference in basic developer productivity.

steveklabnik 4y ago

Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (embedded) but we use it for web backend cases as well. Iteration time hasn’t been an issue, but compile times can be annoying. Though obviously compile time is related to iteration time. Of course, all of these things are anecdotal. Collecting anecdotes is how you develop evidence, of course…

efficax 4y ago
I'm also at a startup using rust. It's true that the feedback loop can sometimes feel bit slower. One thing that helps here is being test driven so that you're not waiting for compiles just so you can click through to confirm a small change in behavior. But in general I think my velocity is not much slower than it was at a previous company using a node backend. The hardest part of software isn't typing in the code and making sure it runs. It's thinking about what it should do and how it should do it in the first place. And really, Rust's type system is a force multiplier. We can prototype really fast, throw out things and rework them with confidence because with well thought out typing and tests to confirm logical behavior we have strong safety guarantees. It lets you experiment and investigate alternative implementations fearlessly.
faitswulff 4y ago
Do you mind my asking what frameworks you're using in Rust on the backend, if any?
- steveklabnik 4y ago
  We ended up building one https://crates.io/crates/dropshot https://crates.io/crates/dropshot Happy to talk about anything!
  - faitswulff 4y ago
    Oh this supports OpenAPI! That's exciting. I'll definitely check this out when I have a chance. Thanks!

rdtsc 4y ago

It's great when wanting to play with cool new technology combines with implementing a viable product to sell to customers. But those two things don't necessarily go together. Quite often they are at odds with each other, and then you have to pick one or the other: either we spend resources playing with cool technology, or deliver a product customers will buy. Neither is wrong if it's your own resources, it's just important to understand that there is a trade-off involved.

dcow 4y ago
Exactly. "Rust wasn't the right choice because we spent too much time and resources playing with it." is not an argument against Rust. It's an argument against learning a new technology while looking for PMF. There's nothing inherent about Rust that makes it a poor choice to build a first iteration of a product with.

jakswa 4y ago

I remember reading about PropelAuth somewhere and thinking that Rust might slow down development -- something I wanted to be proven wrong about since I've been learning rust off and on, and like some things about it. It seems it's ending up up a mixed bag, and the negatives in the bag are still light enough that you're carrying it forward. Thank you for this blog post!

mamcx 4y ago

> Perf is easy when you have AWS credits. One reason that you might pick Rust is for overall performance. Interesting: Rust save money but that mean effort!

marcosdumay 4y ago
Even on the cloud, Rust will only save you money if you have enough users. But the effort is upfront. Unfortunately, the cloud isn't a very good environment for mixed-languages deployments (unless you stick to the most basic services), so you have to make a decision on the very beginning and stay with it.

dhbradshaw 4y ago

We have a fairly complex app with a front end in Typescript and a back end in Rust backed by Postgres on AWS. My favorite part of the job is coding in Rust and we do a lot of cool things in that backend code. Unfortunately, most often the Rust code is the fastest and easiest part of a change, which means that I spend most of my time solving problems either on the front end with Typescript or on CI and infra type things rather than the Rust part. It's a bit sad: if something just works, you spend less time on it than on the hairier things.

EVa5I7bHFq9mnYK 4y ago
Backend code is simpler because is has two limited well defined surfaces (API for the frontend on one side and database on the other side). Frontend is harder because it has to interface with those impolite hairy meat creatures ...
- dcow 4y ago
  Frontend code has two as well: the input methods (mouse, keyboard, screen) and the API surface. > Backend code is simpler I hear this every once in awhile and think it's mostly a front end happy hour misrepresentation that makes everyone feel good so it gets repeated. The service layer of an application is very often far more complicated than, or to be fair, at least as complicated as, the user interface. Front end devs just typically aren't good at chopping up their problem into nice interfaces and therefore struggle to test it reliably or make large broad changes efficiently. This is where the complexity comes in. That's not a stab at FE devs, it's just not a skill that often gets rewarded in FE work so it's not very prevalent, which I find sad. The service layer has to deal with enforcing the correctness of business logic despite the infinite ways the meat monkeys can interact with it. It does this by defining clear boundaries on the outside and by ensuring the transactional correctness of logic on the inside. While front end folks have to figure out the correct UX to use to successfully communicate with with a user, service layer folks have to figure out all the implications of a single action the user wishes to take and make sure it happens correctly. Data validation, data modeling, transactions, errors, queuing, retries, scaling, monitoring, etc. are all things that would probably make the average FE dev explode if thrust upon them.

jmull 4y ago

Since safety was the first reason given for using rust, I'll just point out: There are other safe languages. I think it's a really useful thing to have from day one, but it doesn't particularly point you to rust. Also, performance is really about learning what your bottle-necks are, profiling them and optimizing them. You probably have no idea what those are when you start, so it's not really the right time to try to solve it. (There's a decent chance, e.g., that your inner loops won't even be in code you write, like the database.) Probably the best thing you can do for long-term performance up-front is to try to stay flexible, and try to keep your architecture simple.

ReflectedImage 4y ago
Rust does a bit more on the safety front than typical programming languages.
- dcow 4y ago
  Really? I guess if your typical programming languages are C and C++. Otherwise Rust just has semantics that allow more control over memory, as is often needed in lower level programs, while preventing pointer aliasing. The majority of languages in existence are memory safe--some even more so than Rust. They're just not as flexible.
  - ReflectedImage 4y ago
    It's much better than Java, Kotlin and C#. The borrow checker detects the majority (~95%) of concurrency problems. We don't have that many single core CPUs lying around anymore. It's got a story on high performance, high concurrency programs which is significantly better than anything else I've seen so far.
    - dcow 4y ago
      I'll give you that. The reason I questioned is because in my experience with those languages the 95% problem is not the actual data consistency rather it's locking and synchronization hell that results from needing to make your program threadsafe to ensure data consistency. Rust says, don't get yourself in a situations where you need to do that in the first place, it's not safe. Just clone the data or leak it read only or Cow it. What Rust does is great, it sets you up so you're never sharing references across threads unless you try really really hard. And that's the source of needing manual synchronization the majority of the time. However, when you do need locks, Rust doesn't do anything to help. In other words, if you copied a Java program to Rust with object instance pointers all over the place, I bet it would feel just as bad in Rust. So I tend to think of that more as "thread safety" than "memory safety". But we might just be arguing semantics at this point. I agree Rust is far more of a pleasure to work in than Java and C#.

estebank 4y ago

I find it surprising that so many people are arguing about the benefits and drawbacks of `?`, when in my experience the handling of Result and Option haven't been an issue in practice on the consuming side (`?`, `.unwrap()`, `.map()`, `.ok()`, if let, match, let chains, let else, etc. help a lot), but where all the pain comes from is having to declare the appropriate error type itself. Libraries like `anyhow` takes some of the pain away, but declaring an appropriate struct or particularly an enum in the right places, and the boilerplate for all the type conversions (From/Into impls) are where, during development, I have frustration. What I do then is either use Result<T, ()> or a single `struct Error(String);`, and go back once I have all the scaffolding in place and pry the implicit error tree back into the type system. Anonymous enums like typescript (`A | B | C`) could presumably help here.

lenkite 4y ago
All these workarounds for easier Result handling truly make me wonder whether Rust will eventually evolve exceptions as a feature - of-course without explicitly terming them so.
- steveklabnik 4y ago
  The community would revolt. Not going to happen. Proposals to make the existing syntax and semantics even look more like exceptions were met with lots of hostility.
  - FpUser 4y ago
    Revolt how? Go back to C++ or whatever language/s they were using?
    - steveklabnik 4y ago
      I don't know exactly, but it's never pretty when a project's leadership makes an unpopular decision. Lots of complaining, for sure.
- 4y ago

Ylmaz 4y ago

I like this quote from 'The art of Unix Programming' published in 2003 "While it still makes sense to write system programs and time-critical kernels of applications in C or C++, the world has changed a great deal since these languages came to prominence in the 1980s. In 2003, processors are a thousand times faster, memories are a thousand times larger, and disks are a factor of ten thousand larger, for roughly constant dollars. These plunging costs change the economics of programming in a fundamental way. Under most circumstances it no longer makes sense to try to be as sparing of machine resources as C permits. Instead, the economically optimal choice is to minimize debugging time and maximize the long-term maintainability of the code by human beings. Most sorts of implementation (including application prototyping) are therefore better served by the newer generation of interpreted and scripting languages. This transition exactly parallels the conditions that, last time around the wheel, led to the rise of C/C++ and the eclipse of assembler programming."

apozem 4y ago
That's a great way of looking at it. Languages all have benefits and drawbacks, but you have to consider whether they help you for your problem. One time, I met a guy who wrote firmware for Seagate hard drives. Any new feature he added had a budget measured in microseconds. Obviously he wrote nothing but C++.
dilippkumar 4y ago
In a benchmark of how many fortune responses are returned by various web frameworks[0], nodejs returned 80k odd fortunes per second. The fastest c++ framework compared here returned 616k odd fortunes per second. Assuming that my application scales by the same amount (big assumption, yes), I could cut AWS costs by 7.7 times (!!!) by using the C++ implementation. I'm pretty sure that maintaining a C++ codebase is less than 7.7 times more expensive than Node, even if you throw in extra development time etc. This also ignores the decades worth of excellent tooling we've built up for C++ (static analyzers, fuzzers, etc). At a startup, when building things fast matters more than costs, sure. I buy the argument for Node or Python or any other interpreted backend. But once you start to scale, things change after some threshold. Unless you're facebook[1]. [0]. https://www.techempower.com/benchmarks/#section=data-r21 https://www.techempower.com/benchmarks/#section=data-r21 [1]. https://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/ https://developers.facebook.com/blog/post/2010/02/02/hiphop-...

kilgnad 4y ago

Rust is weird. It has high level features that make is superior to high level languages like go and python. But the low level features like default move semantics inevitably make it harder. IMO there is merit in making a language that is equivalent to garbage collected rust by default with ownership rules similar to python. Then the classic rust based ownership and allocation schemes are all opt-in syntax-wise in the same way Box is opt-in.

frodowtf 4y ago

The reason why people would like to pick Rust is because of its ergonomic features like sum types, streams and of course the toolchain. But here is a claim: Most business-level programmers are not ready for dealing with the borrowing and ownership concept. They don't want to care about reference vs. value types. They can't do memory management efficiently, because most of them have never used a language without GC. With Rust you would need to care more about memory which is not necessary for most use cases in startups.

dcow 4y ago

I don't agree. I think the author is conflating two things: 1. learning Rust, and 2. using Rust. If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early. The iteration time issue with Rust is solved by experience. We use Rust and our iteration times are average. What we gain is not performance, that's not a reason we use Rust (for an early stage startup, totally agree you burn credits until you can afford to care). We gain correctness. And at an early stage, correctness without paying for a massive QA team is a huge boon. There are definitely more mature tools for quickly standing up CRUD APIs. If you want a framework that can bootstrap you into an OpenAPI with docgen, swagger, all the bells and whistles, Rust doesn't do that. But Rust will help force you to write correct code that never crashes and handles edge cases it's easy to forget about when moving fast in a duck typed language. The only language we seriously considered over Rust was Swift. But Swift's just wasn't quite there yet. It might be today. If I was starting something from ground zero today, I'd probably lean towards Swift and need to be argued down back to Rust or Python.

Sodman 4y ago
The author touches on why it matters in the article - either you have to restrict hiring to folks who are already rust experts (much smaller hiring pool, also usually meaning higher comp expectations) - or you have to consider the cost of training new/existing staff on Rust. Rust has a notoriously difficult learning curve, especially to folks who don't have a background in C/C++. As the author mentions, you may be looking at 6+ month ramp up time until new hires can comfortably write non-throwaway tech-debt free production code. For many startups looking to iterate quickly, that's just too slow. Conversely if you are looking to hire Java folks, you'll have an enormous pool to pick from, or if you need to train somebody in eg Go - you can do that significantly quicker than you could with Rust.
- dcow 4y ago
  I was putting that argument aside because that's an argument you can make for any language and it changes depending on who you know, what circles you're in, etc. It's and externality not specific to Rust. You can say the same for Erlang, or Swift, or C#, or ...insert language that isn't JavaScript. What I'm saying is that, disregarding the externalities, I've found Rust to be quite a boon and not inherently a bad fit for an early stage. YMMV.