Live data from Hacker News

Why Rust?

rerun.io

91–100 of 294 posts

Re: Why Rust?

#91
post #12

> Rust's enums and exhaustive match statement are just amazing ADTs + pattern matching are the killer feature set that makes the more popular functional languages so damn pleasant to use, and they're starting to spread to more and more languages. I suspect that, 50 years from now, we'll look back and see them as the key paradigm shift of this era.

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.

Re: Why Rust?

#92
> We've had fast languages like C and C++, and then we've had safe languages like Lisp, Java, and Python. The safe languages were all slower.

Them's fightin' words. SBCL (Lisp) totally screams with speed as far as I've been able to tell.

Re: Why Rust?

#93
post #70

> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring. > I can write web apps in another language than JavaScript > I can write web apps that are fast Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.j…

Hi, author here!

We are building the frontend of our _application_ in Rust and rendering it to a canvas using egui.rs. For the web site we are using more "traditional" tech, as you've noticed.

I am not a big fan of the complexity of modern web sites (including our own), which is exactly why I created egui. However, it is targeted at web apps, not web sites.

Re: Why Rust?

#94

I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years. C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through. Rust code, on the other hand, often doesn't l…

> Too bad most of the Rust jobs right now seem to be in crypto. It is not really surprising that the crypto bros jumped onto the bandwagon, the tech got hyped just around the same time. Just, one of them correctly. :) It's just a shame that other companies don't seem to follow suit. Except some, who always ask for "Senior Rust Developer" which I'd guess is still a limited supply market. :D

> Except some, who always ask for "Senior Rust Developer" which I'd guess is still a limited supply market.

I've seen a role advertised for 750k/month. It makes sens: those who move fastest get to milk the crypto bubble and make out like bandits. Oh wait, exactly like bandits.

Re: Why Rust?

#95
post #87
post #70

> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring. > I can write web apps in another language than JavaScript > I can write web apps that are fast Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.j…

Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.

Obviously not fast enough for Google since they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java.

Re: Why Rust?

#96
post #87
post #70

> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring. > I can write web apps in another language than JavaScript > I can write web apps that are fast Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.j…

Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.

> 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 processing/rendering on the user's desktop instead of server side.

And then there's the monstrosity of server-side JS. I think few people can argue that JS was ever supposed to be server-side. Things like Node are basically square-pegging JS into that round hole.

Re: Why Rust?

#97
post #60
post #22

> Floating point behavior Since 1.62 there have been a native way of doing it with the `total_cmp` method [0] on floating points which can be used to at least sort it quite easily, but cannot really use it in collections like BTreeMap. [0]: https://doc.rust-lang.org/std/primitive.f64.html#method.tota...

> but cannot really use it in collections like BTreeMap Given the nature of floats, is this really a problem? Worst case scenario the floats can be represented differently, if one really needs to use them as keys.

Yeah it was mostly to give a example of where a wrapped type would be better than `total_cmp`. E.g. something that needs the value to implement Ord.

Re: Why Rust?

#98
post #87
post #70

> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring. > I can write web apps in another language than JavaScript > I can write web apps that are fast Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.j…

Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.

> There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time

Lol. That's not why JS was invented, at all.

JS was invented to provide basic interactivity to static html pages. By accidents of history it snowballed in the current monstrosity.

Re: Why Rust?

#99
post #87
post #70

> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring. > I can write web apps in another language than JavaScript > I can write web apps that are fast Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.j…

Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.

In Rusts defense, I can't think of a situation where you would need `OsString` in a frontend, and I don't think you will need `CString` either since strings are passed into webassembly by address + length (so exactly what Rust expects, no null-terminated nonsense). So you would just use the one default string type (`String` + `&str`).

Re: Why Rust?

#100
post #87
post #70

> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring. > I can write web apps in another language than JavaScript > I can write web apps that are fast Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.j…

Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.

Why wouldn't it? Saying that it will never seems very definitive. It's like these famous quotes that "we will never need more than 4kb of memory" or similar. Saying that something will never change is just a lack of imagination of the future.

There are big pushes behind wasm and Rust is leading the way here in a big way. I think you underestimate people and their will not to run javascript. Rust and WASM in particular will make it so that you can bring whatever language you want to the front end.

I believe that while it's very impractical now, wasm will slowly take over and in the future basically no one will use javascript except for basic things and most sites will use wasm for front end logic.

Why? Because it just makes sense for many reasons. You can use whatever language you want both on the server side and in the browser, you can achieve near native speeds and we're already sending big minified javascript blobs anyway so we may as well just send a binary instead. yes it's very hard to make a SPA with Rust today but it is possible and the tooling will become better over time and especially with other languages joining in.

To me it's clear that using javascript on the front end will become slowly irrelevant as more and more devs ship a binary blob. Right now, we need javascript as a glue but I think that will change as well with time.

Post reply on HN