Live data from Hacker News

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

351–355 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#351
post #119
post #27

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. This is really the main reason not to use Rust when you need to move fast: if you don't know the language yet, it will take you time to learn it. But that's true of any language. You probably shouldn't do your startup in Java, either, if your team isn't familiar with it. Yes, Rust's learning curve is…

> You probably shouldn't do your startup in Java, either, if your team isn't familiar with it. Java is wildly easier to pick up than Rust, though. Hordes of productive enterprise java programmers are employed today who frankly don't even understand what memory safety even means, much less the tradeoffs their language runtime (or software) needs to make to ensure it. It's certainly a truism that you should tailor your…

> Java is wildly easier to pick up than Rust, though. Hordes of productive enterprise java programmers are employed today who frankly don't even understand what memory safety even means, much less the tradeoffs their language runtime (or software) needs to make to ensure it.

I think Java is a little easier to pick up than Rust, but not much. And this is especially true if one is not already familiar with Object Oriented programming. Classes are weird - conflating a number of concepts that really ought to be orthogonal to each other (and I remember thinking so as a beginner, although I couldn't articulate why then). IMO, structs, enums, and traits are much easier to explain to a beginner.

Rust does have the overhead of needing to care about ownership and memory, but I don't think that's as significant as you might think (and Java also leaks some of these details in for example the difference between objects and primitive types), and it partially makes up for it in other areas.

Re: Using Rust at a startup: A cautionary tale

#352

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/

Oh no, please no Ur. Sounds good first, but so far from production-readiness. Research? Inspiration? Check. Use in production? No.

Re: Using Rust at a startup: A cautionary tale

#353

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…

Modern OpenJDK comes with a built-in HTTP server, and you can also embed a relational database like H2 or of course SQLite. You can use it from many different languages, of course. Actually it sounds from the article like Kotlin or Java would have been a better fit than Rust for what they were doing. There are also things like Postgrest which turns postgres tables into REST APIs automatically. But here's something to…

Fully agree with you that in a perfect world desktop apps would be the best for end users and programmers. In that world we would be still writing code on Delphi or Jbuilder. One major problem with desktop apps is still distribution. Entry point for majority of modern desktops is still a browser, through which you search, discover and download. Just like with mobile apps, older versions will remain in use and require support for various reasons (imagine IT department that maintains images of their devices — their update cycle will not be what you expect it to be). Another one is that you cannot really put all logic on client and trust that client to manipulate your data in DB, so you will have significant amount of code on the backend. Stored procedures can technically solve the problem, but developer productivity will suffer terribly if you try to build your middleware inside the db. The tooling for Oracle DB or Postgres and tooling for Java are like stone hammer vs a toolkit from Bosch Professional.

Re: Using Rust at a startup: A cautionary tale

#354

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…

Thank you for linking to zero2prod. I just bought it after looking at the repo for the example code and scanning the sample. I wish I’d read this book a year ago.

I’ve worked my way through a couple of rust books, but this was the first one that actually talked not just about the language, but the entire development flow. Git workflows, CI/CD, docker, comprehensive testing.

Even after clearing the initial rust fundamentals, there are so many standard libraries like anyhow, chrono, serde, thiserror, and tokio that are almost required knowledge, but aren’t covered in most books.

Thank you for sharing your discovery!

Re: Using Rust at a startup: A cautionary tale

#355

Earlier quoted context omitted.

Kotlin has null safety, and there are plenty of ways to turn jvm into a binary

It has no adts at all. Like I'm reading blog posts right now about how to do what should be the simplest thing enum Foo { A(String), B(i32), } And it's.. not simple. And even if you manage to do it, it'll never be how Kotlin was meant to be written.

Its pretty simple:

    sealed interface Foo
    class A(val s: String): Foo
    class B(val b: Int): Foo
Post reply on HN