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

Why Rust?

rerun.io

Post reply on HN
Print view View original

131–140 of 294 posts

Re: Why Rust?

#131

Post by horsawlarway »

traceroute66 wrote: post #96
Thaxll wrote: post #87

Earlier quoted context omitted.

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 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 applications 200kb is ridiculously small.

When was the last time you installed an application on Windows/Mac/Android/iOS that was under a single MB?

Yet you install (& run) applications ALL DAMN DAY on the web, without a thought or care.

Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb and load in less than a few seconds.

Ex: Outlook used to be a mail client you installed. The installer was several hundred MBs, and it took 10+ minutes to run. Now you point your browser at outlook.com and you get a nearly identical experience.

That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload.

Music player? It's a website now. JS.

See my point?

So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing.

Re: Why Rust?

#132

Post by masklinn »

Thaxll wrote: post #87
azangru wrote: 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

You have never actually looked at the history of javascript have you? Or at the current "best practices"?

Re: Why Rust?

#133

Post by api »

Thaxll wrote: post #87
azangru wrote: 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.

JS ecosystem front end builds can be complex and incredibly slow these days. It's rare to see a JS app that is just written in JS and shipped as-is without some kind of long "compile" pipeline with translation to support different browsers, minifiers, CSS compilation, and tons of other cruft.

I've definitely seen JS builds be slower than medium to large size Rust builds on the same machine, especially since JS builds often involve large steps that are not parallelized. Rust parallelizes builds pretty well until the very last optimization pass and linker stage.

Go builds are impressively fast, so if that's a big pain point for you I'd look at Go frontend stuff.

Re: Why Rust?

#134

Post by commitpizza »

As a developer who mainly writes front end apps with Javascript (but with experience in a lot of other languages), I started to learn Rust for an app I want to build.

The issue is that the app itself will not really be needing maximum performance and I much more concerned about the safety aspects Rust brings. But I guess the safety aspects would be the same with me using Python for example.

Why I want to learn Rust is because it could help me in the front end aspect and I think it's a language that has a bright future.

Am I crazy to spend the time to get effecient in Rust and write my app I want to write in Rust instead of Python? Is there any other benefits of using Rust that I don't see as a beginner? I am afraid that I'll just waste a bunch of time just because I want to learn Rust and think it's cool but ultimately it will slow me down to such an extent that my app never sees the light of day or that it increases general development time.

Thanks in advance for all potential responses

Re: Why Rust?

#135

Post by api »

cageface wrote: post #29

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…

ZeroTier is doing all its new stuff in Rust and rewriting our core network virtualization engine in Rust, and not crypto. We are hiring.

Re: Why Rust?

#136

Post by marcosdumay »

scratcheee wrote: post #41
anonymous_sorry wrote: post #18

Earlier quoted context omitted.

Reference for "much" slower? Surely depends on usage? The cost is also more predictable/amortised than classic garbage collection.

It's generally true to be fair, reference counting could be used for every garbage collected language (and be much simpler). The only reason they switched to more complex schemes is they're faster on average. Even smart schemes that try to remove unnecessary ref count changes will tend to underperform compared to a (well built) tracing GC. As for a reference, https://en.wikipedia.org/wiki/Tracing_garbage_collection#P…

It's not generally true. It's true for the case when the runtime keeps track of every little memory segment.

Re: Why Rust?

#137

Post by masklinn »

horsawlarway wrote: post #131
traceroute66 wrote: post #96

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…

> So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing.

That web application delivery is "fucking amazing" doesn't mean javascript is. Javascript very much is not.

What javascript is, is the only complete option until wasm is way more fleshed out than it currently is.

> Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb

With an entire browser and server farm to do that.

> and load in less than a few seconds.

Instead of instantaneously.

> That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload.

10% the functionality, 20% the performance, at twice the heft. Amazing.

> Music player? It's a website now. JS.

Your music library? Doesn't exist now.

Re: Why Rust?

#138

Post by api »

rvz wrote: post #50
sirwhinesalot wrote: post #37

Earlier quoted context omitted.

It's a bubble, 99/100 crypto companies are going to crash and burn, or already have. If you manage to land on the 1/100 that actually does something useful and survives, well, better odds than the lottery I suppose.

> It's a bubble, 99/100 crypto companies are going to crash and burn, or already have. I'm sure this is the 990th time that I have heard this. The fact is, it isn't going away and it seems even more crypto companies have taken interest in using Rust and that is good. Even some (crypto) companies are sponsoring the Rust Foundation as silver members. Nothing wrong with that. [0] [0] https://foundation.rust-lang.org/mem…

What are crypto companies doing that I should care about? Give me something I could go check out and use that is:

(1) Not speculation, gambling, or some variation thereof.

(2) Useful for something other than crypto itself.

(3) Actually works and can be used today.

(4) Continues to make sense even in a crypto bear market. (In other words: I will still buy milk even if the US dollar is falling because the point is the milk not the dollar. What in crypto is like that?)

Re: Why Rust?

#139

Post by emilern »

chanks wrote: post #130
emilern wrote: post #93

Earlier quoted context omitted.

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.

I'm very curious how well this is working for you in practice, since I've been thinking about what it would look like to share a single Rust UI implementation across a webapp and native apps.

So far so good!

Putting the UI in a canvas elements have some distinct drawbacks (https://github.com/emilk/egui/tree/master/crates/eframe#prob...) but for us it is definitely worth it. Having one unified codebase for our web app and native app, and having it all in Rust, is just amazing.

We're currently working on a 3D renderer based on wgpu (https://github.com/gfx-rs/wgpu) that we will likewise use for both web and desktop.

Re: Why Rust?

#140

Post by cillian64 »

coldpie wrote: post #119
cillian64 wrote: post #101

Earlier quoted context omitted.

From my experience in C there are two ways libraries deal with not being able to easily pull in their own dependencies. Some of them include their own reimplementations of lots of things (data structures, logging, error handling, date-times). Others decide to keep it simple and only implement a minimal set of functionality which limits their need for dependencies or reinventing the wheel. Cargo letting libraries easi…

I don't know that I have a better suggestion, but the lack of friction on adding new dependencies makes for really hairy dependency graphs. For example, I really loathed having to write this[1] when all I did was write a gstreamer plugin in Rust. I'm not even confident that I got it all the licensing right, and I surely didn't vet every single library in the graph nor will I vet every library during a future cargo-up…

In theory, if the complexity of libraries stayed the same then pretty much the only advantage of not having recursive dependencies is a simpler license statement, and cargo-license should make that easy to automate.

In terms of checking over the code, cargo dependencies should result in less duplication and so fewer lines of code for the same level of functionality, and having it split into crates doesn’t obviously make it harder to review and Cargo.lock means the dependencies won’t change unexpectedly.

I do agree that there is a question about whether easy access to pulling in dependencies means libraries are more inclined to bloat and unnecessary complexity. But not having cargo dependencies at all would seem like a very big hammer to solve that problem. I’d much prefer to grow an ecosystem of minimal/simple libraries which don’t try to do everything and which limit their dependencies.

Post reply on HN