Using Rust at a startup: A cautionary tale • Hacker News Board

Re: Using Rust at a startup: A cautionary tale

#131

Post by eropple » Sun, Dec 04, 2022, 4:11 PM UTC

jpgvm wrote: post #126

satnam14 wrote: post #118

Earlier quoted context omitted.

Curious to hear more about your experience with Node/TypeScript. Is it really comparable to the maturity of JVM or the .Net ecosystems? I've experienced some problems such as: 1. It's still running JavaScript on server-side 2. Debugging becomes a pain because stacktraces will contain .js files and line numbers 3. Multi threading is still complex.

Main issues (non-exhaustive) with Typescript are: 1. Type checking is slow (this problem scales with the size of your project also which sucks) 2. Lack of proper build system ecosystem (as compared to Maven/Gradle/etc) 3. Ecosystem is poor 4. Packaging and module systems are poor (import side effects, gross) If you tackle 2. you can also work around 1. Best way to do this at this time is to use the new Bazel rules_js…

I've worked in pretty large codebases and #1 and #2 have not been problems I've encountered. #1 used to be a problem, but TypeScript incremental compilation has significantly improved things. #2 doesn't parse at all as a problem if you're working in a monorepo, and if you're not you've created other problems that "use Bazel" doesn't fix--and, to be honest, "use Bazel" would be a failure case that would encourage me to use literally anything else that didn't use it anyway.

#3 is also a pretty wild take, in my experience. Maybe you have some pretty particular needs, but I very rarely find that I don't have what I need in Node.

#4, I'll give you--but if you're going to stan for the JVM, I hope you've never run into a static class initializer with side effects, because I've seen them about as often as I've seen side-effecting imports (which is to say, not often). I gather that they used to be a lot more common in Node, but I cannot think of a library in my usual stack, or even that I've used recently, that has side effects in that way (modulo development-environment stuff which leverages that kind of cursedness intentionally).

Re: Using Rust at a startup: A cautionary tale

#132

Post by eropple » Sun, Dec 04, 2022, 4:20 PM UTC

satnam14 wrote: post #118

eropple wrote: post #44

Earlier quoted context omitted.

For my money, at least Node and Python have absolutely reached the point where they can provide self-feeding velocity. I quite like the JVM as well--I've written a lot of Java and a lot of Kotlin--but TypeScript and modern, typed Python are very defensible options. I know more about Node than Python, so that's easier for me to talk about, but for my money tools like Fastify have a really excellent ecosystem around ge…

Curious to hear more about your experience with Node/TypeScript. Is it really comparable to the maturity of JVM or the .Net ecosystems? I've experienced some problems such as: 1. It's still running JavaScript on server-side 2. Debugging becomes a pain because stacktraces will contain .js files and line numbers 3. Multi threading is still complex.

My experience is that it's fine(tm). "JavaScript on server-side" does not bother me; V8 is fine. It's not as fast as HotSpot, but also, I don't care. If I ever wrote something at extragalactic scale, yeah, sure, whatever, I'd rewrite hot paths in something else. But I absolutely don't care about that until then.

None of my debugging output includes JS lines because I pack source maps, which TypeScript happily includes.

Multi-threading isn't complex, because there isn't multi-threading. There's coprocessing via Promises, and there indeed are a lot of Node developers who think you don't need locking functionality because it's not multi-threaded (there was an absolutely bonkers discussion a few years ago where a JS developer insisted you didn't need locks), but whatever, they think that about other languages too, use async-lock or whatever.

"Maturity" is a word that means different things to different people. There is not a consensus-best-choice framework like Spring Boot in Node. Which leads people to doing things like "I'll use Express!" and now they have interesting problems all their own. But the tools are there and they're excellent. Fastify is perhaps The Best web framework I've ever used (other than perhaps Python's FastAPI, which makes me wish I liked Python enough to write it because that seems like a Right Answer in itself), and it has only gotten better with v4 allowing you to engage with type providers to create an end-to-end, automatically typechecked route declaration framework. It lets you do stuff like this, where you specify a request schema as JSON Schema (encoded via typebox) and it'll statically derive the TypeScript type for you whilst also using it for request schema validation:

https://github.com/fastify/fastify-type-provider-typebox#exa...

The tools are there and you do probably want to invest a little time in understanding what they do and what their tradeoffs are. There's value in that, for the way I write code and the stuff I enjoy building.

Overall, I'll trade some compilation niceties and even some (but to be frank, not much) performance for a vastly more productive environment in day-to-day use. I really like the JVM. I've been using it professionally for twelve years. I also like the CLR. I did Google Summer of Code for the Mono Project in 2008, I've been around. But the day-to-day of writing code in the dominant languages on those platforms for things other than CRUD does frustrate me, and the general-purpose languages on the JVM and CLR present difficulties in using the type system to effectively encode intent makes it much harder for me to write software that can guide other people to not misuse it. So for me it's worse both at library-writing and at getting-things-out-the-door. (I still do gamedev experiments in Java or Kotlin, though, because libgdx is seared into my brain.)

Re: Using Rust at a startup: A cautionary tale

#133

Post by pitaj » Sun, Dec 04, 2022, 4:37 PM UTC

lumost wrote: post #127

pitaj wrote: post #55

Earlier quoted context omitted.

I've found Rust is also far better than weakly typed and dynamically typed languages as well. > However rust string handling is barely a step above c’s How so? Personally I've found it very good.

Having 3 separate string types commonly used across the standard library is a huge friction. For beginners, it’s impossible to write a common program for doing some basic string manipulation without reading 3/4 of the Rust book and waiting through dozens of compilation failures.

Are the three types you refer to str/String, CStr/CString, and OsStr/OsString?

There are trade-offs associated with having multiple string types, but the alternative is worse. It's better to force the developer to handle these things up front than to have bugs down the line.

str/String being UTF-8 is great. Is means that the various standard library functions associated with them have well-defined behavior.

CStr/CString are necessary for FFI, but I wouldn't really say they're commonly used in std.

OsStr/OsString are necessary unless you think the standard library should automatically convert whatever random format the OS uses into UTF-8. Rust's decision to not treat everything like Unix is actually a good thing.

> For beginners, it’s impossible to write a common program for doing some basic string manipulation without reading 3/4 of the Rust book and waiting through dozens of compilation failures.

Personally, I think the standard library makes it pretty easy to learn how to convert between the types.

Re: Using Rust at a startup: A cautionary tale

#134

Post by drogus » Tue, Dec 06, 2022, 8:32 AM UTC

cardanome wrote: post #8

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've written web backends in Rust and it's fine for backend apps, especially APIs. For HTML rendering it's a bit lacking at the moment as it doesn't have the whole ecosystem that Rails for example has, but for APIs I haven't found a lot of missing stuff. I'd say for a Rust dev with some experience it's similar to Go, although more pleasant in my personal view.

In the context of web apps you rarely have to deal with the borrow checker and the rest of the Rust code is rather high level.

For me the post is a bit weird, cause on the one hand he mentions a CRUD app and on the other hand he mentions complexity. If your CRUD app is complex it's either not a CRUD app or you screwed up along the way. I've seen dozens of Rails apps where development was painfully slow cause of a "big ball of mud effect": a bunch of "god models" having dependencies across the entire system, crossing all of the boundaries. So it doesn't have to necessarily be only related to Rust.