Live data from Hacker News

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

251–260 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#251

Earlier quoted context omitted.

Python is extremely easy to write, but hell to read. Rust code tends to be very easy to read. On a big project, you are going to be reading a lot more code than you are going to be writing.

I've read and written a huge amount of python and rust, also a fan of rust and don't find it particular difficult to read. As long as there is proper linting, both should be readable. That being said, python is about the simplest language there is to read. Of course if you have many times nested and improperly indented list comprehensions- sure that gets confusing. But that should be fixed with proper linting (black…

I don't necessarily agree that Python overall is difficult to read, but one thing that seems to get my every time is the

    foo = x if y else z

Re: Using Rust at a startup: A cautionary tale

#252

Earlier quoted context omitted.

Your profile link doesn't work. Regarding `if err`, it's one thing to add it everywhere, it's another to forget and then have something break. If Go also checked for exhaustive error handling, I wouldn't mind it either.

https://github.com/kisielk/errcheck Every Go project I've worked on has used this linter. I think it should be builtin, but it's very easy to incorporate.

What kind of error does it check?

Re: Using Rust at a startup: A cautionary tale

#253
post #238

Earlier quoted context omitted.

C++ already has that problem sorted out with Conan and vcpkg.

Sure package managers exist, but there isn't really one that everyone has aligned on. That's a huge benefit of Cargo, and also of npm. Like a lot of C++ things there's a big theme of "can we have X? we have X at home. X at home: o_O"

The amount of packages don't matter, as long as the key ones are available, and they are there on both. No need to compete against npm.

They also have an advantage over cargo, specially Conan, binary repos, no need to recompile the world for 3rd party dependencies after each git clone.

Re: Using Rust at a startup: A cautionary tale

#255
post #33

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 can. I work on a ~20k loc Python service as well as a ~10k loc Rust service. The Rust service is only half the size, but the problem space is many times more complex.

Whenever I work on the Python service I feel like I'm working in clay. Like, everything kind of sort of works. It won't at first, but then you just poke at it with a stick until it does. In Rust, it works or you're told exactly why it doesn't and then you fix it.

I change a struct and the compiler provides me with a list of places that need updating.

I have many reasons (mypy, type system, testing, venv, python 2), but really the big one is rust's superior type system as well as general tooling (lsp is way better, cargo and clippy are phenomenal).

Re: Using Rust at a startup: A cautionary tale

#256
post #77

Earlier quoted context omitted.

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.

Wait what? Python, if anything, has a reputation for being readable! Perhaps this is more of a criticism of dynamically typed languages in general? As the team grows, adding mypy types can help a lot.

Personally, it's the scoping that drives me nuts more than the weird version of dynamic typing (which is awful, but can be fixed). A lot of "pythonic" syntax is also very python-specific and hard to read if you aren't a python person. There is also the implicit type conversion and the runtime errors for things a linter or a compiler would catch in another language.

If you only work on 1M LoC, it gets very hard to keep everything you need in your head if you want to understand code that other people have written.

Re: Using Rust at a startup: A cautionary tale

#257

Earlier quoted context omitted.

> I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type That's going to get tiresome after about half a day. Exceptions or GTFO.

The only difference between exceptions and Result are that you need to change your return type to Result, and that you need to add a ? after calls that might fail. There's also a bit of annoying typing stuff involved, but generally with something like the anyhow crate you can handwave that away too.

> The only difference

That's a significant difference.

It's the only difference if you're only considering blub exceptions, and not a nice exception system in which raising an exception doesn't immediately unwind, so that you can have remote handlers choosing local restart points and such.

> you need to change

Say I can't change it. I want to pass the exception through a third party library I don't control. I don't want to fork it, or can't.

Sum types with pattern matching are definitely nicer than some integer error codes or what have you, but for error handling, they are just a lipstick on error codes.

People outside of the Rust bubble do know what these concepts are, and about languages like OCaml.

Moreover, everyone who ever had anything to do with the concept of the development of exceptions was not an idiot who just didn't see the light of returning a sum type.

> you can handwave that away too

With what plugin for what editor ... :)

Re: Using Rust at a startup: A cautionary tale

#258

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…

I’ll keep an eye on your work on this!

Funny enough, another thread introduced me to Truffle and I came across this article of yours!

https://blog.plan99.net/graal-truffle-134d8f28fb69

Re: Using Rust at a startup: A cautionary tale

#259
post #14

I've noticed that Rust is in an interesting spot - it has a lot of overlapping appeal with various groups. - C/C++ developers like it as an alternative for low level languages - Functional programmers like it because of it's functional features - "Cargo Culters" / "Hot Language" / "Flavor of the Month" followers like it, as it's in vogue at the moment (this is the crowd that has likely shifted from various web/API sc…

I'm in a fourth category. I just want a simple imperative language with a solid type system that is reasonably fast.

While Rust isn't simple, I don't know any other languages that fill this space.

Re: Using Rust at a startup: A cautionary tale

#260
post #199

> Rust is awesome, for certain things. > This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices Of course. Use Java/Kotlin or Node.js/Typescript or Go or Python for your basic web services. Easy test: Would you at least seriously consider usin…

> Easy test: Would you at least seriously consider using C/C++ for it? Only then should you use Rust. This is a great point. I understand liking a language, but don't bring Rust into a GC space (in industry, personal projects can be what you like!) You can find a GC language with all the features of rust you like.

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