I've seen a pretty clear difference in success with less popular technologies based more on management philosophy and culture than the technologies themselves. Management seeing individual developers as fungible—"lack of fungibility in the engineering team can be a real liability"—is a massive red flag in this regard. I am not surprised to hear Rust didn't work out in an environment like that!
Using Rust at a startup: A cautionary tale
161–170 of 355 posts
Re: Using Rust at a startup: A cautionary tale
#162Earlier quoted context omitted.
The problem is that, while the benefits of trading safety vs. velocity go to the company, the costs go to the user, as it is the user whose data or identity will be stolen. And this goes well beyond Rust and "mere" memory safety: this extends to every kind of taking things slow and being careful in your coding rather than just throwing something together and later finding out you've made a serious error. This is why…
Rust is essentially not doing anything to prevent the kinds of attacks you're talking about that other mainstream languages aren't already doing. It's a clear win over C and C++! But to a first approximation zero startups are shipping ordinary applicatioins in C/C++. Rust simply isn't meaningfully more secure than Java.
As a Rust fanboy, I mostly agree with this sentiment. Theoretically, Rust should prevent “security” issues arising from memory safety issues like heartbleed (maybe not actually heartbleed) but a good GC would too. I do think Rust does push a little harder on correctness via Result types and things like Sync/Send traits, but I don’t have much Java experience to fully compare.
However, type correctness won’t necessarily prevent a DDoS, stolen password, specter, timing attack, phishing attack, etc. Type safety is a nice-to-have but not sufficient for security in SAAS products.
Re: Using Rust at a startup: A cautionary tale
#163Over the past 2 years I've been writing Rust services for my own startup. Some were straightforward CRUD, some advanced language parsing and ML services. Some thoughts: - Rust tends to push you to make good decisions. In my case, one of these good decisions was to ditch an ORM (which has always slowed me down) and instead write Postgres queries directly via SQLx. The compile time checks against an actual DB helped my…
Not special. I couldn’t have said it better myself.
I often reach for Rust when Python could do, but it’s a bit bigger than a one page of code program. I also forget I’ve been doing Rust nearly full time since late 2015. And before that 15 years of C and understanding memory, etc. Maybe we’re just a rare breed.
Re: Using Rust at a startup: A cautionary tale
#164Earlier quoted context omitted.
C++ doesn't have a Rust-like ownership/borrow system.
I think you meant “borrow checker” because sure it does. It’s called a const reference. Want a mut borrow? That’s a pointer. That Rust can check these somewhat more explicitly (rather than via good coding style) and that C++ also allows you to do arbitrary permutations (a la non-const references) is what you’re talking about. But ownership is very very real in C++! Just look at the craziness that is move semantics!
[deleted]
Re: Using Rust at a startup: A cautionary tale
#165"Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations — like building code in an OS kernel, or for memory-constrained embedded systems — but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial" Great point
This really depends on your problem domain. Rust productivity is vastly higher than C++ due to its helpful compiler error message, package manager, integrated tests and bench facility, and language features like algebraic datatypes and a whole lot more. This also hasn't counted the reduced debug time later, which would be a significant time spent by devs in C++. In areas that don't value performance and correctness,…
>Rust productivity is vastly higher than C++ due to its helpful compiler error message, package manager, integrated tests and bench facility, and language features like algebraic datatypes and a whole lot more
Are you actually a C++ programmer? I work at a firm that uses C++ and Rust and this isn't the case at all. Setting up dependencies, tests and benchmarks is a one-off cost, most C++ compiler errors are quite understandable to experienced devs unless they're doing something really hairy, and C++ has algebraic datatypes, as a library (std::variant) via variadic templates, something Rust doesn't support. For C++ devs comfortable with template metaprogramming Rust is missing a bunch of features, many things that are relatively simple in C++ are literally impossible in Rust (at least without writing macros). Rust also doesn't save much on debug time if writing single-threaded code, because memory errors are a very small proportion of the bugs one encounters in modern C++ written by experienced devs, rather most bugs are logic errors, which Rust doesn't prevent.
Re: Using Rust at a startup: A cautionary tale
#166Earlier quoted context omitted.
This doesn't match my experience. It took some time to get up to speed, but at this point it's much faster for me to write something in Rust than in other languages that I'm proficient in that are ostensibly faster to develop in (e.g., JavaScript). Part of this depends on one's bar for quality. In Node.js I could write `JSON.parse(input).foo.bar` really quickly. In Rust, I'd probably write two struct definitions with…
FWIW the “parse don’t validate” attitude which has become popular in TypeScript circles does this equally well. In Rust you’ll define the types you expect to deserialize as structs with Deserialize trait implementations, in TypeScript you’ll define a basic schema with runtime decoding and corresponding (inferred) static types. Like you say, maybe 45 seconds more typing, with the same value guarantees. I like that thi…
To me the greatest thing about TypeScript is that there are times that I absolutely know that something doesn't need to be extra safe or to have validation, and I can easily slap a `// @ts-expect-error` on it and either ignore it or come back and fix it later. I know some people think that's a horrible thing and sacrilege, but damn it if it makes it easy to move fast when you need to.
Re: Using Rust at a startup: A cautionary tale
#167Interesting. By contrast, I wish I had used less Python and more Rust for my company's product because Rust is considerably more productive. We were building gRPC and web services. I just haven't found it to be the case that developers have a very hard time learning it, but we haven't grown to the point where that would maybe be the case. We also lean heavily into microservices so "oh there's no library in Rust but t…
In my experience, Python is one of the least productive programming languages for projects with more than 3 people. If you have a big project, you are going to spend a lot more time reading code than writing it. Python is write-optimized. By contrast, using Rust makes it easy to force a readable coding style on yourself and others.
Python is not readable to you? The beginner friendly, whitespace-enforcing, almost-like-pseudocode-in-English language - that Python? - is not readable enough, but Rust, where you liberally sprinkle ', {}, !, &, :: or #[] everywhere _is_ readable to you? You must be trolling.
You know what Rust looks like to me? Perl without the dollar signs. There's your write-only language, you just have it backwards.
Re: Using Rust at a startup: A cautionary tale
#168I've seen a pretty clear difference in success with less popular technologies based more on management philosophy and culture than the technologies themselves. Management seeing individual developers as fungible—"lack of fungibility in the engineering team can be a real liability"—is a massive red flag in this regard. I am not surprised to hear Rust didn't work out in an environment like that!
... but especially for a small team, having people able to cross-operate on adjacent pieces of the tech is vital. You can't just not develop if all your Rustaceans catch COVID at the same time.
So "there's a huge bifurcation between people who know this language and people who don't" is a good reason to pick another language. As with so many such techs, network effect can dominate other benefits.
Re: Using Rust at a startup: A cautionary tale
#169Earlier quoted context omitted.
Trying too hard to write good code can be a deadly mistake for an early-stage startup regardless of the language you use. If you're really a startup, looking for a product-market fit, then you don't know exactly what you're building yet. There's a high change you're going to throw away a lot of code. e.g. you spend effort caring about scalability, flexibility, proper architecture, full test coverage — only to hand it…
Sure, but good code saves time even on really short timeframes. Every time I've worked on—or seen other people work on—a "we must hurry at all costs project", enough time is wasted on debugging, firefighting and friction that just building a decently clean system from the get-go would have been faster. I've seen this unambiguously on "throw away" data science code meant to produce a single report (or normal science c…
It all comes down to whether the team is faster at writing safe code in a tight language or debugging a loose language. My experience has been even with the lossage due to initial errors, teams I'm on have been better debugging errors, especially when the task is so small that the errors are obvious.
Re: Using Rust at a startup: A cautionary tale
#170I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…
God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.
That just means you have written a lot of go. I truthfully don't notice lifetimes or the borrow checker most of the time when I write rust.
I actually think that, ironically, the if err problem with go is worse for reading code than writing code. If you are used to the pattern it's not that difficult to add the `if err != nil` after a fallible function call, and as is mentioned elsewhere, linters can help catch if you miss it. However, if you are trying to figure out what a function is doing, it can be very difficult to follow the flow, when 3/4 of the code is
if err != null {
return err
}