Live data from Hacker News

Why Rust is a great choice for startups

dailyedit.com

181–190 of 294 posts

Re: Why Rust is a great choice for startups

#181
post #117

Earlier quoted context omitted.

I'm doing some work on a friend's startup, and we have a pretty stark divide between our hot path gateway service and our lower traffic services. All three of our services are currently written in typescript with no plans to change, but I've earmarked the gateway as "maybe we'll rewrite it in Rust in three years." It's so small it's nearly trivial (so a rewrite of that specific service will be quickish) and infrequen…

FYI: If you're primarily IO-heavy, the GC pauses aren't going to be a big deal. Something like NodeJS (or Async .Net) will have great performance; even with garbage collection. (IO-heavy is the specific use case that NodeJS was designed to handle.) GC pauses really become a problem when you have long-lived objects in RAM. A generational GC (which pretty much all of them are) is designed to collect short-lived objects…

This is sort of highlighted by other comments, but GC is only good at small quick requests. If you're dealing with large or slow requests it results in large or long lived allocations which causes havoc with GC. This is true for any generational GC, Java included.

Also node will only perform well if that IO is offloaded to the kernel or CPP code and behind a future via epoll etc... If it's in the actual node runtime it'll perform poorly because it'll block the thread.

Re: Why Rust is a great choice for startups

#182

Earlier quoted context omitted.

What makes Rust better for these attributes than any other statically typed language with immutable data structures? It sounds like Ocaml would do just as good of a job here.

Ocaml is absolutely playing in similar spaces as rust. I see the tradeoff there as one of runtime performance (Rust) against less syntax / dev effort (Ocaml). If you don't need your code to go fast, Ocaml is probably just fine for you to use. Hell, Jane Street famously does so and has talked in great detail on their podcast and in articles about the many strengths and tradeoffs involved here.

Given how many startups work with python, which is notoriously slow, this is a somewhat ridiculous statement. Ocaml's performance is probably 50ish% of Rust's at worst, which I claim is more than enough for 99% of the problems out there.

Rust's popularity, again I claim, has almost nothing to with its performance. It's more about the much more modern tooling, relatively simplified language (for most parts, though obviously not all) and superior marketing.

Re: Why Rust is a great choice for startups

#183
I’ve been using Rust as a hobbyist since 2015. I see what’s going on in the community, attend a meetup, and work on open source projects (mostly my own).

I’m starting a side project, and after much consideration, I went with F# and AspNetCore. The maturity of the framework and solutions for web is hard to ignore.

And then F# gives me a lot of what I like about Rust: union types, pattern matching, avoiding null… With less syntax, and without reasoning about lifetimes, which still takes me more effort than I would like.

Don’t get me wrong, I love Rust. In this case, I was able to build out a web server a lot faster, while still getting _most_ of what I love about Rust.

Re: Why Rust is a great choice for startups

#184
post #103

Earlier quoted context omitted.

> Rustian Garbage collection Genuinely curious here: the Java GC (still in 2022) is often a major headache in production wrt latency when system is under load. How's the Rust GC in that regard?

Rust doesn't have a mark-and-sweep GC. It has "automatic" memory management through static analysis. Rust's memory management is done by the compiler automagically inserting free() in the same places that you would put it manually in C.

I would add that it inserts free similarly to C++’s RAII, and it also have reference counting wrapper type which will free at runtime. Reference counting makes different tradeoffs to mark-and-sweet GCs, they usually have worse throughput, but better latency (when they are shared between threads, every new/lost reference does an atomic increment/decrement which is very expensive and happens on the working thread. Java’s GC for example can amortize this cost by doing the work almost completely in parallel)

Re: Why Rust is a great choice for startups

#185
post #183

I’ve been using Rust as a hobbyist since 2015. I see what’s going on in the community, attend a meetup, and work on open source projects (mostly my own). I’m starting a side project, and after much consideration, I went with F# and AspNetCore. The maturity of the framework and solutions for web is hard to ignore. And then F# gives me a lot of what I like about Rust: union types, pattern matching, avoiding null… With…

Are you using ASP.Net Core straight up or through something like Giraffe? Also are you using JS or Fable/etc to handle the front end? The F# web ecosystem is something that I've done light research on but haven't done a real project with yet, but still incredibly curious about it.

Re: Why Rust is a great choice for startups

#187
post #178

Earlier quoted context omitted.

Ocaml to this day has issues on Windows. Its a phenomenal tool, but adoption is always going to be hampered while the world's dominant desktop OS is a second class citizen for that tool.

Just like most languages that are UNIX first, like Rust.

No, not really. Rust undoubtedly started on *nix, but all Tier 1 platforms are supported equally[1]. To quote from OCaml's main site[2] A gentle reminder that if you do not need Windows binaries, then a more stable option is to use WSL2, ie when on Windows it is better to use OCaml from within a Linux VM.

Ocaml is great, but its Windows support sucks, and that makes adoption hard in a lot of contexts.

[1] https://doc.rust-lang.org/beta/rustc/platform-support.html

[2] https://www.ocaml.org/docs/ocaml-on-windows

Re: Why Rust is a great choice for startups

#188

Startups are about cost, time to market, and a high level of efficiency to deliver on a promises ( product ) to sell or get to market. A language selection should consider two things, talent pool and maturity of the tools. When you go hire developers, I want a strong pool to be able to be selective in finding attitude with the right aptitude, and I want them to be productive ASAP, so that means that we might bring in…

Exactly, I did startup before, and my take is: Rust is absolutely the worst choice for startups.

to survive startup, you need a large pool of talents, mature and verified and boring stack, easy to find tutorials, etc. The least thing you want is to spend cycles on fancy new bleeding unstable languages to build your earth shaking product.

Re: Why Rust is a great choice for startups

#189
post #170

Earlier quoted context omitted.

Maintenance is where Rust really shines and makes up for it's initial learning curve and slightly slower writing speed. In terms of hiring I can't imagine it being a problem either. There are lots of developers who would jump at the chance to work with Rust, and comparatively few Rust jobs (especially ones that don't involve working with cryptocurrency).

Can anyone speculate why there's so much crypto using Rust as opposed to everybody else? I am afraid crypto will end up giving Rust a bad name.

There seem to be a lot of long running Rust job openings in the cryptocurrency space. Maybe those positions are always open because nobody wants to work there? You asked for speculation :)

Re: Why Rust is a great choice for startups

#190
post #164

Earlier quoted context omitted.

Java _used_ to give me that "it just works" feeling when I started using it... in 1999. The rich type system makes the biggest difference. In Rust, you can solve a problem by first modelling it through structs and enums and then define operations pertaining to elements of the model. rustc (the compiler) has such a grasp on the implications of a given model that it will most often guide you toward a near-optimal (and…

Rust has a cool type system, but I think you give it much more credit, like it doesn’t have dependent types where the implementation can often be filled in literally. Other than checking mutability and nullness, I really don’t think that Rust would be that much ahead compared to even an “older” language like Java. Also, java now has ADTs so “exhaustive checks” are available there as well.

I can't compare with Java, but I can for C#. With Rust I find that I have much more confidence that I understand what the code is doing primarily due to the borrow checker and how Rust enforces unique vs shared access vs ownership. Just by knowing the types involved, I know exactly what a function could potentially do to what I pass in just by looking at the call site.

In C#, I can't tell at the call site whether a function could mutate what I pass in; not without looking at the implementation of the function and anything it passes that object to. With Rust, how it's passed in completely informs me about this. If it's passed by shared reference, it can't mutate. If it's passed by unique reference, it might mutate. If it's passed by ownership, then I can't access the instance any more anyway, so it's not my problem.

Post reply on HN