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

131–140 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#131

Post by sam0x17 »

kibwen wrote: post #120
bsder wrote: post #118

Earlier quoted context omitted.

> You don't find it hard. Many do. The question at the end of the day is whether that "hardness" is required or accidental. My gut feel is that Rust does have some accidental complexity--poor support for static/globals, poor support for placement new and alternate allocators, inability to transmute equivalent types well, etc. However, my gut feel is also that a lot of Rust's "difficulty" is the fact that people reall…

*> poor support for static/globals I'll agree with your other things, but discouraging global state is an aspect that reduces ultimate complexity, rather than increasing it. :P

global state is often necessary. Abusing it is always possible, but every startup-sized application footprint I've ever been in we eventually have to add an exception to the no-globals linting rule for some very legitimate reason in some specific place.

The crate ecosystem (oncecell, lazystatic) lets you completely sidestep this limitation for now anyway before better const behavior eventually gets added to stable

Re: Rust 2024 the Year of Everywhere?

#132

Post by jandrewrogers »

kibwen wrote: post #120
bsder wrote: post #118

Earlier quoted context omitted.

> You don't find it hard. Many do. The question at the end of the day is whether that "hardness" is required or accidental. My gut feel is that Rust does have some accidental complexity--poor support for static/globals, poor support for placement new and alternate allocators, inability to transmute equivalent types well, etc. However, my gut feel is also that a lot of Rust's "difficulty" is the fact that people reall…

*> poor support for static/globals I'll agree with your other things, but discouraging global state is an aspect that reduces ultimate complexity, rather than increasing it. :P

It increases complexity if the state is intrinsically global. Hardware resources, for example, which are commonly directly managed in systems code, are intrinsically global state. You can't allocate another hard drive or physical network interface. I've seen impressively convoluted code that existed solely to pretend that global state isn't actually global state, because that was seen as bad, even though it behaved exactly like global state.

Re: Rust 2024 the Year of Everywhere?

#133

Post by sam0x17 »

As a library author a big aha moment for me was being able to write proc macros. There are so many creative (and simple to implement) ways of getting around certain limitations when you can just do some smart code-gen. I think a lot of people get overwhelmed by the limitations before considering what the world of proc macros has to offer.

Re: Rust 2024 the Year of Everywhere?

#134

Post by egnehots »

sam0x17 wrote: post #133

As a library author a big aha moment for me was being able to write proc macros. There are so many creative (and simple to implement) ways of getting around certain limitations when you can just do some smart code-gen. I think a lot of people get overwhelmed by the limitations before considering what the world of proc macros has to offer.

as a library user, I dread proc macros since they are often associated with slow, long compile times.

Re: Rust 2024 the Year of Everywhere?

#135

Post by aussiesnack »

kibwen wrote: post #121
aussiesnack wrote: post #101

Earlier quoted context omitted.

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

> Complexity (not conceptual difficulty) seems to be the general culturally accepted norm. Can you give an example of what you mean by "complexity"? I think this could be an instance of people simply having different definitions.

In a way it's tricky to encapsulate, precisely because I do mean 'complexity' rather than 'conceptual difficulty', and complexity spreads through systems in thousands of small ways. Clap's one example - it's not only immensely hard to use (compared to what you find in other languages), but this is compounded by the fact that it's the library everyone recommends when asked online. This speaks to a cultural acceptance of complexity within the Rust community. I've found the same with nearly all of the commonly used libraries I've needed. As soon as I needed to do anything custom with serde it took me hours to figure out how. I gave up on all the general database libraries trying do some simple persistence to sqlite (though I did end up with rusqlite, which is genuinely simple). The utility traits smear complexity throughout just about everything an application programmer needs to do.

Without a lot of experience (not to mention vast amounts of memorisation), everything is just hard and slow to get done. And I do mean by comparison with other languages I've used, from Objective-C to Java, from Typescript to Elixir (and many others).

Again, this isn't necessarily a complaint about the complexity per se. It might be necessary (I don't feel I know enough to judge), given Rust's uses and constraints. But the community consistently and obviously denies the difficulty. I think I understand the sources of the denial. But that doesn't make it any less irritating!

Re: Rust 2024 the Year of Everywhere?

#136

Post by aussiesnack »

nu11ptr wrote: post #85
aussiesnack wrote: post #73

Earlier quoted context omitted.

> Rust isn't really all that hard. You don't find it hard. Many do.

I can see how it could be hard for someone used to high level languages and who doesn't care about how memory actually works "under the hood". The secret to learning Rust is really the same as C/C++: you have to learn to think of memory in a low level way -and- learn Rust's safety rules for dealing with that. I think it does take someone very dedicated to the task, more so than is required to learn say Python, for ex…

I don't think the ownership model, borrowing, references etc are actually particularly difficult. They're well explained in "The Book", even better so in Jim Blandy's "Programming Rust", and at least in principle can be got over in an afternoon. Admittedly it can all knotty with a lot of closures and async etc, but it's certainly not the source of the difficulties for me.

Re: Rust 2024 the Year of Everywhere?

#137

Post by hither_shores »

stormbrew wrote: post #128
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…

I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad. I like haskell, don't get me wrong, but it is not in any way simple to write or read or work with by comparison. And while rust has some heady concepts in its design, for the most part even advanced users don't actually need to understand most of them to use it (I thin…

> I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad.

This seems clearly false to me. Haskell has a higher abstraction ceiling than Rust, but unless you want to contribute to a particularly heavyweight library (`lens` comes to mind) you can get by just fine without going anywhere near it. In practice, most code in both languages maxes out at or below the mathematical sophistication of an introductory algebra class.

Re: Rust 2024 the Year of Everywhere?

#138

Post by resonious »

mikepurvis wrote: post #104
resonious wrote: post #44

Earlier quoted context omitted.

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.

That's true, a lot of Rust's features do exist in C++. I guess the main difference is that Rust is safe by default and you have to go out of your way to be unsafe. C++ is basically unsafe by default. In C++, the standard syntax for allocating memory gives you a completely unchecked pointer that you can freely use from whatever thread you want.

Re: Rust 2024 the Year of Everywhere?

#139

Post by davidatbu »

Gigachad wrote: post #126
BatFastard wrote: post #46

Earlier quoted context omitted.

I am relearning c++, much has changed in last 12 years! I tried Rust, but when doing a data driven app, I found myself using unsafe way too much!

Why are people always more afraid of unsafe than C/++? Using C++ because you had to use unsafe is throwing the whole house out with the bath water. It’s like Rust forces people to acknowledge when they are taking things in to their own hands while C/++ let’s them live in blissful ignorance.

This is indeed very curious!
Post reply on HN