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

Was Rust Worth It?

jsoverson.medium.com

Post reply on HN
Print view View original

161–170 of 736 posts

Re: Was Rust Worth It?

#161

Post by badrequest »

dilippkumar wrote: post #84

> After two decades of JavaScript and decent experience with Go, this is the most significant source of frustration and friction with Rust. It’s not an insurmountable problem, but you must always be ready to deal with the async monster when it rears its head. In other languages, async is almost invisible. I am a former C and C++ programmer who lived calling into pthread almost every week for a decade. I use async rus…

Recently tried writing some async Rust to compare the error handling when nested async calls are made to how errors are handled in Go, and it seemed like the trivial example I was trying to write up simply couldn't be done without involving Tokio. That barrier simply doesn't exist in Go, or C#, or Typescript.

For instance, you apparently cannot `await` in the main function without a decorator you import from, you guessed it: Tokio.

Re: Was Rust Worth It?

#162

Post by fullarr »

awesome_dude wrote: post #132
echelon wrote: post #111

Earlier quoted context omitted.

There's a secret effort in the Rust community to supplant Crates.io and create an entirely new package ecosystem with proper namespacing, security, and much better community. Not naming names, but I know several people working to put Crates.io out to pasture. There's a level of playing nice with them for the time being (eg. build reproducibility), but it's only KTLO. Crates.io needs to die for Rust to thrive. They're…

How secret is it now that you've posted on HN about it?

Wait I thought only I could read the secret

Re: Was Rust Worth It?

#163

Post by maxbond »

_aavaa_ wrote: post #85
willsmith72 wrote: post #68

Earlier quoted context omitted.

if it were that simple, I'd take the "billing time" payment every time. Engineers' time is the greatest cost for just about any tech business

And yet the big tech companies are perpetually re-writing their whole stack, or going out of their way to create new compilers for their language in order to lower their billing time.

Salaries are dominant in early stage startups, and infrastructure costs becomes dominant as you scale (also probably a SaaS-centric oversimplification). You can get into trouble in the middle, where you have enough scale to be paying jaw dropping cloud bills, but you don't have the staff to move to a cheaper architecture and you may still need to focus on getting new features out to drive growth (or to attract investment).

In startups that chasm is generally filled with VC money paid to cloud vendors, but if you're bootstrapping or not looking to be a unicorn, you probably will want to drive down infrastructure costs much earlier.

Re: Was Rust Worth It?

#164

Post by AgentME »

HKH2 wrote: post #157
throwaway914 wrote: post #7

I feel like Rust finally broke the idea that programmers should be in complete control and completely conscious of everything the compiler is doing. It hasn't been that way in decades, compilers are freaking magic. But Rust undid a lot of that with borrowing. People became comfortable with the compiler knowing better than them. I just wish we could relax further: We should never be explicitly iterating forward over a…

> Give me rusty bash. Bash with types (especially floats), fewer edge cases, functions with explicit parameters, simple command line flags...

You're skipping the most needed improvement of all: fixing the issue where scripts with unquoted variables will seem to work until they contain a space. Almost every single bash script of more than a dozen lines I've seen outside of large open-source projects fails if a user puts a space in a file path, because the programmer didn't understand the insanity of variable quoting rules! I don't know of any programming language with a more common major footgun.

Re: Was Rust Worth It?

#165

Post by jowea »

swatcoder wrote: post #65
jrockway wrote: post #5

Earlier quoted context omitted.

URLs for packages makes a lot of sense. It works well in the land of Go. It also conveniently eliminates the need for the language to have a global packages database. Upload your package to example.com/your-thing and it's released! (You can, of course, still offer a cache and search engine if you want to.)

No, URL's don't make sense because your application shouldn't care where on the internet your dependency happened to be hosted when you integrated it. It's location has nothing to do with what it is. By the time you're going to production, your vetted and locked dependency should be living in your own cache/mirror/vendored-repo/whatever so that you know exactly what code you built your project around and know exactly…

Isn't that just delegating the problem? URL dependencies do not replace what crates.io does, and a modern language will still want something like it. You'd just end up with most every dependency being declared as crates.io/foo.

Re: Was Rust Worth It?

#166

Post by cmrdporcupine »

topspin wrote: post #160

"Want to use an async library? There’s a chance you can’t use it outside of a specific async runtime." I complained about this here[1]. I'm told "Tokio won, it's not a problem anymore." Wrong. It's still a problem and it's a killer. [1] https://news.ycombinator.com/item?id=37892655

Yeah those are terrible responses.

Tokio monoculture is a serious problem.

Re: Was Rust Worth It?

#167

Post by tialaramex »

tantalor wrote: post #19

> I started writing tests in Rust as I would in any other language but found that I was writing tests couldn’t fail. This is a common refrain in C++ testing: if it compiles then it's probably correct. > Rust has accounted for so many errors that many common test cases become irrelevant In practice, if you think this way I think it's a sign that you aren't testing the right things in those other languages. You should…

There is surely something wonderful about the kind of C++ programmer who figures that, since their unusable broken garbage compiled it's probably correct.

Remember unlike most languages you'd be familiar with C++ has IFNDR, which has been jokingly referred to as "False positives for the question: Is this a C++ program?". A conforming C++ compiler is forbidden from telling you in some† unknown number of cases that it suspects what you've written is nonsense, it just has to press on and output... something. Is it a working executable? Could be. Or maybe it's exactly like a working executable except it explodes catastrophically on Fridays. No way to know.

† The ISO standard does identify these cases, but they're so vague that it's hard to pin down everything which is covered. My guess is that all or most non-trivial C++ software is actually IFNDR these days. Just say No to the entire language.

Re: Was Rust Worth It?

#168

Post by MuffinFlavored »

topspin wrote: post #160

"Want to use an async library? There’s a chance you can’t use it outside of a specific async runtime." I complained about this here[1]. I'm told "Tokio won, it's not a problem anymore." Wrong. It's still a problem and it's a killer. [1] https://news.ycombinator.com/item?id=37892655

Can you help understand why somebody wouldn't use Tokio/why it didn't "win"?

Re: Was Rust Worth It?

#169

Post by [deleted] »

dilippkumar wrote: post #84

> After two decades of JavaScript and decent experience with Go, this is the most significant source of frustration and friction with Rust. It’s not an insurmountable problem, but you must always be ready to deal with the async monster when it rears its head. In other languages, async is almost invisible. I am a former C and C++ programmer who lived calling into pthread almost every week for a decade. I use async rus…

[deleted]

Re: Was Rust Worth It?

#170

Post by ants_everywhere »

taberiand wrote: post #152
swatcoder wrote: post #65

Earlier quoted context omitted.

No, URL's don't make sense because your application shouldn't care where on the internet your dependency happened to be hosted when you integrated it. It's location has nothing to do with what it is. By the time you're going to production, your vetted and locked dependency should be living in your own cache/mirror/vendored-repo/whatever so that you know exactly what code you built your project around and know exactly…

URLs are well structured and unique, with a sensible default - sourcing the file from the internet - and ubiquitous processes for easily mapping the URL to an alternative location. I.e., when you're going to run the production build, the URLs are mapped to fetch from the vetted cache and not the internet. I don't see any downsides to allowing them as a source, or making them the default approach

> and ubiquitous processes for easily mapping the URL to an alternative location.

This seems strange to me because the whole point of a Uniform Resource Locator is to specify where a resource can be located.

It's a bit like saying "My project depends on the binder on shelf 7 in Room 42, sixth binder from the left. Except when I go into production, then use...." Don't tell me what binder it's in, tell me what it is.

I can see a case made for URIs, which is basically what Java did.

Post reply on HN