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

71–80 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#71

Post by woodruffw »

cesarb wrote: post #51
woodruffw wrote: post #36

Earlier quoted context omitted.

If I had to guess: Safe Rust, Unsafe Rust, proc macros, declarative macros, the attribute language, and maybe async Rust (although I'd really just consider this sugar on Safe Rust). I love Rust, but I would love to see more syntactic unification between these components. Both macro languages, in particular.

> Safe Rust, Unsafe Rust These two are the exact same language. Some features (like calling unsafe functions, or dereferencing raw pointers) are "locked" outside unsafe blocks, but syntactically and semantically they are identical. It's easy to show this: put a unsafe block around a normal "safe" block, and all that happens is an extra "this does not need to be an unsafe block" warning from the compiler.

My other responses say this in more detail, but: they're not the exact same language if they have separate semantics and syntaxes, which they do. The fact that they can be composed together (much like C and the C preprocessor) does not make them the same language; it just makes them compatible.

Re: Rust 2024 the Year of Everywhere?

#72

Post by p1necone »

woodruffw wrote: post #36
aussiesnack wrote: post #30

Earlier quoted context omitted.

Not quite sure what you mean by sublanguages - procedural and declarative macros perhaps? In any case I wonder about the simplicity/complexity dance. Simplification ends up with something like Lisp, in which you write DSLs that each has to be independently learned. Elixir does something similar. Some differentiation might just be a natural consequence of chasing ergonomics.

If I had to guess: Safe Rust, Unsafe Rust, proc macros, declarative macros, the attribute language, and maybe async Rust (although I'd really just consider this sugar on Safe Rust). I love Rust, but I would love to see more syntactic unification between these components. Both macro languages, in particular.

As far as I'm concerned any programming language either has a good, builtin, type safe macro system, or people are going to use code generation (on large complex projects). And I never want to have to work on something with custom code generation.

Typescript seems to have embraced the third option, which is having such a batshit insanely expressive dynamic type system that you don't need either 99% of the time while still having proper type safety.

Re: Rust 2024 the Year of Everywhere?

#73

Post by aussiesnack »

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…

> Rust isn't really all that hard.

You don't find it hard. Many do.

Re: Rust 2024 the Year of Everywhere?

#74

Post by pclmulqdq »

kibwen wrote: post #60
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…

> 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.

Re: Rust 2024 the Year of Everywhere?

#75

Post by kibwen »

aussiesnack wrote: post #59
mdtusz wrote: post #22

Earlier quoted context omitted.

I'm curious why you think it's too big to master. There's certainly a lot to the language, but it's design means that these various facets are largely contained to their area of effect. I'd be confident in the assertion that most rust developers don't need to understand much more than the basics of the type system, traits, lifetimes, and the surface levels of async. The biggest benefit to the language is precisely th…

> I'm curious why you think it's too big to master. Many of us do find Rust very hard to get to grips with, however much we're informed by Rust advocates that it isn't! I don't know if there's any readily available way to be objective about this? I think all we have is attestation. Here's Chris Keathley (of some Elixir fame): > I've written a non-trivial amount of Rust code (50-100k lines) .. and I feel like I barely…

It's entirely reasonable to have trouble getting to grips with Rust, as ownership and borrowing are quite different paradigms compared to the usual mainstream languages that people tend to know. But there's no way to write "50k lines" of Rust without saying that you understand the language, so I'm baffled by what the author is trying to imply there. If you don't understand the language, then you won't even make it to 1k lines.

Re: Rust 2024 the Year of Everywhere?

#76

Post by p1necone »

woodruffw wrote: post #63
p1necone wrote: post #50

Earlier quoted context omitted.

Unsafe Rust is just Rust, but there's a few extra things you can do inside unsafe blocks that you can't normally do outside them (because they're unsafe). I wouldn't call it a different language.

See my response to 'kibwen. We can nitpick all day about whether it's really a separate language; I think it satisfies at least one important definition of "language" by having its own separate syntax and semantics that aren't accessible to Safe Rust.

But by that argument every feature in a language is it's own separate language. "This is the language that can only be written inside function definitions", "This is the language that can only be written inside ternary operators" and so on.

Re: Rust 2024 the Year of Everywhere?

#78

Post by rascul »

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…

I'm just a hobby coder. Except for lifetimes and a bit of fighting with the borrow checker, the language came fairly easily for me. After banging my head against the borrow checker for a week or two at some point something switched in my brain and all of a sudden I wasn't fighting the borrow checker anymore. This was spending maybe 1-2 hours a day with rust. I don't often have a lot of time to write code. Everyone has their own experiences, though, and this is just mine.

Re: Rust 2024 the Year of Everywhere?

#79

Post by [deleted] »

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…

[deleted]

Re: Rust 2024 the Year of Everywhere?

#80

Post by jasfi »

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…

That's Nim.
Post reply on HN