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

81–90 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#81

Post by azakai »

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 wonder if there is a subset of Rust that can be extracted someone into a new, minimal language with the core benefits.

That is basically what Val aims to do:

https://www.val-lang.dev/

It has Rust-style ownership to guarantee memory safety, but without the complexity of lifetimes.

There is still a borrow-checker-like component, but I believe it should be much simpler than Rust's (see e.g. "method bundles" and how they are called).

Still in the research phase. It is an open question how well this approach scales.

Re: Rust 2024 the Year of Everywhere?

#82

Post by kibwen »

aussiesnack wrote: post #73
nu11ptr wrote: post #66

Earlier quoted context omitted.

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.

Yes, Rust is quite different from typical languages thanks to ownership and borrowing. It often takes people several attempts to learn it before their perspective shifts and it finally clicks for them. But this perception of Rust has less to do with Rust being "hard" than it has to do with Rust being "different". To be sure, Rust has hard parts even after you've internalized the differences, but IMO by that point it's not substantially different from mastering the hard parts of other languages (especially other systems languages, none of whom can get away with entirely sweeping the details of the machine under the rug).

Re: Rust 2024 the Year of Everywhere?

#83

Post by rascul »

aussiesnack wrote: post #69
Cyph0n wrote: post #47

Earlier quoted context omitted.

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…

Interesting. I find the clap derive stuff great and haven't had any trouble figuring out how to use it. Compared to anything I've done before in any other language, it's so much simpler and straightforward for me. Maybe it helps that I used structopt before clap incorporated it? I don't know. Different people can have very different experiences.

Re: Rust 2024 the Year of Everywhere?

#84

Post by rascul »

pclmulqdq wrote: post #49
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…

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)?

Re: Rust 2024 the Year of Everywhere?

#85

Post by nu11ptr »

aussiesnack wrote: post #73
nu11ptr wrote: post #66

Earlier quoted context omitted.

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.

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 example. However, I find it much more rewarding.

Re: Rust 2024 the Year of Everywhere?

#86

Post by woodruffw »

p1necone wrote: post #76
woodruffw wrote: post #63

Earlier quoted context omitted.

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.

Sure: you can clearly drive this to absurdity.

The list I gave was the ones I've heard people in the Rust community, including official Rust language documents, refer to as separate languages. Does that guarantee that we're carving the nature of "computer language" at its joints? No; it's merely a shorthand for expressing the range of syntaxes and semantics that you need to know to "fully" know Rust.

Re: Rust 2024 the Year of Everywhere?

#87

Post by jjtheblunt »

CountSessine wrote: post #21
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 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.

The counter-observation might be that Rust exposes, as a responsibility of the programmer, the completion of what would otherwise be compile-time analyses in sophisticated compilers. (Borrow and move look what SSA could comment on, for a simple example.)

Re: Rust 2024 the Year of Everywhere?

#89

Post by webkike »

kccqzy wrote: post #62
webkike wrote: post #57

Earlier quoted context omitted.

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.

What part of rust do you think can be made simpler?

Re: Rust 2024 the Year of Everywhere?

#90

Post by aussiesnack »

kibwen wrote: post #75
aussiesnack wrote: post #59

Earlier quoted context omitted.

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

I didn't find anything tricky about the ownership model. The last two languages I learned were Clojure then Elixir, both of which had far more concepts novel to me (with no experience in Lisps nor functional languages), yet neither gave me the trouble Rust has.

Frankly your response is typical of the smugness I find with Rust advocates. You 'know' Rust isn't complex (perhaps because of your own experience). When people say they find it so, you consider it your role to inform them about how they are mistaken about their own experience.

Post reply on HN