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

A Rust shaped hole

mnvr.in

Post reply on HN
Print view View original

261–270 of 319 posts

Re: A Rust shaped hole

#261

Post by blub »

Expurple wrote: post #220
blub wrote: post #210

Earlier quoted context omitted.

Many of us strongly prefer handling some complexity ourselves that we can then tackle with tests, CI, fuzzing, etc if it means we don’t have to jump through hoops to satisfy the compiler before we can even see our code running. Yes, Golang and Python and Java are very easy to start programming in. And unless we’re dealing with some really complex problem, like next-gen cryptocurrencies ;), by the time the Rust teams…

> the Golang/Python/Java teams have already released to customers. ...have already released a broken prototype that appears to be working for now. I'm yet to see a case where manually "hardening" your software is faster than writing a "similarly-good" program in Rust. That's just anti-automation. Why repeat the same work in every project and bloat your codebase, when the compiler can carry that burden for you? In my…

The idea that one needs Rust to write reliable software is not only ridiculous at a logical level, it is also contradicted by the fact that Rust is but a tiny, irrelevant subset of safety-critical software or really all software. If it were really “preferable for writing such production software”, more people would be using it.

But they don’t because the compiler does not carry the burden for you. It puts the burden of writing code in a way that satisfies the Rust lifetime management design on you, and that’s what you’ll be doing forever.

There zero proof that Rust software is higher quality than equivalent e.g. Swift or Java. The memory-safety trick only works against C and C++.

Re: A Rust shaped hole

#262

Post by blub »

ViewTrick1002 wrote: post #239
imtringued wrote: post #233

Earlier quoted context omitted.

Yeah, the thing is, the moment your software has crossed the boundary of success, it becomes a burden, not a blessing. You are now stuck with it and you better have made sure that you're happy with it the way you built it, because you're not moving on from this project any time soon. Maybe Rust isn't optimized for throwaway projects and that's fine.

I think you can do throwaway projects and prototypes about as fast in rust. But it requires a different mindset which I think many in our industry finds hard to work with. Rust exposes the imperfections rather than hiding them until you explicitly check for them like in most other languages. Just clone and unwrap liberally and throwaway projects go fast.

What we’re seeing in practice is not throwaway software but successful companies built over many years using e.g. Golang. When they grow big enough to pay the Rust tax and can’t squeeze more performance out of their set-up they switch to Rust.

Starting something in Rust only makes sense for very few domains and software categories.

Re: A Rust shaped hole

#263

Post by abhijat »

wk_end wrote: post #18
ashishb wrote: post #12

Earlier quoted context omitted.

TypeScript is good as a language. You can't generate static binaries out of it (except Docker images) and that itself is a deal breaker.

I'd love to see someone develop a compiler for TypeScript that got, say, Ocaml-like performance. There's a bunch of reasons why that'd be tough though - you'd probably want a language very-similar-to-but-not-quite-like-TypeScript.

There used to be reasonml but I'm not sure how active it is these days.

Re: A Rust shaped hole

#264

Post by bryanlarsen »

adastra22 wrote: post #122
bryanlarsen wrote: post #89

Earlier quoted context omitted.

> but I have no experience refactoring Rust code But you're willing to write many comments complaining that Rust is hard to refactor. Rust is the easiest language to refactor with I've ever worked in, and I've used a couple dozen or so. When you want to change something, you change it, and then fix compiler errors until it stops complaining. Then you run it, and it works the first time you run it. It's an incredible…

Also, although it was not designed with this in mind, the described process adopts VERY well to LLMs. You can make a refactoring change, then tell the LLM to "run cargo check and fix the errors." And it does a very good job of doing this.

An LLM will do it with fewer clicks, but the rust-analyzer LSP hook on your editor also helps tremendously.

Both the LLM and humans doing it are relying on the fabulous work the rust compiler team has done in generating error messages with clear instructions on how to fix problems.

Re: A Rust shaped hole

#265

Post by gooooood »

blub wrote: post #262
ViewTrick1002 wrote: post #239

Earlier quoted context omitted.

I think you can do throwaway projects and prototypes about as fast in rust. But it requires a different mindset which I think many in our industry finds hard to work with. Rust exposes the imperfections rather than hiding them until you explicitly check for them like in most other languages. Just clone and unwrap liberally and throwaway projects go fast.

What we’re seeing in practice is not throwaway software but successful companies built over many years using e.g. Golang. When they grow big enough to pay the Rust tax and can’t squeeze more performance out of their set-up they switch to Rust. Starting something in Rust only makes sense for very few domains and software categories.

I wonder how Go would fare if it had a production-ready LLVM/GCC backend. I wouldn't be surprised if much of the performance differences between Go and C/C++/Rust comes down to optimized codegen (rather than GC, which is what people often complain about Go). Not saying that GC pauses might not be an issue in some cases, but still...

Re: A Rust shaped hole

#266

Post by tayo42 »

sealeck wrote: post #221
tayo42 wrote: post #150

Earlier quoted context omitted.

Does ocaml have a mature ecosystem of libraries and dependencies? And easy way to manage them? Even rust with all its hype lacks in this area imo.

It doesn't have a great ecosystem of libraries, but it _does_ have a good way to manage them: https://dune.build/ , which as I understand it was developed at Jane Street (lots of code and dependencies) and is now open source. > Even rust with all its hype lacks in this area imo. This is surprising to me! I find that Rust has pretty excellent tooling, and Cargo is substantially better than the package manager in most…

I didn't write that clearly. I meant the ecosystem still isn't mature. Agree with you rust tooling is major positive for the language

Re: A Rust shaped hole

#267

Post by throwawaymaths »

sealeck wrote: post #218
whytevuhuni wrote: post #144

Earlier quoted context omitted.

If anything I'd like an even lower-level Rust. There's so many good high-level languages to choose from, but when you need to go low-level, there's essentially only C, C++, Rust. Maybe Zig once it reaches 1.0. What we need isn't Rust without the borrow checker. It's C with a borrow checker, and without all the usual footguns.

> What we need isn't Rust without the borrow checker. It's C with a borrow checker, and without all the usual footguns. Which would look a lot like... Rust!

except you would have macros, protocols, raii, a library system fragmented over async/noasync...

Re: A Rust shaped hole

#268

Post by throwawaymaths »

shmerl wrote: post #141
peppingdore wrote: post #138

Earlier quoted context omitted.

Rust is unreadable by default

Syntax could be less terse and abbreviated, I agree. But it's not unreadable. On the other hand some complain that Rust sometimes is too verbose, so I guess it's some balance.

verbosity is not really the same as nonreadability.

i would say the biggest factor for nonreadability is not being able to chase function calls using simple text search, with as few indirections as possible. proc macros and to a lesser degree traits make that difficult.

Re: A Rust shaped hole

#269

Post by WorldMaker »

childintime wrote: post #214
Sophistifunk wrote: post #108

Earlier quoted context omitted.

I very much enjoy reading and writing TS code. What I don't enjoy is the npm ecosystem (and accompanying mindset), and what I can't stand is trying to configure the damn thing. I've been doing this since TSC was first released, and just the other day I wasted hours trying to make a simple ts-node command line program work with file-extension-free imports and no weird disagreements between the ts-node runner and the l…

Fully agree. Try bun.

Or deno.

Re: A Rust shaped hole

#270

Post by Expurple »

blub wrote: post #261
Expurple wrote: post #220

Earlier quoted context omitted.

> the Golang/Python/Java teams have already released to customers. ...have already released a broken prototype that appears to be working for now. I'm yet to see a case where manually "hardening" your software is faster than writing a "similarly-good" program in Rust. That's just anti-automation. Why repeat the same work in every project and bloat your codebase, when the compiler can carry that burden for you? In my…

The idea that one needs Rust to write reliable software is not only ridiculous at a logical level, it is also contradicted by the fact that Rust is but a tiny, irrelevant subset of safety-critical software or really all software. If it were really “preferable for writing such production software”, more people would be using it. But they don’t because the compiler does not carry the burden for you. It puts the burden…

> The idea that one needs Rust to write reliable software is not only ridiculous at a logical level

I never said that. I said that it's more appropriate and productive.

> If it were really “preferable for writing such production software”, more people would be using it.

There are many valid reasons for not using it, even in new projects. Such as human preferences, lack of specific libraries, and simply not having time to learn yet another language for a non-10x benefit.

> the compiler does not carry the burden for you. It puts the burden of writing code in a way that satisfies the Rust lifetime management design on you, and that’s what you’ll be doing forever.

It carries a different burden for me. In exchange for the burden that you mention, I don't worry about mutable aliasing bugs (including data races), breaking the code by refactoring it, manually unit-testing basic properties that could be types, debugging non-obvious non-local effects (such as exceptions and null values invisibly propagating through the layers of the app), micro-optimizing the performance manually, and so on. The benefits are known. I've almost forgot how to use a debugger at this point.

It's a tradeoff. I find it more comfortable and less cognitively-taxing to work this way, once the initial learning curve is behind. Less unpredictable problems to distract you from solving the problem. The borrow checker problems largely go away as you get more comfortable with it. And it's a skill that's instantly transferrable between all Rust projects, unlike project-specific defensive practices in other languages (the "manual hardening" needed to get decent quality). It's a long-term investment that automates a small, but not insignificant part of your work.

> There zero proof that Rust software is higher quality than equivalent e.g. Swift or Java.

The Google's director of engineering gave a talk saying that their Rust teams are just as productive as their Go teams, while also enjoying "a decreased defect rate over time": https://www.reddit.com/r/rust/comments/1bpwmud/media_lars_be...

> The memory-safety trick only works against C and C++.

That's absolutely true, and that's an important thing to keep in mind when framing discussions about Rust.

Post reply on HN