Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

Post reply on HN
Print view View original

281–290 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#281

Post by fooker »

virtualritz wrote: post #214
fooker wrote: post #101

This matches my experience. I have been doing compiler development in C++ for about 10 years, lisp before that and a bit of python more recently. We could not figure out how to be productive in Rust after starting a greenfield project and sticking to it for a month. Luckily this was not a project which requires incremental updates, we were on the verge of rewriting it in C++.

Yes, this matches my experience. It took me almost a year to be as productive (and my code as canonical) in Rust as I was after over two decades of C++. After a month of Rust I was still fighting the borrow checker and grokking basic concepts of the language. So no surprise in what you wrote. However, after that year I am probably a factor of two to ten more productive in Rust. The speedup is about two for everyday c…

>It needs to be integrated with the build and that takes about the same time plus writing/generating a wrapper.

It's one line of change for any build system..

Re: Using Rust at a startup: A cautionary tale

#282

Post by satvikpendem »

futureproofd wrote: post #264
satvikpendem wrote: post #36

I'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…

It's nice to read that someone else has had a positive experience with the zero2prod book. I'm working my way through it and my impression so far (even after reading the official "book") is that Rust is hard ; I enjoy the challenges and the eventual realizations, but working my way through some of the chapters that involve implementations, traits, and macros makes me wonder: Would I actually be able to do this myself…

I thought so too when first starting it, but I realized it's in-depth by design. There are a lot of tutorials that teach you the vague basics but they leave out things you (ostensibly) might not need currently, like logging and tests. In contrast, Z2P covers a lot of areas that are traditionally missed in such tutorials, and it even teaches design patterns for high performance web APIs. With that in mind, it felt like reading two books worth of information in one.

After going through the book, I've found that I simply use the same boilerplate for every new project, so it's more of a `write-once, use again` type of deal. In that case, I don't worry about the time it took to get to the point where I could do that reusing.

Re: Using Rust at a startup: A cautionary tale

#283

Post by satvikpendem »

pipe_connector wrote: post #88
satvikpendem wrote: post #78

Earlier quoted context omitted.

It is dealbreaking. These days I gravitate more and more towards strongly statically typed languages over weakly dynamically typed ones, which I definitely used to use when younger. Fact is, linters are simply not the same as something built-in from the ground up. Trust me, I have written many thousands of lines of Python and Ruby, and even with linters, they don't hold a candle to even something like TypeScript in t…

In general I agree with you, but Go's simple syntax means that there are extremely few (if any? I've never run into one) edge cases with checking that an error was at least considered. The guarantees are the same as what you get with e.g. Rust. The only difference is that you have to run a third party's code, which I don't like, either.

> The guarantees are the same as what you get with e.g. Rust.

I'm not sure how they could be, given that Rust checks exhaustively and Go doesn't. If one programmer messes up, then that's it, an unhandled exception might occur in the future. I would rather rely on the computer telling me when it should be handled over humans.

Re: Using Rust at a startup: A cautionary tale

#284

Post by satvikpendem »

3a2d29 wrote: post #266
satvikpendem wrote: post #211

Earlier quoted context omitted.

I mentioned the benefits elsewhere. Faster, more throughput, uses far less memory, more ergonomic developer experience (Elixir for example is not statically typed), rock solid stability (my API and anecdotally those of others I hear have never crashed). The risk is small compared to the benefits. I'm not sure why you keep saying there aren't benefits because there are. Now you might not agree they're good enough for…

Fair, but again I think you can get all those things with a GC language. Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.

> Speed in programming never matters except in the systems space.

This kind of attitude is how we get bloated Electron apps that HN (including me) loves to complain about. Speed should be a first class consideration, not something to throw away for later.

> No one is gonna be able to tell Rust vs Go in a web API

Debatable, Discord moved from Go to Rust [0] because they were getting latency and CPU spikes from Go's GC, and I'd assume that's the same with any GC language because, well, the GC has to run sometime. Now you might say that we're not all Discord scale, to which I'd say, like above, there are benefits to Rust that are more than just speed. Cargo alone is nigh unbeatable compared to some other languages. I was trying to get Python to work the other day and was pulling my hair out over venv, virtualenv, pip, conda etc.

[0] https://news.ycombinator.com/item?id=26227339

Re: Using Rust at a startup: A cautionary tale

#285

Post by errantmind »

singularity2001 wrote: post #278
errantmind wrote: post #122

While I respect the author's anecdote, this doesn't match my experience. I've been programming for 20+ years across a wide array of languages and I'm by far the most productive in Rust. With a competent teacher, experienced devs should be able to pick up on the memory model pretty quickly, and that is really the only initial blocker to productivity. After that a dev can essentially write procedural code if they want,…

how can you be more productive in rust, where you do have to worry about object lifetimes than in languages where you don't, and where you can focus more on algorithms, say java?

A couple reasons I'm more productive:

1. I'm familiar with lifetimes and they don't slow me down anymore. Also, I usually structure my projects such that I don't need to explicitly express them.

2. I spend a lot less time fixing bugs because Rust makes them impossible.

Re: Using Rust at a startup: A cautionary tale

#286

Post by mtelgon »

3a2d29 wrote: post #280
Casperin wrote: post #260

Earlier quoted context omitted.

You can? Imperative, strong type system (no null, adts), reasonably fast, compiles to a single binary. I'm genuinely interested.

Go fits all of those, so does Ada.

go doesn't have null safety or adts though? (sum types)

Re: Using Rust at a startup: A cautionary tale

#287

Post by arcticbull »

3a2d29 wrote: post #279
arcticbull wrote: post #247

Earlier quoted context omitted.

> 1. The risk of future unsafety (a GC language will always safer than rust) [citation needed] > 2. Faster development that's easier to change on a dime. Yes, development can be faster at the expense of safety, which is a trade-off that favors the use of other languages at early company stages. Agreed here. > 3. No risk of memory leaks (which can happen in safe rust) ... at the expense of making collection non-determ…

1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe. 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it. 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.

> 1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe.

That's not what you originally claimed though. You made some claims about 'risk of future unsafety' and I'm not sure what that means?

For the second half of your claim, Rust's safety guarantees extend well past memory safety - and a collector doesn't guarantee memory safety at all. Yes, most GC'd languages are memory safe too. However, you can just strap the Boehm GC to C or C++ [2] and that doesn't suddenly, magically, make it memory safe.

> 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it.

Safety means a lot of different things. GC isn't a replacement for safe Rust. Rust offers many kinds of safety, memory safety is just one. And yeah, unsafe is a tool for implementing certain things that cannot be expressed in safe Rust, but it's extremely rare that you would dip into it in production code. It's more for library authors who wrap unsafe APIs in safe ones.

If you're curious what 'safe' rust really means and why the GC doesn't subsume all its features - and the difference between safe and unsafe Rust - I'd recommend [1].

> 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.

Sure in embedded it can be hard, but on a PC you can just use valgrind or the leaks tool. If you're writing embedded code in Rust just don't use Rc or Arc boxes and you can't form a cycle. Remember there's no reference counting in Rust at runtime unless you opt into it with a shared-ownership reference-counting box. All Rust's reference counting happens in the compiler and once the compiler determines your object is no longer referenced, it drops it. If it cannot make that determination statically your build will fail.

Reference counting is generally how resources are managed in GC'd languages since you're explicitly not to rely on the finalizer ever being called. Files, sockets, etc. It's just trading off one kind of problem for another.

[edit] Note that you can also leak memory in a GC'd language by keeping a reference to objects you no longer need - for instance, in some long-lived dictionary or array, or in a static. [3]

[1] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

[2] https://hboehm.info/gc/

[3] https://www.lucidchart.com/techblog/2017/10/30/the-dangers-o...

Re: Using Rust at a startup: A cautionary tale

#288

Post by insanitybit »

creata wrote: post #33
insanitybit wrote: post #3

Interesting. 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…

> Rust is considerably more productive [than Python] Can you expand on this, please?

I'll just link you to the last time I responded to this: https://old.reddit.com/r/rust/comments/xbqdzi/anyone_use_rus...

Re: Using Rust at a startup: A cautionary tale

#289

Post by 3a2d29 »

arcticbull wrote: post #287
3a2d29 wrote: post #279

Earlier quoted context omitted.

1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe. 2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it. 3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.

> 1. No citation needed. I can take rust and do unsafe things in it. I can’t in a GC language. Rust allows you to use unsafe. That's not what you originally claimed though. You made some claims about 'risk of future unsafety' and I'm not sure what that means? For the second half of your claim, Rust's safety guarantees extend well past memory safety - and a collector doesn't guarantee memory safety at all. Yes, most G…

Right, but to my knowledge the other “safety” of rust is concurrency, which is easily attainable with something like Elixir.

I’m not saying a GC guarantees all safety, I am saying you can find a GC language that gives all the safety (and technically more) of rust.

My quote of “future unsafety” is that even if your code currently uses only safe rust, their will always be the chance someone adds unsafe rust, increasing the safety issues.

It just seems you can find a GC alternative that will never run into the issues rust can cause, and it will be faster to develope/change (because no borrow checker), and there is no downside.

Re: Using Rust at a startup: A cautionary tale

#290

Post by 3a2d29 »

mtelgon wrote: post #286
3a2d29 wrote: post #280

Earlier quoted context omitted.

Go fits all of those, so does Ada.

go doesn't have null safety or adts though? (sum types)

I think you can have null safety in Go and you certainly can have adts.

But even then, what about Ada?

I’m also not an expert, but I assume between C#/Typescript/haskell/swift that you can find all those things in many GC/safer languages.

Post reply on HN