Live data from Hacker News

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

321–330 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#321
post #319

Earlier quoted context omitted.

The quantifier I infer from "GC languages simply will not allow it" is "all", not "some". Anyway, can you name such a language then?

Are you gonna argue that no GC language exists that is more safe than rust? There were over 200 memory safety violations discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ Elixir for example, is very safe and guarantees more safety than rust.

Those were all memory safety violations in Unsafe Rust. Safe Rust can't have them. And doesn't Elixir only guarantee its safety at runtime, which is way less useful?

Re: Using Rust at a startup: A cautionary tale

#322

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…

Some languages that integrate with an HTTP server and a database:

Ur/Web: http://impredicative.com/ur/

Dark (Darklang): https://darklang.com/

Re: Using Rust at a startup: A cautionary tale

#323
post #319

Earlier quoted context omitted.

Are you gonna argue that no GC language exists that is more safe than rust? There were over 200 memory safety violations discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ Elixir for example, is very safe and guarantees more safety than rust.

Those were all memory safety violations in Unsafe Rust. Safe Rust can't have them. And doesn't Elixir only guarantee its safety at runtime, which is way less useful?

Right but if you imported one of those crates, then your “safe” rust would have memory safety issues.

So bam, you just introduced memory safety issues into your web API. This is like a C++ dev using C++ and causing memory issues unnecessarily just because they don’t want to use a safe language.

And Elixir has concurrency and memory safety and it’s guaranteed, so no package you import can violate it. Unlike rust, where you can use safe rust and think there’s no violation, but then use a crate and suddenly have memory unsafety and concurrency violations.

These crates worries are wayyy better than normal C++, but they are terrible compared to any actually safe language.

Re: Using Rust at a startup: A cautionary tale

#324
post #323

Earlier quoted context omitted.

Those were all memory safety violations in Unsafe Rust. Safe Rust can't have them. And doesn't Elixir only guarantee its safety at runtime, which is way less useful?

Right but if you imported one of those crates, then your “safe” rust would have memory safety issues. So bam, you just introduced memory safety issues into your web API. This is like a C++ dev using C++ and causing memory issues unnecessarily just because they don’t want to use a safe language. And Elixir has concurrency and memory safety and it’s guaranteed, so no package you import can violate it. Unlike rust, wher…

My program might also crash if there's a bug in the kernel's filesystem driver, but that's not my bug. And Elixir has FFI, which definitely lets you do unsafe stuff.

Re: Using Rust at a startup: A cautionary tale

#325

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…

7 years ago I’ve deployed the first version of the REST API service written in Rust. We had multiple deployments in consecutive 5 years. For 2 years this service runs without any updates.

There were just a couple of failures in the first 2 months.

Re: Using Rust at a startup: A cautionary tale

#326

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…

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.

This reminds me of the same response regarding generics from Go users:

> God I get tired of the generics 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.

Over ten years later, Go gets generics.

Re: Using Rust at a startup: A cautionary tale

#327

Earlier quoted context omitted.

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.

This reminds me of the same response regarding generics from Go users: > God I get tired of the generics 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. Over ten years later, Go gets generics.

There’s no contradiction there. I rarely missed generics in Go. Now on the rare occasion that they add significant value, I can use them.

Re: Using Rust at a startup: A cautionary tale

#328

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…

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.

It's hard catching bugs in go when your eyes tend to glaze over tens of thousands of 'if err != nil' statements causing bad signal-to-noise ratio.

I actually like Go over Rust, but really, really wish the language provided some more ergonomics and fixed several of its terrible gotchas. (the for loop issue for example)

Also wish Go gets RAII some day.

Re: Using Rust at a startup: A cautionary tale

#329

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…

Some languages that integrate with an HTTP server and a database: Ur/Web: http://impredicative.com/ur/ Dark (Darklang): https://darklang.com/

Thank you for the introduction!

Re: Using Rust at a startup: A cautionary tale

#330
post #318

Earlier quoted context omitted.

Well if you had 10 yoe with C++, you would certainly not achieve the same level of productivity with Rust for a while. Your point is valid in the sense that you should use the tool that you know if you need results, but it's not great criticism towards Rust.

For most languages it takes a few weeks to be reasonably productive. This is not a criticism of Rust, just a trait which needs to be acknowledged if the situation has to be improved.

Fair enough.
Post reply on HN