Live data from Hacker News

Why Rust?

rerun.io

201–210 of 294 posts

Re: Why Rust?

#201

Earlier quoted context omitted.

> There is a reason why JS was invented. I disagree. As I see it, JS was invented as a browser utility, as the name implies "script", i.e same as shell script languages such as BASH, for doing small amounts of interactive stuff. What JS has morphed into is a Jeckyll & Hyde monstrosity. Frontend devs now routinely dump 200kb+ of junk down the pipe at people's browsers because its somehow "better" to dump the processin…

I think you're failing to address the elephant in the room: The browser is simply the single best application distribution method humanity has ever created. Full stop. There are literally no other tools that give anywhere close to the same benefits. So 200kb of scripts might seem "HUGE!" to someone who's thinking about the web as a tool for distributing static information (blog distribution). But in the context of ap…

For blogs, sure, JavaScript is "fast enough".

But in the context of applications, JavaScript is slow as dog shit.

It takes "seconds" to open my spreadsheet? That is an absolutely deplorable regression.

Personally, I'm fine with 200KB initial downloads, sure that's great and I don't mind repeating them. (But, also don't care about 50MB or even 500MB downloads that I only do once.)

But for the browser to really become the "single best application distribution method humanity has ever created" it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts. Not just the putrid UX, but we now understand that slow, inefficient code also cooks the planet and destroys various life forms.

I work at a company that uses Google Sheets. So yeah, it does often take seconds to open a document. And I've spent way more time waiting for those sheets to load over the past 5 years than I have waiting for software installers.

And many web apps bog down and lag behind even just typing, because they are doing some (trivial) computation on every keystroke. It doesn't have to be that way, but it often is... because JavaScript.

I'm also bullish on the browser's future as an app-delivery channel — but that is only because I think doing it without JavaScript will become easy, and thus common.

JavaScript is relevant because of the browser, not the other way around.

Re: Why Rust?

#202
post #153

Earlier quoted context omitted.

Are you propagating errors with the question marks here?

Good one! is_hiring()?.apply()?.code_rust()? Error handling is really nice in rust Edit: Just realized that the first question mark in my original question was a mistake

No post body was provided.

Re: Why Rust?

#203
post #11

Earlier quoted context omitted.

Atomic reference counting does incur a slowdown.

Which should be incredibly negligible unless you're counting literal millions of objects. Even then, I'm suspecting that refcounting will never be in the top spots of things that slow you down.

What I'm saying is that bumping atomic references inside a hot loop will be detrimental for performance, and since it invalidates a cache line and this can flush caches for lots of cores. It also shuts down ILP.

Re: Why Rust?

#204
post #170

Earlier quoted context omitted.

I'll bite - I just googled this, and am having a struggle understanding. Is an Algebraic Data Type (ADT) in rust an enum or tuple? I make heavy use of enums (along with structs) as my program foundations. Am I using ADTs? The third type the query shows are unions, which I'm not familiar with.

> Is an Algebraic Data Type (ADT) in rust an enum or tuple? It's the combination of both. Tuples are Product Types . If you treat types as sets of values, then the type (A,B) is the cartesian product of types A and B. For all practical purposes, structs are just syntactic sugar for tuples. Enums are Sum Types . The values of Result are fundamentally just all the values of T plus the values of E (with a tag to tell th…

Union types and sum types are different things. Given a type 𝐴:

𝐴 + 𝐴 ≠ 𝐴

𝐴 ∪ 𝐴 = 𝐴

Re: Why Rust?

#205
post #30

Earlier quoted context omitted.

ADTs is last missing piece that would make me fully content with Go :)

aren't interfaces technically an abstract data type? EDIT: ah, it's algebraic data types, my bad, apologies.

Interfaces are not closed, which is considered a big advantage of sum types (though it can also be a disadvantage).

Re: Why Rust?

#207
I just bootstrapped Rustc 1.58 using only GCC and mrustc sources on an 8 core 16 thread machine with 32 GB memory and lot's of disk space. It took 20 hours.

If you think Rust is bloated, I agree.

Re: Why Rust?

#208

> There is of course some legitimate worry that the Rust crate ecosystem could devolve into the crazy left-pad world of npm, and it is something to be wary about, but so far the Rust crates keep an overall high quality. Note that the particular case of left-pad cannot happen with crates.io/cargo, because once published, you cannot unpublish a crate. You can 'yank' it, in which case it will not be resolved by Cargo.to…

What is the alternative to not having a crate ecosystem? Everyone roll their own smallvec implementations? How is that any better?

You can decrease the attack surface by having a good standard library, so packages don't have hundreds of microdependencies like `rand`.

Re: Why Rust?

#209
post #84
post #75

Honestly, this kind of breathless adulation is off-putting to me. > If I'm honest, the main reason is because I love Rust. That's nice if it works for you, but I'm looking to build and maintain software well and efficiently. I don't want a programming language I can love I want a tool. (BTW, old and tired but true: don't love things that can't love you back.)

But I love good food.

I have to admit, food is a good exception to the rule.

Re: Why Rust?

#210

Earlier quoted context omitted.

Emil has been working in Rust for eight years. Hardly a honeymoon phase. As for your accusation of lying: I cannot imagine where you’ve pulled that from. Emil’s description of unchecked exceptions as invisible errors insofar as you can’t see where errors might occur from the source code alone is objectively an accurate and reasonable description.

Except Emil is talking about "Java exceptions", not "Java runtime exceptions". Because Java's checked exceptions have the exact same good qualities that Rust's question mark operator offers.

Agreed, checked exceptions surface potential errors to the caller. In that regard Java fares better. However, handling exceptions still require a separate catch clause rather than being part of the normal flow. Furthermore, it is nigh impossible to rely on checked exceptions alone, most Java code may throw RuntimeExceptions such as NullPointerException or ArrayIndexOutOfBoundsException and there is no way to know it by just looking at the calling code.
Post reply on HN