Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rust is a great choice for startups

dailyedit.com

Post reply on HN
Print view View original

131–140 of 294 posts

Re: Why Rust is a great choice for startups

#131

Post by steeleduncan »

nerdponx wrote: post #83
gary17the wrote: post #67

Actually, I think Rust is a godsend to startups for the following reasons: 1.) startups rarely have time, expertise or budget for extensive unit tests, mock-up tests, UI-automation tests or paid third-party Q/A services, 2.) software product users these days have a strong tendency never to submit bug reports or work with product support, but instead just leave negative reviews and/or just move on to the competition,…

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 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.

Re: Why Rust is a great choice for startups

#132

Post by pizza234 »

mritchie712 wrote: post #43
ThePhysicist wrote: post #13

I started my first Rust project a month ago after working for years in Golang and before that Python (and before that Perl, C/C++ and Turbo Pascal). I really like the whole experience but I'm not sure if I'd recommend writing all your backend code in Rust as a startup. Rust definitely provides a pleasant experience and is very powerful. If you can stick to the standard library I think Rust is great, though the packag…

Two things I consider: 1. what languages does the team already know best? 2. are any languages dominant in the problem space? for us, I've used Python over 10 years and Python is the leader in data science / analytics. Some things might be a little faster if we used Rust, but compute is cheap. Go with what you know.

I agree that one doesn't necessarily need a fast language, but I think that the "hardware is cheap" idea is very misleading. Renting/owning 5x as much servers may be cheap, but maintaining them isn't.

Re: Why Rust is a great choice for startups

#133

Post by WuxiFingerHold »

Many good points that I'm able to relate to. However, the post is too exaggerated, e.g.:

> The amount of debugging required for Rust projects is an order of magnitude less than I’ve seen anywhere else.

Sorry, that's just nonsense. I've done a large amount of .NET and Java and a good amount of Go and Rust. Stating that debugging effort in other languages is at least 10 time (which is an order of magnitude) higher is a huge exaggeration.

Also, one absolute critical point is missing: The reliability of the ecosystem. That's the biggest weakness of Rust. Rust's NPM like ecosystem is just brittle and dangerous. There're enough examples of widely used crates that caused issues due to maintenance or that had malicious code. For all the undeniable benefits Rust brings, this single big disadvantage makes it actually not the best choice for startups.

I sometime wish Rust and Go had a baby ...

Re: Why Rust is a great choice for startups

#134

Post by jedisct1 »

What matters for a startup is time to market.

So, go with a boring technology that the existing team is already familiar with, and that fits your use case.

There's nothing wrong with PHP, Python, Go, JavaScript or Java. Even modern "no code" tools such as Bubble can get a first version done in a minimum amount of time.

Re: Why Rust is a great choice for startups

#135

Post by rowls66 »

stevepeg wrote: post #81
pjmlp wrote: post #75

Earlier quoted context omitted.

So, F# with NuGet/Fake, Scala or Kotlin with Maven/Gradle, OCaml with OPAM. Those points are hardly Rust specific and apply to any compiled language with ML influences.

No disagreement here. My post is a praise of Rust, not "everyone must use Rust!". These languages and tools are also great! (edit) added 'tools'

Maybe you should retitle your article "Why Rust is one of many great choices for startups"

Re: Why Rust is a great choice for startups

#136

Post by gwbas1c »

BigJ1211 wrote: post #116
spaintech wrote: post #74

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…

On the other hand, you might attract talent that wants to use a specific language like Rust, but hasn't had the chance in their current professional environment.

I've been toying with Rust on and off for a few years. It has an extremely steep learning curve. As a novice it's incredibly difficult to do things that are trivial in other languages.

> On the other hand, you might attract talent that wants to use a specific language like Rust, but hasn't had the chance in their current professional environment

Maybe if you're doing something embedded? Otherwise, the learning curve is so steep that you're better off just buying a faster computer to run C#/Java/NodeJS/Python/Whatever.

Re: Why Rust is a great choice for startups

#137

Post by giraffe_lady »

Icathian wrote: post #123
nerdponx wrote: post #83

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.

It's more like "if you need your code to go extremely fast" though, which is honestly pretty rare in my experience. Ocaml is no slouch and people regularly build great products on much slower languages and that's rarely the limiting factor.

Re: Why Rust is a great choice for startups

#138

Post by dijit »

WuxiFingerHold wrote: post #133

Many good points that I'm able to relate to. However, the post is too exaggerated, e.g.: > The amount of debugging required for Rust projects is an order of magnitude less than I’ve seen anywhere else. Sorry, that's just nonsense. I've done a large amount of .NET and Java and a good amount of Go and Rust. Stating that debugging effort in other languages is at least 10 time (which is an order of magnitude) higher is a…

yeah, I love Rust but this rings hollow for me too.

debugging python is a pleasure compared to Rust, and it makes sense that this is the case... Rust itself performs well because of the compilation stage to native code, but it gets harder to step through because of that.

Re: Why Rust is a great choice for startups

#139

Post by gwbas1c »

strken wrote: post #117
spaintech wrote: post #74

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…

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 extremely fast.

Rust definitely has its use; but in the case of a startup making an IO-heavy product, you're going to be better off spending your precious resources on a slightly faster computer instead of struggling with Rust's learning curve.

Re: Why Rust is a great choice for startups

#140

Post by tialaramex »

FpUser wrote: post #122
mwcampbell wrote: post #107

Earlier quoted context omitted.

This constant refrain must be discouraging to the people who have worked so hard on async rust. Can we please restrict our criticism to specific problems, and temper it with gratitude for the amazing things that the Rust developers have already given us free of charge?

I am not sure what is so "un-tempered" in the original message (assuming it is not technically incorrect) and what makes Rust so special that criticism must be "tempered with gratitude".

It's too vague. The claim is that async "still doesn't really work" but like, how so?

Sometimes you could make a claim like that about a feature and it's more or less accurate just as it stands. C++ 20 Modules were like that (still might be like that?) on most platforms, 'cos it turns out that's a lot of work for a compiler to implement and it's important to say you have the feature even if you know it doesn't work well. But even then, I'd rather see e.g. "C++ 20 Modules blow up if I try to A, or B, or C... or Z" it's just that I can understand if your list is a page long "doesn't really work" seems more concise than listing everything.

There are clearly people who are frustrated by aspects of Rust's async. Some of those frustrations are fixable, some are consequences of a principle decision that's unlikely to be revisited, and who knows if you won't say what frustrated you

Suppose I said Go's generics "don't really work". Do I mean that they aren't monomorphised in the way I hoped? That the syntax is too untidy for me? That the Go libraries aren't yet making them ergonomic? That I found a compiler bug? No way to know.

Post reply on HN