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

341–350 of 496 posts

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

#341

Post by 8note »

brimstedt wrote: post #172
ozten wrote: post #113

Earlier quoted context omitted.

NodeJS kind of muddies the waters. It ate a lot of use cases that would have previously been done in Java. That created conflict between backend teams that wanted statically typed code and a "boring" tech choice against "full stack" developers creating a backend service. I think Rust will see a lot of adoption in web services that are glorified CRUD APIs. It would have been a poor choice to do many of these workloads…

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…

I find typescript makes the most common things I do in business app software as straightforward as possible. That is, making copies of objects with slightly different structure to pass them to some other system. Typescript is just fantastic for plumbing.

To do the same in java means making a billion model files with a billion transformation functions on them

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

#342

Post by tgbugs »

PaulHoule wrote: post #63
Jensson wrote: post #14

Earlier quoted context omitted.

In Java functions declares Exceptions in its type signature, so it does all of that automatically. Then you get a compile error if you don't handle it in the function, or you need to declare the function throws it, so it is type safe. Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that.

We are in the distributed systems age. If systems are composable, operations can fail for reasons that are completely unfathomable to the client. It's not reasonable to have a SharkBitTheOpticFiberCableException and 100,000 other ones that handle every reason why an operation failed. What the client should know is how an error affects what it is doing, it wants answers to questions like * Is it likely this error will…

I had a similar thought a while back [0]. Developing a sane ontology of error types and their implications is a hard problem, but I think it could be done. The subset of errors that is the most frustrating and hard to deal with are ones where, as you point out, the client will have no way to estimate how long a failure mode might persist, at which point you resort to exponential backoff (actually probably an s-curve).

The issue is that sometimes the solution to the issue would require the client to get up and get out a shovel, and go dig somewhere or something. When the abstractions break down that hard there isn't really a way for the developer of the code to handle that unless they somehow stuff a full blown AGI into their program, and even then it would be a stretch.

0. https://github.com/tgbugs/idlib/blob/master/docs/identifiers...

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

#343

Post by huijzer »

pcwalton wrote: post #264
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…

> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actua…

You mean to link against Rust binaries or can you make library files too? Compared to, say, SQLite as a single C file, I thought that Rust projects are not super easy to use as a dependency

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

#344

Post by jossclimb »

weavie wrote: post #32

I've been writing Rust professionally for a few years now and if there's one thing I've learned it's that if you ever write a function that takes a parameter of `impl Fn(&Vec ) -> &'a str` you are going to be in for some pain. Just make it `impl Fn(&Vec ) -> String`. It is highly unlikely that the extra allocation is ever going to be noticed in the performance. Just because Rust pretty much forces you to be explicit…

A lot of programmers will look at '`impl Fn(&Vec) -> &'a str`' and think what the hell is that, alien hieroglyphics?

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

#345

Post by ameliaquining »

huijzer wrote: post #343
pcwalton wrote: post #264

Earlier quoted context omitted.

> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actua…

You mean to link against Rust binaries or can you make library files too? Compared to, say, SQLite as a single C file, I thought that Rust projects are not super easy to use as a dependency

Rust can output library files that use the C calling convention, either static or dynamic. Doing this entirely by hand is pretty annoying, because your API surface has to be C-compatible (so can't contain a lot of Rust's useful language features) and because you still have to do the other half of the FFI to use the library from the other language. However, it's possible to develop automated language-specific tooling to make this easier, with PyO3 being a particularly impressive example.

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

#346

Post by 8note »

Larrikin wrote: post #30
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…

Despite what CS and SE classes try to drill into you, null results or failure cases are nearly always better handled right when they happen instead of passing them up with layers of exception handling. Log it, pass null up, and just immediately handle it. Fail early and none of the rest of the function matters. Even types of exceptions are rarely useful results outside of reading the logs or sometimes in libraries ou…

The most important considerations for errors is whether they can be retried, and who needs to change something to fix it.

The types can be useful for communicating this

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

#347

Post by adastra22 »

galangalalgol wrote: post #176
adastra22 wrote: post #139

Earlier quoted context omitted.

Golang absolutely has a faster development cycle than Rust. Unless you’re a Rust expert who never touches Go, but then it’s an issue of familiarity. Go devs hit the ground running and the ergonomics are streamlined, and the borrow checker and other rust restrictions don’t get in the way.

Given my downvotes you seem to be with the consensus on this one. I had 30 years of c++ development going into rust and I never found myself fighting the borrow checker. Golang seemed the same, just started coding and stuff worked mostly. But, the complexity of rust was familar coming from c++ with generics and macros but without some of the footguns, so it just seemed like power, not clutter. I like go, but I wouldn…

30 years of C++ can inoculate you to the idea of hideous amounts of boilerplate, or worrying about memory allocation timelines and such. I'm a 25 year C++ veteran myself.

I recently wrote an asynchronous microservice in C++, because it needed to use a C++ library I'd already written. Took about two weeks of effort, and clocked in at 1500 loc, not counting tests or the half-dozen external dependencies. I rewrote it in 100 lines of idiomatic Go using nothing except the standard library a few days ago. That's a 10x reduction in both lines of code and development time, although it's a bit unfair because I had already done the C++ version first. That is after giving up on a Rust version that was already weighing in at ~1000 LOC in an unfinished state.

After this experience, I don't think I'd ever use C++ or Rust again for a concurrent web service, unless there was hard real-time latency requirements. Golang is just so much better streamlined for that application, and the standard library is batteries included.

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

#348

Post by dividedbyzero »

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

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 bad as that even on genuinely big codebases. Hundreds of ms, sure, but minutes just getting the JVM up and running? I can see how that would be problematic.

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

#349

Post by dcow »

EVa5I7bHFq9mnYK wrote: post #310
dhbradshaw wrote: post #89

We have a fairly complex app with a front end in Typescript and a back end in Rust backed by Postgres on AWS. My favorite part of the job is coding in Rust and we do a lot of cool things in that backend code. Unfortunately, most often the Rust code is the fastest and easiest part of a change, which means that I spend most of my time solving problems either on the front end with Typescript or on CI and infra type thin…

Backend code is simpler because is has two limited well defined surfaces (API for the frontend on one side and database on the other side). Frontend is harder because it has to interface with those impolite hairy meat creatures ...

Frontend code has two as well: the input methods (mouse, keyboard, screen) and the API surface.

> Backend code is simpler

I hear this every once in awhile and think it's mostly a front end happy hour misrepresentation that makes everyone feel good so it gets repeated. The service layer of an application is very often far more complicated than, or to be fair, at least as complicated as, the user interface. Front end devs just typically aren't good at chopping up their problem into nice interfaces and therefore struggle to test it reliably or make large broad changes efficiently. This is where the complexity comes in. That's not a stab at FE devs, it's just not a skill that often gets rewarded in FE work so it's not very prevalent, which I find sad.

The service layer has to deal with enforcing the correctness of business logic despite the infinite ways the meat monkeys can interact with it. It does this by defining clear boundaries on the outside and by ensuring the transactional correctness of logic on the inside. While front end folks have to figure out the correct UX to use to successfully communicate with with a user, service layer folks have to figure out all the implications of a single action the user wishes to take and make sure it happens correctly. Data validation, data modeling, transactions, errors, queuing, retries, scaling, monitoring, etc. are all things that would probably make the average FE dev explode if thrust upon them.

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

#350

Post by f_devd »

huijzer wrote: post #343
pcwalton wrote: post #264

Earlier quoted context omitted.

> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs. One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actua…

You mean to link against Rust binaries or can you make library files too? Compared to, say, SQLite as a single C file, I thought that Rust projects are not super easy to use as a dependency

Depends on how you link rust, using PyO3 makes it arguably easier to do link python code to rust than any C construction I could think off. Linking a single C file into python is quite difficult (if not using JIT like cppyy) because you need to make bindings & conversion often on both sides for each exported function.
Post reply on HN