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

61–70 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#61

Post by jjtheblunt »

yyyk wrote: post #53
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…

Rust is rather lean - you'd have to give up something to simply. e.g. most simpler languages are GC languages. That said, GC shouldn't be a problem for 90% of apps. Now, it's not unlikely that eventually Rust will accrete enough baggage to need replacement too - I'm guessing we have 20 years minimum until that happens?

It seems like a section of those enthused already left quite publically, maybe a couple years ago, once async was added with that syntax.

Re: Rust 2024 the Year of Everywhere?

#62

Post by kccqzy »

webkike wrote: post #57
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…

If this is the case, why hasn’t math been replaced?

Parts of math have been replaced. The original Maxwell's equations were replaced since the new ones were much simpler.

Re: Rust 2024 the Year of Everywhere?

#63

Post by woodruffw »

p1necone wrote: post #50
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.

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.

Re: Rust 2024 the Year of Everywhere?

#64

Post by ilovecaching »

switchbak wrote: post #34
ilovecaching wrote: post #10

Earlier quoted context omitted.

If you don't need to care about vm, you probably should be using a GC language. If you do, you certainly need to understand vm.

Virtual memory != Memory management, your abbreviations are confusing.

Sorry, I don't normally work outside of the kernel. To me vm is a common abbreviation with a well understood meaning.

Re: Rust 2024 the Year of Everywhere?

#65

Post by woodruffw »

andrewstuart wrote: post #37
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.

There's something wrong if a language is so unsuited to programming itself that it needs another language - or five more languages - to get the job done. This is one of the great things about JavaScript - it's flexible enough to do everything in its ecosystem.

I don't think that's a good metric. Most of the most successful programming languages of all time have had at least one macro or attribute language attached to them.

Re: Rust 2024 the Year of Everywhere?

#66

Post by nu11ptr »

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 and the more you care about every cycle of performance the more of those you have, but if you are just looking to code Rust as a high level language, it really isn't that hard. Knowing that everything is likely to work when it compiles is really good feeling too.

Tips/Concepts:

- Form a mental model of the rules/memory model of the language, this will help you get to an understanding, and once you understand you don't have to remember the rules.. you could write them yourself.

- The analogy I used to understand borrowing: it is like a read/write lock. Any data structure can be read any number of times (&), but it can only be written once at a time (&mut)

- Borrowing "locks" the position of the data structure and this is one of my favorite features. Imagine you have a reference to the middle of a data structure and then it suddenly moves... this can't happen in Rust as borrows "lock" the struct from moving

- Lifetimes aren't magic and you are in no way defining the lifetimes themselves with lifetime annotations. All you are doing is helping the compiler see which references are backed by what values already. Once you understand which these are lifetimes become easy.

- Eventually you will have an aha moment.. and you will wonder what was so hard. You will have to think about memory in a lower level way, but only to learn it, after that it is just natural

Re: Rust 2024 the Year of Everywhere?

#67

Post by rascul »

andrewstuart wrote: post #25
CountSessine wrote: post #21

Earlier quoted context omitted.

I think any language that has the concept of storage classes will be complicated because you have to deal with copy versus move vs borrow semantics. Other languages get around this by just saying that primitives are on the frame and everything else is on the heap. Efficiency has its price.

As I understand it Rust is composed of 5 or 6 sub languages. I find it hard to believe that there's no way to get the benefits of Rust without 5 languages. Why can't a programming language be one language that does everything it needs to do? Seems crazy to me to have 5 or 6 sublanguages.

I think you might be referring to this:

https://gist.github.com/brendanzab/d41c3ae485d66c07178749eae...

In which there is:

>Many sub-languages to learn, many with different syntaxes and semantics. For example:

> the expression language

> unsafe runtime language

> safe runtime language

> compile time language

> the type language

> the trait language

> the macro language

> the attribute language

And was discussed (122 comments):

https://news.ycombinator.com/item?id=32819444

Re: Rust 2024 the Year of Everywhere?

#68

Post by kibwen »

jjtheblunt wrote: post #61
yyyk wrote: post #53

Earlier quoted context omitted.

Rust is rather lean - you'd have to give up something to simply. e.g. most simpler languages are GC languages. That said, GC shouldn't be a problem for 90% of apps. Now, it's not unlikely that eventually Rust will accrete enough baggage to need replacement too - I'm guessing we have 20 years minimum until that happens?

It seems like a section of those enthused already left quite publically, maybe a couple years ago, once async was added with that syntax.

I'm not entirely sure what this is referring to? If it's something about Rust's postfix await syntax, it's quite lovely in practice, and even if someone disagreed they wouldn't leave the language over something like that.

Re: Rust 2024 the Year of Everywhere?

#69

Post by aussiesnack »

Cyph0n wrote: post #47
aussiesnack wrote: post #20

Earlier quoted context omitted.

I'm currently learning Rust (as a distinctly average programmer) and I think I agree. I put that so tentatively because I have experienced something of what Rust advocates claim - ie. when I've battled just trying to get a module to work at all for a while, but then when it does fit together (in a rather pleasing way, like gears snicking neatly together), it just continues to work. So I don't rule out the possibility…

Out of curiosity, can you share examples of popular libraries that were difficult to get working correctly?

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 (which is more explicit) or parsed the args manually.

But I've experienced similar things repeatedly. Complexity seems to be tolerated (even vaunted) by the Rust dev community at large. I don't rule out that this may have good reasons behind it (the nature of Rust's natural domain, etc).

Re: Rust 2024 the Year of Everywhere?

#70

Post by [deleted] »

kibwen wrote: post #40
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.

Unsafe Rust is a minimal superset of Safe Rust, proc macros aren't their own language, there's no such distinction between Rust and "the attribute language", and async Rust isn't its own distinct thing, it's all just Rust.

[deleted]
Post reply on HN