Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 2024 the Year of Everywhere?

smallcultfollowing.com

Post reply on HN
Print view View original

101–110 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#101

Post by aussiesnack »

kibwen wrote: post #91
aussiesnack wrote: post #69

Earlier quoted context omitted.

One example - clap, which is by far the most commonly recommended cli args parsing library. Plain uses of the derive api are simple enough, but I found it a huge time suck to figure out how to do anything remotely different from the docs' examples. On my first 'real' Rust project, it took nearly half my time just figuring out how to deal with cli args. In retrospect I probably should have either used the Builder api…

That's fair, Clap is an 800 pound gorilla of library that is trying to be heavy-duty and production-grade. But if you're just learning Rust and want to crank out a CLI for fun or education then I'd say that Clap is overkill and a distraction from learning the language itself. There are dramatically simpler libraries out there for argument parsing, e.g. https://crates.io/crates/lexopt . Heck, if I was just starting ou…

That was but one example of what I face at every single turn with Rust though. Complexity (not conceptual difficulty) seems to be the general culturally accepted norm. I truly don't rule out that this reasonable given Rust's domain of use. But there is a general reluctance from Rust advocates to accept that it's complex, and that this complexity makes it hard to use.

I do find the intense advocacy thing singularly odd with Rust. It's not like developers have to be convinced a thing is easy for them to use it. I'm still learning Rust (for reasons). But I don't feel the need to submit to social pressure from Rust advocates to feign ease.

Re: Rust 2024 the Year of Everywhere?

#102

Post by chrismsimpson »

nu11ptr wrote: post #66
andrewstuart wrote: post #12

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…

This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard an…

You’re holding it wrong

Re: Rust 2024 the Year of Everywhere?

#103

Post by tupshin »

jherico wrote: post #88

Quoted post unavailable.

Your comment has nothing to do with the blog post, which is about when rust features can be used (in combination with each other).

> Up until now, Rust has had a lot of nice features, but they only work sometimes. By the time 2024 rolls around, they’re going to work everywhere that you want to use them, and I think that’s going to make a big difference in how Rust feels.

Re: Rust 2024 the Year of Everywhere?

#104

Post by mikepurvis »

resonious wrote: post #44
jerf wrote: post #31

Earlier quoted context omitted.

"Is it possible to create a truly safe language without the dizzying complexity?" Yes! The good news is, they even already exist. There's even at least two variants of them: Pure immutable values (Haskell, Erlang) and languages that aren't pure functional but involve lots of little execution units that can't send mutable references between the units (Elixir, Pony) which when used even slightly properly makes unaccoun…

Aren't Haskell and Erlang both GC? I don't think anyone is touting Rust as newly immutable. The only differentiator (to my understanding) is Rust's safety without GC .

I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do.

But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.

Re: Rust 2024 the Year of Everywhere?

#105

Post by verdagon »

nu11ptr wrote: post #66
andrewstuart wrote: post #12

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…

This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard an…

In my experience learning Rust (and in watching others learn Rust) that first "aha!" moment is actually rather misleading.

That moment comes when one learns how to technically accomplish any task in Rust. One knows the minimum set of tools needed to refactor enough to work around the borrow checker's limitations. Learning what the borrow checker prefers becomes second nature and, as you say, becomes natural.

However, the journey isn't over there. One still has to learn the costs they paid to fit their design into what the borrow checker prefers. For some situations, the cost is low (CLI tools, data transformation, numeric analysis, etc). For other situations, the cost can be alarmingly high: one learns that the borrow checker is surprisingly anti-abstraction, causes brittle APIs, and can sometimes introduce artificial complexity compared to the optimal solution in other languages. One sees this a lot in programs with unavoidable inherent state. There are also sometimes problems working with teams, because the borrow checker likes to cause refactors with very wide blast radii that conflict with others.

Of course, this varies wildly person-to-person, according to the prevalent use of unsafe, Rc, etc.

Understanding how to work within the borrow checker isn't enough. The real challenge comes in figuring out when to work within it, and when to work outside it, in my opinion.

Re: Rust 2024 the Year of Everywhere?

#106

Post by woodruffw »

ilovecaching wrote: post #98
woodruffw wrote: post #48

Earlier quoted context omitted.

I agree that Rust is a large language, but I think you're overstating the complexity: it's been my experience that you don't need to know all (or even most) of the "clever" stuff to write large, performant Rust programs. It's generally true that you can spin engineers up quickly on C, because it looks like a simple language. But that's because C translates static program properties into dynamic ones, and expects engi…

I've heard this argument many times from Rust enthusiasts, most of whom do not work in C, C++, or even write system level software. Of the kernels that I have worked on, the Linux kernel core is very high quality C (even if many of the drivers are not), and other large parts of the stack like grub and systemd are also written in C and yet the sky isn't falling for users around the globe (and on other planets).

I can't speak for that group. I've been doing systems programming in C for about a decade now, and C++ for about half a decade; that includes both kernelspace programming and compiler development.

I'm not claiming that the Linux kernel core isn't high quality (or is, for that matter). I'm claiming that the kernel maintainers increasingly have to resort to all kinds of extensions and tricks to keep optimizing compilers from simply deleting their code, because nothing about C's semantics reflect the "bare metal."

Re: Rust 2024 the Year of Everywhere?

#107

Post by verdagon »

andrewstuart wrote: post #12

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…

Good news! Complexity isn't a baseline requirement: it's possible to make a language that has the basic patterns and benefits of an average Rust program. It's what we're doing in Vale [0].

It turns out, they key is to move some checks to run-time [1] to reduce complexity, move other checks instead to compile-time [2] where it doesn't increase complexity, and then make the borrow checker "opt-in" instead of forcing it to be used everywhere [3].

[0] https://vale.dev/

[1] https://verdagon.dev/blog/generational-references

[2] https://verdagon.dev/blog/higher-raii-7drl

[3] https://verdagon.dev/blog/zero-cost-refs-regions

Re: Rust 2024 the Year of Everywhere?

#108

Post by diffxx »

woodruffw wrote: post #48
ilovecaching wrote: post #9

Earlier quoted context omitted.

I have primarily worked on kernels written in C during my career, but I read through the official Rust book and wrote a small microkernel using Rust and my opinion is that Rust is already everything I hate about C++. It's already a huge language with a large upfront learning curve and there's no hope of mastering it as it's already grown so large that it could never fit in one person's head. Instead of focusing on so…

I agree that Rust is a large language, but I think you're overstating the complexity: it's been my experience that you don't need to know all (or even most) of the "clever" stuff to write large, performant Rust programs. It's generally true that you can spin engineers up quickly on C, because it looks like a simple language. But that's because C translates static program properties into dynamic ones, and expects engi…

> I agree that Rust is a large language, but I think you're overstating the complexity: it's been my experience that you don't need to know all (or even most) of the "clever" stuff to write large, performant Rust programs.

The same could equally well be said for, say, scala. In my experience though, you always pay one way or another for the unneeded and unwanted features in a language. Unreasonable compile times that kill joy and productivity are just one of the ways.

Re: Rust 2024 the Year of Everywhere?

#109

Post by kibwen »

pclmulqdq wrote: post #74
kibwen wrote: post #60

Earlier quoted context omitted.

> GCC-Rust may put Rust on track to have a decent STL since (presumably) GCC will not import a package manager. I think you may be misunderstanding something here? GCC-Rust would have no reason to import Cargo. Cargo is a tool for resolving and managing dependencies and generating compiler invocations. GCC-Rust is a compiler that would be invoked by Cargo. > the Rust STL itself is full of bit-rotting functions that h…

* GCC-Rust would then provide an incentive to make the STL more complete, if users of Rust on GCC don't have easy access to Cargo. * The first_entry and last_entry functions in BtreeMap come to mind immediately, but there were others I ran into. The fact that several new functions are stabilized with every release does not mean that many functions don't sit in the queue for years waiting for stabilization.

> if users of Rust on GCC don't have easy access to Cargo.

Can you clarify which users you mean? If you mean the developers of GCC-Rust, they don't need Cargo because GCC-Rust is written in C++. And users of GCC-Rust would have no problem using Cargo, assuming that GCC-Rust presents a CLI interface that's more-or-less compatible with rustc (which I assume they would want to do, because being compatible with the existing Cargo ecosystem is quite valuable).

> The first_entry and last_entry functions in BtreeMap come to mind immediately, but there were others I ran into.

The good news is that those functions were recently proposed for stabilization and the ten-day final comment period elapsed as of today with no objections, so these are on track to be available on stable as of Rust 1.66. As for the other functions that you allude to, I encourage you to join the libs-team Zulip and ask how best to proceed on a given API; quite often I find that there's nothing preventing an API from reaching stable other than finding someone willing to do the small amount of labor involved in documenting, writing a stabilization report, and issuing the stabilization PR.

Re: Rust 2024 the Year of Everywhere?

#110

Post by steveklabnik »

rascul wrote: post #84
pclmulqdq wrote: post #49

Earlier quoted context omitted.

I just recently started learning rust a few months ago, and I came to the same conclusion as you about packages. Cargo seems like the biggest impediment to Rust. GCC-Rust may put Rust on track to have a decent STL since (presumably) GCC will not import a package manager. However, insisting that a package manager have first-class treatment for a systems language just seems wrong. On the other hand, the Rust STL itself…

What is this STL you are referring to? It's not something familiar to me. Or do you mean the standard library (std)?

In C++, the "STL" is the "standard template library", which was a large inspiration for the standard library, but not actually the same project. Due to this history, some folks still call the standard library "the STL" even though it's not 100% accurate.
Post reply on HN