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

I love building a startup in Rust but wouldn't pick it again

propelauth.com

Post reply on HN
Print view View original

481–490 of 496 posts

Re: I love building a startup in Rust but wouldn't pick it again

#481

Post by codethief »

flohofwoe wrote: post #448
gpderetta wrote: post #117

Earlier quoted context omitted.

Exceptions are not a form of gotos, they are both less powerful as they are structured and more powerful (as they are nonlocal). They desugar to continuations, but so does rust option type handling and ?. In fact they are pretty much equivalent. I'm not terribly familiar with either language, but I don't see any particular difference between swift and rust error handling for example, swift will also mark fallible fun…

I was actually wondering (in Zig, which has a per-statement "try" which is essentially the same as the ? in Rust) whether it also makes sense for whole blocks, which would look a lot like traditional try-catch block in languages with exceptions, e.g. instead of: try may_fail_1(); try may_fail_2(); try may_fail_3(); ...this could be grouped into: try { may_fail_1(); may_fail_2(); may_fail_3(); } ...but would behave ex…

I've been pondering the same thing![0] Essentially, one would get (checked-)exception-like behavior, except that performance would be better, and whether a function can fail or not would still need to be declared explicitly in its return type.

> But I guess that forcing individual trys makes you think harder about handling individual errors than just pushing the responsibility for error handling up the callstack.

It probably does but it can also make code much harder to read if you have to check for errors after every other line. I'm a bit divided on this.

[0]: https://news.ycombinator.com/item?id=34856910

Re: I love building a startup in Rust but wouldn't pick it again

#482

Post by dboreham »

dividedbyzero wrote: post #348
dboreham wrote: post #186

Earlier quoted context omitted.

You exec a process expecting it to begin operating, providing some networked service, in a reasonable time. Instead it doesn't do that. It spends tens of seconds, sometimes minutes, running JIT and other sundry startup overhead. You may not have seen this if you haven't used Scala...

Genuinely curious, what kind of application are you running? Which JVM are you using? Are you aggressively GC tuning? Very low on memory? I've used Scala from 2.8 up to 3.0, for microservice systems, monoliths, data pipelines, machine learning (way back), desktop apps for research using Swing, an Android app (worst idea ever), highly imperative to very functional, and I don't think I've ever seen anything remotely as…

Ok, so to expand: applications that I've been responsible for from the beginning have not had long start up times. Where I've seen it is with other folks applications where I was hired as a consultant to look at performance.

The most recent example was a Scala monolith. It had to use JVM 1.8 because prevented migration to 11 (tried quite hard, but never succeeded). GC tuning doesn't really apply when considering start up delay, but yes it had been tuned over the years. Memory was not limited. The application, mainly due to Scala, had tens of thousands of classes. They all seemed to get JIT'ed on start up, which was the primary reason for the slow start up. People involved (who had come from heavy Scala shops like Twitter) seemed to think it was normal.

Re: I love building a startup in Rust but wouldn't pick it again

#483

Post by dboreham »

oauea wrote: post #218
dboreham wrote: post #184

Earlier quoted context omitted.

Rolling deployment is a hack imho. Adds complexity and hence yet more potential failure modes.

Hardly, it's a fantastic guardrail when combined with health checks. You can say "you don't need it", but everyone makes mistakes sometimes. Make those mistakes not matter. You also take backups, right? Same idea.

It has a non-zero cost though, which is why I don't like it. Things go wrong with the "roll" for example. You have potentially two versions of your code running against the same DB for some time.

Stop -> deploy code -> start is simpler and less likely to go wrong.

Re: I love building a startup in Rust but wouldn't pick it again

#484

Post by ReflectedImage »

tcfhgj wrote: post #478
ReflectedImage wrote: post #475

Earlier quoted context omitted.

Just finished my learning Rust project (very basic version of minecraft). It's great for writing highly parallel high performance code. At no point was the memory of my program ever replaced with the number 53 nor did memory become corrupt due to multiple threads accessing the same areas at the same time. Much better than C++. Did my Rust project suddenly contain no errors or did it never crash? Well no. How did it c…

Nobody claims that Rust code contains no errors, but less. Rust removes types of errors that can happen. Logic errors don't belong to the types of errors Rust 'removes'

When you are using a duck typed language, the overwhelming majority 90%+ of errors are logic errors.

Re: I love building a startup in Rust but wouldn't pick it again

#485

Post by legerdemain »

d-z-m wrote: post #476
legerdemain wrote: post #293

Earlier quoted context omitted.

> You can ingest and emit JSON in any language. How is this relevant? Serving a JS application to a client is not like serving a JSON API. > You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. Not in my experience. Compared to front-to-back JS, shipping your applications as WASM ends up with downloads and…

> How is this relevant? Serving a JS application to a client is not like serving a JSON API. In some JS applications, the way the frontend code communicates with the backend is via JSON API endpoints. I believe GP was just pointing out that you can write that JSON API in any language you want. > not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front e…

My understanding is that to get reasonable WASM file sizes, one must use tinygo (a C reimplementation). tinygo is a WIP, although I wish I could find a better updated description of what's missing than this page on their site: https://tinygo.org/docs/reference/lang-support/

Re: I love building a startup in Rust but wouldn't pick it again

#486

Post by dcow »

ReflectedImage wrote: post #484
tcfhgj wrote: post #478

Earlier quoted context omitted.

Nobody claims that Rust code contains no errors, but less. Rust removes types of errors that can happen. Logic errors don't belong to the types of errors Rust 'removes'

When you are using a duck typed language, the overwhelming majority 90%+ of errors are logic errors.

By definition this is true. Duct type languages don't care about whether your program is expected to work at compile time. They just run it and hope it does so it's all "logic errors".

I've experienced an array indexing issue in Rust exactly once and when it happened the stack trace told me exactly where and then I did exactly what you did: changed default to new or something and called append instead of my_vec[N] = foo. This issue was caught in my test btw.

That leaves infinite loop which is a problem in any language if you aren't intending to loop infinitely. So it's simply not something Rust fixes. I must say the number if times I've had a program infinitely loop and it be a problem that made it through a basic test of the logic is minuscule compared to the number of times I've had a program just shit the bed with poorly managed pointers or corrupt memory.

So you're basically proving our point. Rust eliminated all your bugs except an infinite loop and an array index out of bounds. I bet your mincraft clone is running flawlessly and you have Rust to thank.

What Rust has shown me is that programmers by and far make more unforced semantic errors (like not properly managing a pointer or accessing memory without proper synchronization) than they do logic errors. When you remove all the silly BS errors, you're left with surprisingly few problems to solve and you can almost surely blame yourself and find and fix the issue when one does crop up. It's way different. If you haven't, try writing Minecraft in Java.

Re: I love building a startup in Rust but wouldn't pick it again

#487

Post by gofreddygo »

zeroxfe wrote: post #37

If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…

Or as Charlie Munger would invert,

"What kind of startup would fail because it chose Rust ?"

Then don't be.

Re: I love building a startup in Rust but wouldn't pick it again

#488

Post by d-z-m »

legerdemain wrote: post #485
d-z-m wrote: post #476

Earlier quoted context omitted.

> How is this relevant? Serving a JS application to a client is not like serving a JSON API. In some JS applications, the way the frontend code communicates with the backend is via JSON API endpoints. I believe GP was just pointing out that you can write that JSON API in any language you want. > not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front e…

My understanding is that to get reasonable WASM file sizes, one must use tinygo (a C reimplementation). tinygo is a WIP, although I wish I could find a better updated description of what's missing than this page on their site: https://tinygo.org/docs/reference/lang-support/

This page[0] seems to have some good information(on stdlib support at least).

As far as file sizes go, you're right. It might be possible to get better results deploying a brotli'd or gzipped file instead[1].

[0]:https://tinygo.org/docs/reference/lang-support/stdlib/ [1]:https://github.com/golang/go/wiki/WebAssembly#reducing-the-s...

Re: I love building a startup in Rust but wouldn't pick it again

#489

Post by dcow »

ReflectedImage wrote: post #471
tcfhgj wrote: post #469

Earlier quoted context omitted.

> Programmers write bugs per line Source? Hack more code into one line -> less bugs for the overall program? doubt Use Typescript instead of JS (thus add a few loc) -> more bugs? certainly doubt

That's really a question for Google or Stack Overflow. One source would be: https://www.oreilly.com/library/view/code-complete-2nd/07356...

I think the metric you’re looking for is bugs per line not raw total bugs. Bugger programs have more bugs is trivially true if all programs had the same rate of bugs per line.

Re: I love building a startup in Rust but wouldn't pick it again

#490

Post by satvikpendem »

Klonoar wrote: post #364
Animats wrote: post #237

Earlier quoted context omitted.

> If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess o…

>I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested. The thing here is that most web backends are basic CRU…

Exactly. And for phone apps, using Flutter with flutter_rust_bridge is a great choice for FFI.
Post reply on HN