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

101–110 of 294 posts

Re: Why Rust?

#101

Post by cillian64 »

kajaktum wrote: post #82
richdodd wrote: post #74

> There is of course some legitimate worry that the Rust crate ecosystem could devolve into the crazy left-pad world of npm, and it is something to be wary about, but so far the Rust crates keep an overall high quality. Note that the particular case of left-pad cannot happen with crates.io/cargo, because once published, you cannot unpublish a crate. You can 'yank' it, in which case it will not be resolved by Cargo.to…

What is the alternative to not having a crate ecosystem? Everyone roll their own smallvec implementations? How is that any better?

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 easily have their own dependencies means that many Rust libraries are very rich and fully featured. This has plenty of advantages, but the big dependency tree can be a problem in some circumstances. Crate features can sometimes help but usually not much in my experience.

I’ve seen libraries appearing in Rust which are specifically very simple and minimise dependencies (ureq is an example I like). This gives the developer the choice whether they want libraries which just do a small basic job or whether they are okay with including lots of dependencies in exchange for rich functionality. There’s a risk of segmenting the ecosystem (see also async/tokio) but it seems to be working pretty well to me.

Re: Why Rust?

#102

Post by emilern »

richdodd wrote: post #74

> There is of course some legitimate worry that the Rust crate ecosystem could devolve into the crazy left-pad world of npm, and it is something to be wary about, but so far the Rust crates keep an overall high quality. Note that the particular case of left-pad cannot happen with crates.io/cargo, because once published, you cannot unpublish a crate. You can 'yank' it, in which case it will not be resolved by Cargo.to…

Hi, author here

Good point about the yanking. But yes, there are multiple other problems such as typosquatting and adding malicious code to a patch release. `cargo-crev` and `cargo-vet` are both interesting tools that I'm keeping my eye on.

Re: Why Rust?

#103

Post by bluejekyll »

pjmlp wrote: post #33
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…

> 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. I wonder why, doing Windows programming with OWL in 1993 was quite delightful, or Mac with AppToolbox/PowerPlant,... Yes there is always C stuff coming throught the cracks, but I see similar aproaches with Rust cod…

> 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, and it trends to 0: https://www.reddit.com/r/rust/comments/g0wu9b/percentage_of_...

Re: Why Rust?

#104

Post by traceroute66 »

ttfkam wrote: post #95
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.

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.

> they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java.

And then ironically they then use a complex and runtime-heavy Java-based CI/CD to manage the compilation of their Go codebase.

Go is great though, best bit is how its so useable for web-stuff out of the box. Unlike Rust where you have to spend half your life either re-inventing the wheel or choosing which of hundreds of crates you want to use to do stuff that should be part of stdlib.

Re: Why Rust?

#105

Post by fuckstick »

ttfkam wrote: post #95
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.

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.

Of all the criticisms I’ve heard hurled at Java, compile time isn’t one of them. Have you actually used any of these things you comment on?

Re: Why Rust?

#107

Post by selfmodruntime »

eptcyka wrote: post #11
Fiahil wrote: post #4

Earlier quoted context omitted.

> dynamic lifetimes What do you mean ? If you refer to heap allocations, then you can use Box, Arc, Rc. They are not a "garbage collector" nor do they incur performance hits other than a regular heap allocation.

Atomic reference counting does incur a slowdown.

Which should be incredibly negligible unless you're counting literal millions of objects. Even then, I'm suspecting that refcounting will never be in the top spots of things that slow you down.

Re: Why Rust?

#108

Post by selfmodruntime »

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…

What are the major points concerning complexity you have encountered?

Re: Why Rust?

#109

Post by torstenvl »

bluejekyll wrote: post #103
pjmlp wrote: post #33

Earlier quoted context omitted.

> 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. I wonder why, doing Windows programming with OWL in 1993 was quite delightful, or Mac with AppToolbox/PowerPlant,... Yes there is always C stuff coming throught the cracks, but I see similar aproaches with Rust cod…

> 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't nearly the smackdown of GP's position you must think it to be for you to be so aggressive toward them.

Re: Why Rust?

#110

Post by cageface »

pjmlp wrote: post #33
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…

> 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. I wonder why, doing Windows programming with OWL in 1993 was quite delightful, or Mac with AppToolbox/PowerPlant,... Yes there is always C stuff coming throught the cracks, but I see similar aproaches with Rust cod…

Yeah everything was perfect back in my day and there's nothing new under the sun. You kids get off my lawn.

I've been coding C/C++ since 1995. I'll take Rust any day, thanks.

Post reply on HN