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

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

Post reply on HN
Print view View original

291–300 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#291

Post by 3a2d29 »

satvikpendem wrote: post #284
3a2d29 wrote: post #266

Earlier quoted context omitted.

Fair, but again I think you can get all those things with a GC language. Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.

> Speed in programming never matters except in the systems space. This kind of attitude is how we get bloated Electron apps that HN (including me) loves to complain about. Speed should be a first class consideration, not something to throw away for later. > No one is gonna be able to tell Rust vs Go in a web API Debatable, Discord moved from Go to Rust [0] because they were getting latency and CPU spikes from Go's GC…

Bloated is the problem, not language speed. I may have misspoke, what I meant was speed in language never matters.

And the discord instance was because it was systems/performance critical software they rewrote. They didn’t rewrite there web APIs. Discord mentioned the rewrite is now rust with C++ glueing it together. No way you are using C++ unless you have to.

I’ll agree with you on python venv/pip. Ugh what a mess. I like cargo, but honestly I think you could argue cargo also is an issue. When you bring in 100 crates, you just gotta hope all the unsafe code in them are safe.

A static analyzer found 200 memory unsafety issues in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/

Memory safe GC languages you don’t have to worry about that, and you can get a package manager.

Re: Using Rust at a startup: A cautionary tale

#292

Post by widdershins »

3a2d29 wrote: post #266
satvikpendem wrote: post #211

Earlier quoted context omitted.

I mentioned the benefits elsewhere. Faster, more throughput, uses far less memory, more ergonomic developer experience (Elixir for example is not statically typed), rock solid stability (my API and anecdotally those of others I hear have never crashed). The risk is small compared to the benefits. I'm not sure why you keep saying there aren't benefits because there are. Now you might not agree they're good enough for…

Fair, but again I think you can get all those things with a GC language. Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.

> Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API

Speed equals money. The same app running at twice the speed uses half the compute resources. You may also gain a lot of simplicity if you don't need to distribute your architecture so early on.

Re: Using Rust at a startup: A cautionary tale

#293

Post by kolbe »

zozbot234 wrote: post #223
kolbe wrote: post #112

Earlier quoted context omitted.

I can only give you some guesses, but I think there's some false sharing type of bug going on. There's also an issue with the fact that LLVM hasn't released a target for my CPU yet (I use a Zen 4), and who knows what bugs are caused by targeting the wrong CPU. In a single threaded version, it beats C#, though not by as much as I would have expected. The essence is that I have to run the same calculation on a large ar…

> I use AVX-512, and it's not even 2x faster, though it is faster--it should be more than 2x faster because AVX-512 has better instructions to work with. But when I combine this with doing the calculation in threaded parallel chunks on the array, it goes far slower than it should. You might be saturating your memory bandwidth to the point where it just can't go any faster. Since it seems your problem is easy to paral…

I will say that when I do the same parallelization scheme using non-avx operations, it accelerates properly and goes far faster than the avx versions. One interesting caveat is when the compiler autovectorizes non-intrinsic code, the problem persists.

Re: Using Rust at a startup: A cautionary tale

#294

Post by 3a2d29 »

widdershins wrote: post #292
3a2d29 wrote: post #266

Earlier quoted context omitted.

Fair, but again I think you can get all those things with a GC language. Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.

> Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API Speed equals money. The same app running at twice the speed uses half the compute resources. You may also gain a lot of simplicity if you don't need to distribute your architecture so early on.

If that were true, all enterprise code would still be non-GC

Re: Using Rust at a startup: A cautionary tale

#295

Post by drogus »

optymizer wrote: post #167
pclmulqdq wrote: post #68

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.

Python is not readable to you? The beginner friendly, whitespace-enforcing, almost-like-pseudocode-in-English language - that Python? - is not readable enough, but Rust, where you liberally sprinkle ', {}, !, &, :: or #[] everywhere _is_ readable to you? You must be trolling. You know what Rust looks like to me? Perl without the dollar signs. There's your write-only language, you just have it backwards.

Being able to understand the syntax and by implication being able to understand a single piece of code in front of your eyes doesn't mean you will understand what it actually does. If you're talking about a small piece of code mainly using well known APIs, maybe you will understand it perfectly. But with code calling custom functions in a big codebase? Even when looking at a simple function call in a class:

- if it calls a function on `self`, where is it actually implemented?

- if you pass arguments, can they be mutated?

- can the function throw an exception?

you can't really answer this questions easily and I would argue answering them in Rust is much easier. Also because tooling for statically typed languages can derive much more than for dynamically typed languages.

Re: Using Rust at a startup: A cautionary tale

#296

Post by rob74 »

ColonelPhantom wrote: post #231
Aeolun wrote: post #219

Earlier quoted context omitted.

I dunno, if my exceptions would have to be manually rethrown every time, I’d get really cranky very quickly. I don’t think that’s any better in Rust though.

Rust has many convenient shorthands like the ? operator, where `let x = foo()?` is equivalent to let x = match foo() { Ok(value) -> value, Err(e) -> return Err(e), }

Many convenient shorthands that you all have to be familiar with before being able to write (and read) Rust competently. I guess that's what they mean with the steep learning curve...

Re: Using Rust at a startup: A cautionary tale

#297

Post by rob74 »

widdershins wrote: post #292
3a2d29 wrote: post #266

Earlier quoted context omitted.

Fair, but again I think you can get all those things with a GC language. Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.

> Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API Speed equals money. The same app running at twice the speed uses half the compute resources. You may also gain a lot of simplicity if you don't need to distribute your architecture so early on.

Don't believe the hype: moving from Go to Rust will not make your app (web or other) twice as fast! It might make your developers twice as slow though (as the author of the article noticed)...

Re: Using Rust at a startup: A cautionary tale

#298

Post by karmakurtisaani »

zozbot234 wrote: post #226
almost_usual wrote: post #150

Earlier quoted context omitted.

I agree mostly with this, however, ownership can be strange in Rust if you’re not familiar with it. Something simple like a linked list can be challenging to implement. https://rust-unofficial.github.io/too-many-lists/

> Something simple like a linked list can be challenging to implement. Well, that's because linked lists are not simple. The linked blogpost makes that clear enough.

To expand this a little, the perception that linked lists are easy comes from the fact that the garbage collector does all the heavy lifting on the background. Using a non-GC language reveals the complexities involved.

Re: Using Rust at a startup: A cautionary tale

#299

Post by kinjba11 »

3a2d29 wrote: post #290
mtelgon wrote: post #286

Earlier quoted context omitted.

go doesn't have null safety or adts though? (sum types)

I think you can have null safety in Go and you certainly can have adts. But even then, what about Ada? I’m also not an expert, but I assume between C#/Typescript/haskell/swift that you can find all those things in many GC/safer languages.

Go does not have compile-time null safety or sum types :)

    foo := Foo{"hello"}
    fooPointer := &foo
    fooPointer = nil
    fmt.Println(fooPointer.Bar)
    > panic: runtime error: invalid memory address or nil pointer dereference
In a language like Kotlin a compile time error would prevent `fooPointer.Bar`, and in Rust `nil` does not exist. Go also does not have sum types, see for instance https://making.pusher.com/alternatives-to-sum-types-in-go/

Re: Using Rust at a startup: A cautionary tale

#300

Post by josephcsible »

singularity2001 wrote: post #278
errantmind wrote: post #122

While I respect the author's anecdote, this doesn't match my experience. I've been programming for 20+ years across a wide array of languages and I'm by far the most productive in Rust. With a competent teacher, experienced devs should be able to pick up on the memory model pretty quickly, and that is really the only initial blocker to productivity. After that a dev can essentially write procedural code if they want,…

how can you be more productive in rust, where you do have to worry about object lifetimes than in languages where you don't, and where you can focus more on algorithms, say java?

Because the time you spend thinking about lifetimes is insignificant compared to the time you save by not having to fix bugs that lifetimes prevented from ever existing.
Post reply on HN