Live data from Hacker News

Using Rust at a startup: A cautionary tale

scribe.rip

11–20 of 134 posts

Re: Using Rust at a startup: A cautionary tale

#11
post #4

> the service we were building was a fairly straightforward CRUD app. The expected load on this service was going to be on the order no more than a few queries per second, max, through the lifetime of this particular system. The service was a frontend to a fairly elaborate data-processing pipeline that could take many hours to run, so the service itself was not expected to be a performance bottleneck. There was no pa…

Elixir for a crud app? Really?

Re: Using Rust at a startup: A cautionary tale

#12

One question though: What does Garbage collection do besides what Rust provide? Ownership and borrow checker.

Garbage collection deals with a couple (albeit rare) additional cases (e.g reference cycles) while requiring significantly less mental overhead.

Re: Using Rust at a startup: A cautionary tale

#13
I find it a little odd the author mentions C++ often. I think the use cases for C++ and Rust are pretty interchangeable, and C++ devs would and should probably know about lifetimes anyway. (That said: yeah, don't use Rust for CRUD apps.)

Re: Using Rust at a startup: A cautionary tale

#14

Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…

IMO if you would forget about borrow checker, Rust is awesome language by itself.

I'm not sure if it's even possible, but I think that if GC were introduced to Rust as an optional part, it would make Rust suitable for CRUD apps.

Like all low-level libraries are written with borrow checker and you can write your code with borrow-checker or GC, your choice. So you'll still get superior performance compared to any other GC languages, because your standard library is incredibly fast. And your code will use GC because your code does not matter from performance PoV. And if some function matters - you use borrow checker in that function, so it's fast.

Also green threads might be a good addition. It seems that modern computing reinvents it all over again. Golang, Java. Async/await is hard, people want to write blocking code and get good scalability at the same time.

We need a silver bullet programming language. Period. Suitable to write CRUD and MCU firmware at the same time. Until this silver bullet is not found, we will reinvent new languages.

Re: Using Rust at a startup: A cautionary tale

#15
I liked the recent article about writing the Apple Silicon GPU Linux kernel driver in Rust. Now there's a perfect application for Rust if I ever heard one. The service described in this article is a great example of an application that Rust is not the best choice for.

When I first heard about Rust I really thought it would be the language to end all languages, but even after just a few days using it I realized that's not the case. Maybe someday someone will come up with that perfect language for everything, but given recent progress in AI I think the more likely long term outcome is that neural nets will start writing all our code for us. I wouldn't start work on a new programming language today given the changes that are clearly coming in the next 20 years or so. At least, not one designed for humans. Maybe there's an opportunity for someone to make the first programming language designed for neural nets to use.

Maybe that neural net language would look like Rust. The downside of lower programmer productivity may not matter when the programmer is a neural net. You can just run more neural nets! And neural nets are anything but perfect so they will still benefit from the safety guarantees Rust provides. Rust is the language that I don't want to write, but I want the software I use to be written in it.

Re: Using Rust at a startup: A cautionary tale

#16

Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…

> I don't get how someone could think making a CRUD app in Rust could ever be a good idea

It's the same people than have kept saying there is nothing wrong with writing a backend API server in C++.

Of course you can write a CRUD app in Rust. You can also write it in Brainfuck, such is the magic of Turing-complete languages. Is it a good idea? I'd argue there's languages that are much better suited to writing CRUD systems than either.

Re: Using Rust at a startup: A cautionary tale

#17

Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…

If you want to use a hot new language, Nim seems like a safer default choice.

Re: Using Rust at a startup: A cautionary tale

#18
post #13

I find it a little odd the author mentions C++ often. I think the use cases for C++ and Rust are pretty interchangeable, and C++ devs would and should probably know about lifetimes anyway. (That said: yeah, don't use Rust for CRUD apps.)

Coming from c++ I had no troubles with lifetimes in rust; they were obvious and moat of the time I would have structured the code in the same way anyway.

The main problem i encountered (beyond the usual learning curve for stdlib and other common libraries) is all the gotchas and rough edges around async

Re: Using Rust at a startup: A cautionary tale

#19
Rust would not be my first choice for a simple CRUD app. There are too many other tools that handle that space well.

I have used Rust at a startup, and it worked out extremely well. But we used it for CLI tools (where it shines), and performance critical code, and for specialized, high performance servers.

Re: Using Rust at a startup: A cautionary tale

#20
post #4

> the service we were building was a fairly straightforward CRUD app. The expected load on this service was going to be on the order no more than a few queries per second, max, through the lifetime of this particular system. The service was a frontend to a fairly elaborate data-processing pipeline that could take many hours to run, so the service itself was not expected to be a performance bottleneck. There was no pa…

Elixir for a crud app? Really?

As a fan of Elixir it seems like a good fit. Why do you think otherwise?
Post reply on HN