Why Rust? • Hacker News Board

Re: Why Rust?

#291

Post by dgan » Thu, Oct 20, 2022, 9:56 AM UTC

FromTheSteppe wrote: post #285

dgan wrote: post #117

I don't understand why everyone seems to ignore Ada? Granted I am completely new to it, but from what I see it is years ahead of Rust in terms of safety (it can prove correctness!! Rust is only heading into that direction). Yes syntax is verbose, but I dare to believe there must be another blocker than just syntax?

Because Ada tooling is bad. Try getting gnat on macOS aarch64 and compile emacs' ada mode extension. You'd never touch anything Ada again.

It took me less than a week to understand the main problem is tooling and licensing :)

Re: Why Rust?

#292

Post by coldpie » Thu, Oct 20, 2022, 12:57 PM UTC

dureuill wrote: post #245

coldpie wrote: post #119

Earlier quoted context omitted.

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 case you don't know and it would be useful to you, there's tooling out there to generate license files from the Cargo.toml. cargo lichking is an example, and I think cargo deny has similar functionality?

Actually writing the license wasn't the bad part, it was that Cargo more-or-less-silently pulled in a couple dozen different projects, which means a couple dozen different projects that a responsible software distributor "should" be vetting.

(I did use some tool like you mention, but my recollection is they were pretty crummy. IIRC they just did a dumb full dependency graph, so included stuff required only for platforms that I wasn't deploying for; also I think the output format was ludicrously verbose so I had to manually trim it down. This was a couple years ago, perhaps the tools have improved since then.)

Re: Why Rust?

#293

Post by 5e92cb50239222b » Thu, Oct 20, 2022, 6:34 PM UTC

toyg wrote: post #284

5e92cb50239222b wrote: post #214

Earlier quoted context omitted.

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://githu…

When JS was born, "building" was F5 in a browser. 45 seconds is an eternity in comparison.

You also couldn't use JS of that time to build anything remotely like modern SPAs. Unlike some Silicon Valley unicorns, we're using SPAs only where they fit, to replace legacy desktop applications. (It's boring intranet stuff, but they make a lot of sense there.) I was a skeptic initially, but it grew on me.

Re: Why Rust?

#294

Post by ttfkam » Sun, Oct 23, 2022, 7:32 PM UTC

thesuperbigfrog wrote: post #122

ttfkam wrote: post #95

Earlier quoted context omitted.

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.

>> 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. Go was created to overcome complexity issues and compile times of C++ (not Java): https://commandcenter.blogspot.com/2012/06/less-is-exponenti... https://go.dev/talks/2015/gophercon-goevolution.slide#4

I misspoke (miswrote?). You are correct, it was created to address the issues Google had with C++ and—crucially—other internally supported languages like Java and Python could not adequately fill C++'s role.

If Java could have filled this role in both compile time and memory efficiency, Go in all likelihood would never have been created.

But yes, Go beats Java in compile-time speed as well.