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

251–260 of 294 posts

Re: Why Rust?

#251

Post by 3836293648 »

pie_flavor wrote: post #244
cyber1 wrote: post #212

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 temporar…

You have successfully linked to the only meaningfully loud bug in the borrow checker; declaring that as proof that Rust is a temporary step does not seem like the most cool-headed of evaluations, especially as it will be fixed by a new borrow checker in active development. These assertions are always made, and always alongside information suggesting the speaker has not actually spent very much time using Rust.

Eh, it might be the only meaningful issue with the borrow checker, but the language itself has more issues than just that. I adore rust and have done for years, but I also see it as a stepping stone language and worry about it gaining too much adoption

Re: Why Rust?

#252

Post by hsn915 »

flohofwoe wrote: post #90
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.

Typescript and React project build times are easily in the same ballpark as Rust or C++ for similar code base sizes though, yet they are used in the frontend 'at scale' ;)

Yes but you can use esbuild to make it fast. My projects take less than a second.

Re: Why Rust?

#253

Post by marcosdumay »

Keyframe wrote: post #185
marcosdumay wrote: post #155

Earlier quoted context omitted.

C++ was C with a better interface for GUI widgets and generic templates. There was a lot of hype about OOP too, but I am not sure it was ever adopted because of it.

C++ was C with a better interface for GUI widgets and generic templates. That came a lot later in its life, like mid to late 90's.

Good point. I am not aware of how software was developed at the late 80s and early 90s...

But was C++ widely adopted at that time? I remember C++ compilers being a huge pain by the middle 90s. I can't imagine everybody using them earlier. (But then, it wouldn't be the first time everybody just decides to do something I can't imagine.)

Re: Why Rust?

#255

Post by bern4444 »

emilern wrote: post #93
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…

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.

Doesn’t dart/flutter do this? Render everything to a canvas.

It is difficult to believe this will be the future of the web.

I don’t think websites should take this approach. Seems like a bad idea

Re: Why Rust?

#256

Post by api »

RestlessMind wrote: post #226
api wrote: post #138

Earlier quoted context omitted.

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…

https://news.ycombinator.com/item?id=32406095 I prepared that post since the question you posed comes up every week here, if not more frequently.

That’s cryptocurrency in its original use case: virtual money.

This was all technically possible in 2009. What I was getting at was… what’s new? Billions and billions have been poured into all kinds of app development and R&D in this space and all we have is still what we had when Bitcoin launched.

What are all these people in crypto building? Where is it? Where can I use it?

Imagine if 25 years after the dot com era after hundreds of billions had been spent we still just had e-mail, static html4, and text chat protocols over dialup modem.

Re: Why Rust?

#257

Post by Const-me »

scratcheee wrote: post #34
moonchild wrote: post #13

Earlier quoted context omitted.

Reference counting is much slower than 'garbage collection'.

Technically yes, but if you only use it when you need it, it's often not a performance concideration. And for systems programming, the often overlooked truth is that people care far less about perfect performance than they do about control - ref counting doesn't give up control to a mysterious oracle running in the background which may or may not wreck your performance in hard to predict ways, it just pays a known co…

> why can't we have an optional modern garbage collector built into a systems language?

It's possible in C#. Some language and runtime features like lambdas insist on using the GC, but with some care they can be avoided. The usability becomes worse without these features, but IMO that's not a dramatic downgrade.

Many pieces of the standard library in modern .NET don't require managed heap. Instead, they operate on stuff like Span which can be backed by anything: unmanaged heap, native stack, or even the memory mapped to user space by a Linux device driver (I did it with DRM, V4L2 and ALSA devices).

Re: Why Rust?

#258

Post by andrewflnr »

hota_mazi wrote: post #176
pdpi wrote: post #16

Earlier quoted context omitted.

Scala, Kotlin, Haxe, Swift, and several others. The search term you want is "Algebraic Data Types" Erlang has the superpowered version of this - binary pattern matching, that lets you pattern match on a bitstream directly.

Erlang doesn't have enums.

I almost said the same thing, but a tuple starting with an atom is basically the dynamically typed version of an enum. :) You can safely think of ADTs as sugar and typing rules for such tuples, though I believe you do need dependent types to come at it from that direction...

Re: Why Rust?

#259

Post by quuuu »

One issue with egui and shoving the whole page into a canvas element is accessibility -- having just a canvas element is a screen reader's worst nightmare

Re: Why Rust?

#260

Post by Gigachad »

rvz wrote: post #31
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…

> Too bad most of the Rust jobs right now seem to be in crypto. What is the problem with that?

Very scummy companies. They often try to pull tricks like paying your wage in mostly their own coin which they plan to rug pull before you are able to cash it out.
Post reply on HN