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

211–220 of 294 posts

Re: Why Rust?

#211

Post by Traubenfuchs »

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…

> an avalanche of javascript errors in the browser console

Dear god. And then you can't even visually tell if you are at the main, "Team" or "Blog" page from the menu bar.

This says one thing very clearly: "This website was not made with love." -which says NOTHING about the product they are offering.

Re: Why Rust?

#212

Post by cyber1 »

Most benefits of Rust are true, except in some cases it does not allow you to compile an absolutely valid and safe program like here https://github.com/rust-lang/rust/issues/47680 - unfortunately you don't have freedom of code design decisions! I see some possible problems with refactoring, extending logic and functionality, and lots of issues with async code design and readability.

For me, Rust looks like a temporary step before the next language.

Re: Why Rust?

#214

Post by 5e92cb50239222b »

maeln wrote: post #124
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.

> People doing frontend dev don't want to bother with slow compile time Honestly, with my previous experience as a frontend web, compile time for frontend is starting to become as bad as a standard compiled language. When you start to have a whole framework, many (many!) dependencies (you know, the kind that make just deleting the node_modules directory slow) and webpack with some plugins for CSS, es-lint and all tha…

It's pretty fast with modern tooling. Try vite or swc if you have the time and inclination. vite builds one of my large $DAYJOB projects in ~45 seconds (which is insane compared to how webpack performed).

If you don't need vite's extensibility, you can go with 'pure' esbuild and slim down transpilation + minification + bundling to only a few seconds.

https://vitejs.dev

https://github.com/swc-project/swc

https://github.com/evanw/esbuild

Re: Why Rust?

#215

Post by bluejekyll »

torstenvl wrote: post #109
bluejekyll wrote: post #103

Earlier quoted context omitted.

> I see similar aproaches with Rust code making use of unsafe when there are safe alternatives. Really? I review and read a bunch of Rust code on a weekly basis from projects I might use in various contexts. I hardly ever see unsafe used, except in contexts where it is necessary like FFI. I am pretty sure that your comment is provably false, if someone wanted to run a report on crates.io. Oh, looks like someone did,…

That isn't a trend line, the crates are sorted by percentage of unsafe code. From your link: To get this plot I ordered all crates by unsafe code % and then plotted it, so each point on the graph is unsafe code % for a single crate. The link is still some evidence in support of your position, given that it drops off close to the left edge, i.e., a small number of crates have a large amount of unsafe code. But it isn'…

Yes, you’re correct trend is the wrong term. Was that an aggressive statement? It wasn’t intended to be.

I find the statements around unsafe in Rust to generally be incorrect though, from what I can tell, it’s only ever used in quite narrow cases and not generally across the vast majority of Rust software.

Re: Why Rust?

#216

Post by mwcampbell »

emilern wrote: post #166
panzi wrote: post #161

Earlier quoted context omitted.

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.

Anyone who's interested in the AccessKit integration can play with my work-in-progress branch: https://github.com/mwcampbell/egui/tree/accesskit

It's currently Windows-only, and I'm working on the big missing feature, which is text editing support.

Re: Why Rust?

#218

Post by UltraViolence »

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…

They may be static pages, but usually you need a CMS to manage those static pages and their content.

So it containing Javascript to fetch the content isn't all that far fetched.

Re: Why Rust?

#219

Post by UltraViolence »

losvedir wrote: post #10

> Rust's enums and exhaustive match statement are just amazing, and now that I'm using them daily I can barely imagine how I could live without them for so long. I feel this! I absolutely love rust's fancy enums - i.e. not just a set of constants, but where each variant can be a full fledged type of its own, and how you have to handle every case whenever you're matching on it. It dovetails absolutely wonderfully with…

You have to understand where enums originally came from. Initially they were simply #defines in the pre-processor to make code easier to read. Instead of having "magic numbers" all over your code you'd have something that kinda made sense.

Then they became part of the C language when they evolved into enums but still remained compatible with int's (you could cast an enum to an int).

In that mindset it never occurred to anyone that an enum could have an "internal" value too.

Re: Why Rust?

#220

Post by UltraViolence »

bobajeff wrote: post #36

As someone who's not the biggest fan of Rust because of its complexity. There is a big reason to use it today. If you need to use something that has safety guarantees where it's possible to achieve acceptable performance in certain classes of programs where languages like golang, nim or crystal have trouble achieving then I just don't see any other options out there certainly not one with as many libraries available…

IMHO the biggest reason for Rust is that developers NEVER get enough time to write perfect code. All this takes time and management usually doesn't grant you that allowance.

In a perfect world where developers could tinker with the code until it's perfect we wouldn't need Rust. This is not that world.

Post reply on HN