Live data from Hacker News

Why Rust?

rerun.io

161–170 of 294 posts

Re: Why Rust?

#161
post #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.

How does egui interact with screen readers and other accessibility APIs?

Re: Why Rust?

#162
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.

I have a real-world codebase of considerable complexity in both BE & FE code where I work. Our Rust compile time, across all targets we build (which includes a lot of tooling that's not really "backend", but we compile all the Rust together, so…) is 7m47s. Our FE build time was ~20m (and is part of our CI's critical path).

Re: Why Rust?

#163
post #86

Earlier quoted context omitted.

Except that cryptomoney isn't adding insane amounts of value in any niche, outside of extortion and evading government controls.

Evading government controls sounds like a valuable attribute.

Yes and no, both. That really depends on what government and what control.

But anyway, the amount of value you can provide there is severely limited, as you can only at most undo the value your government is destroying. You can't ever get in a better situation than what you would get with a competent liberal-ish government and no cryptomoney.

That means some business can exist there, and a small amount of it can even be morally acceptable. But it is completely different from the internet boom.

Re: Why Rust?

#165

I saw a YT video about how safe Rust is. I want to give it a try but I do mainly web applications, where I use Spring Boot and front-end frameworks. From what I have read Rust is better for system level or regular applications (not web apps). Can modern web applications be built efficiently with Rust? And by efficiently I mean, is the ecosystem there (libraries and tools). I imagine the following would be needed.. 1)…

We use Actix for HTTP. Works fine. I don't use ORMs, I prefer sqlx, which gives me compile time checking of queries while still just writing plain old sql. I log via the tracing library to stdout, I let other services handle what's done at that point. I don't use DI frameworks, nor do I believe that they are good, I use dependency injection via construction, which works great.

I don't do any fancy configuration. I use `clap` to take in values and ideally I'll never do any config anywhere else in my program.

The AWS SDK from rusoto works well enough. AWS has a beta SDK out for Rust as well, seems good.

I haven't found any need for libraries like Guice, there's metrics, collections, and everything else I've needed in crates.io.

Re: Why Rust?

#166
post #161
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.

How does egui interact with screen readers and other accessibility APIs?

So-so. There is an experimental screen reader you can enable in the "Backend" panel of egui.rs.

There is ongoing work to integrate AccessKit (https://github.com/AccessKit/accesskit) which will improve things significantly.

Re: Why Rust?

#167

I saw a YT video about how safe Rust is. I want to give it a try but I do mainly web applications, where I use Spring Boot and front-end frameworks. From what I have read Rust is better for system level or regular applications (not web apps). Can modern web applications be built efficiently with Rust? And by efficiently I mean, is the ecosystem there (libraries and tools). I imagine the following would be needed.. 1)…

We use Actix for HTTP. Works fine. I don't use ORMs, I prefer sqlx, which gives me compile time checking of queries while still just writing plain old sql. I log via the tracing library to stdout, I let other services handle what's done at that point. I don't use DI frameworks, nor do I believe that they are good, I use dependency injection via construction, which works great. I don't do any fancy configuration. I us…

Thanks for your reply. Can you disclose what web application this is you work on?

Re: Why Rust?

#168

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…

> See my point?

No.

Because your point only works if you make (at least) two prior assumptions which are not always true.

Number one you assume everyone has high-speed broadband and "unlimited" 5G on mobile. This might well be the case in many parts of the Western world. But I can point you to a number of rural areas in the Western world and beyond that, in Africa and Asia where this assumption falls flat.

Number two, given most developers use JS to outsource the processing duties, you assume everyone has a half-decent computer. Many people use cheap laptops with lousy Celeron processors and a minuscule amount of RAM, likely also with an ancient browser that has not been updated for ages. Their experience of a browser-app will likely be very different to the cool-kid developer sitting on his bean-bag in a fancy office coding on a spec'd out beast of a machine.

Re: Why Rust?

#169

How does Rust do at random number generation? Is there (for example) a crate for seeding random number generators?

I'm not sure if I understand your wording: "a crate for seeding random number generators"? Do you mean, "is there a RNG that you can seed in Rust"?

There's a `rand` crate[0] which I believe was written by folks in the Rust project, though it's not part of std. You can seed the RNG[1].

[0] https://crates.io/crates/rand, https://github.com/rust-random/rand

[1] https://docs.rs/rand/latest/rand/rngs/struct.StdRng.html#met...

Re: Why Rust?

#170
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.

> 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 them apart). Put the two things together, and enum Coordinates{TwoD(f32, f32), ThreeD(f32, f32, f32)} is a set of values with cardinality #f32^2 + #f32^3. You can build types corresponding to arbitrary polynomials, hence the name.

"Union type" usually just means the same as "sum type", though it can also be used to mean C-style unions specifically.

(There's also functions as exponential types, with A -> B having cardinality #B^#A, but you're neck deep in type wankery when you start talking about those :o)

Almost every language supports product types in some way, either implicitly or explicitly, and nobody really bothers talking about those in isolation. It's when you add sum types to the mix that people start talking about ADTs, and it's when you add pattern matching that the whole thing comes into its own and you can just express functions as "things with this shape become things with that shape".

Post reply on HN