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

291–300 of 496 posts

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

#291

Post by AceJohnny2 »

ISL wrote: post #283
AceJohnny2 wrote: post #279

> Perf is easy when you have AWS credits. I get that the point of this article is that launching > sustaining. But I have a horror story about AWS credits for startups: a friend's startup got their account suspended for a couple days when their Credits ran out, they started getting billed 5 digits (as they expected), and Amazon's fraud detection detected this as an anomalous billing pattern and suspended them! For tr…

If those reassurances are in unmistakable writing, a letter from the startup's corporate attorney may yield a quick refund and compensation.

Sure, but in the life of a startup that's just one extra thing they'd rather not have to deal with, and the damage isn't just financial.

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

#292

Post by hinkley »

Sodman wrote: post #239
hinkley wrote: post #80

Earlier quoted context omitted.

One of the things I’ve vowed to do for my next interview cycle is set myself up an empty project with test, and it is appalling how many interviewers assume that implementation without any tests is something a senior developer won’t simply laugh at the suggestion and leave the room. It takes too long to do these basic steps and then copy them to new projects. And generators only work once, if then, which means they a…

You have to remember though that coding interviews != production code. Taken to the extreme, are you also adding logging, metrics, performance benchmarks, etc? TDD is great if you can get it working in a tight interview time schedule - they can also reveal any misunderstandings of requirements before the actual solution is implemented! On the flip side however, many interviewers have experienced countless folks who s…

And in a real situation I have all of these tools set up and running, so I shouldn't need to spend more than a minute faffing about with them. I'm just writing exploratory tests to make sure that I've got the bits right before I put them together. Even in an hour task those tools can be a force multiplier, once you figure out how to make them work instead of fighting them constantly.

What's happening in interview loops is that we're implicitly or explicitly selecting for people who prefer to YOLO instead of writing tests, and then we are surprised how hard it is to get new and existing hires on board with mature testing processes. The people you need don't work here, they work somewhere else.

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

#293

Post by legerdemain »

zozbot234 wrote: post #266
legerdemain wrote: post #257

Earlier quoted context omitted.

This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in…

> want back ends that can interoperate with those front ends. You can ingest and emit JSON in any language. 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. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.

  > 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 memory footprints that are several times larger than the same application in ordinary JS, and this matters a lot for slower networks and mobile clients.

Edit: not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.

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

#294

Post by twsted »

"Building a startup in Rust".

I know the hype around Rust, but this is really exaggerated: you build a startup for creating a product or giving a service, not to have something written in Rust. Your customers should care about what you are offering, much more than about which language do you use.

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

#295

Post by nawgz »

zozbot234 wrote: post #266
legerdemain wrote: post #257

Earlier quoted context omitted.

This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in…

> want back ends that can interoperate with those front ends. You can ingest and emit JSON in any language. 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. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.

> The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here

> You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm)

Lol, you can't be serious

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

#296

Post by thefaux »

dboreham wrote: post #186
dividedbyzero wrote: post #173

Earlier quoted context omitted.

How would real-world JVM startup times matter in deployments?

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

Yeah, Scala is absurdly bad for startup time because of poor modularization of the standard library. It's a decent language with a terrible standard library.

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

#297

Post by WJW »

zozbot234 wrote: post #272
WJW wrote: post #261

Earlier quoted context omitted.

There is probably a good space for Rust in writing the databases, caches and all sorts of proxies as well. I agree though, for most of the stuff I need for $DAYJOB the speed is nice but hardly required. It doesn't really matter if I can generate a HTTP response 50 microseconds quicker if the response then has to travel over the internet for 20+ milliseconds.

It does matter if you're using cloud autoscaling FaaS (previously known as CGI) and paying for those HTTP responses by the microsecond (and by RAM usage as well, which is also typically quite low in Rust).

Not really, the connection won't close until you are done sending it all and have received the relevant TCP ACK messages from the other sides. Being on autoscaling FAAS or not does not matter for that.

In any case, if you are trying to optimize microsecond usage in AWS lambda I hope you have a truly gargantuan amount of traffic and/or have incredibly cheap engineers or the money saved will barely match up to the cost of the engineering hours sunk into them.

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

#298

Post by ReflectedImage »

dcow wrote: post #182

I don't agree. I think the author is conflating two things: 1. learning Rust, and 2. using Rust. If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early. The iteration time issue with Rust is solved by experience. We use Rust and…

Well Python code will on average will be more correct than Rust code.

I'm not sure why you feel Rust code would be more correct than Python code but it certainly isn't true.

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

#299

Post by nawgz »

pdntspa wrote: post #189
brimstedt wrote: post #172

Earlier quoted context omitted.

I've really tried to give js/ts in backend a go. Both by nodejs and deno. And by kickstarting my own projects as well as diving into experienced nodejs developers' code. I really don't see how anyone choses nodejs/deno to anything. Java imo gives you much less trouble, is more stable, has a working (!!!) Unit testing setup and exceptional runtime. Next on my list is to give rust a go, since I'm intrigued by its featu…

And the IDEs which practically write your code for you. I mean yeah Java is so verbose but most of that word vomit is me just tabbing through autocomplete I went back and prototyped a slightly similar app in Python w/ a gui toolkit and I felt like I was driving through exception city. I have made my career writing in dynamic languages so I forgot just how pleasant it was to write in a static one!

> Python w/ a gui toolkit

Sorry, this is always the wrong choice, which is why it felt so bad.

Writing a UI in TypeScript with any of the major frontend frameworks will not require you to wade through run-time exceptions

Java native GUI toolkits are also far more mature

Python and TKinter and similar stuff is always just awful, I've never seen someone put together anything half decent with that stack

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

#300

Post by ngrilly »

oconnor663 wrote: post #188
PaulHoule wrote: post #2

I can't get it why people would prefer to add "?" to everything instead of just having exceptions which automate that behavior. In the bad old days of C there were two kinds of programs: programs without correct error handling, and programs where half the loc are unhappy paths that do what exceptions do... with a huge amount of work. Today people are repeating the same mistakes of the past, putting a "?" on everythin…

I mean, ask the C++ community. They've had exceptions forever, but a large chunk of them forbid exceptions in their codebases. I think there's a pretty good rule of thumb in modern systems-ish language design: If Go and Rust and Zig all do a certain thing, that thing is probably a great idea. These languages have very different priorities, but often they overlap.

Zig, unlike Go and Rust, provides an error return trace showing how the error bubbled up. This is a really interesting idea.

https://ziglang.org/documentation/master/#Error-Return-Trace...

Post reply on HN