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

51–60 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#51

Post by cesarb »

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.

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

Re: Rust 2024 the Year of Everywhere?

#52

Post by josephg »

echelon wrote: post #13
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…

Writing Rust/Actix for server code is a breeze. There's zero complexity. It's practically Java, just with a more Ruby-like syntax. Entirely depends on what you're building. Edit: You can have a small Actix app up over the weekend and never touch "lifetimes" until you're ready.

Part of my work involves the braid HTTP spec. Braid uses a custom server-sent events like protocol sent over long lived HTTP connections. I spent about a week trying to get this working using rust & actix. My code became mired in complex lifetimes, crazy iterators, Pin, async and Futures. Hundreds of lines of code later, I gave up and rewrote the whole thing in an hour or two, in about 30 lines of javascript.

The whole experience was so bad I've sworn off using async rust entirely until a few more features land. Thankfully, apparently there GAT lands next release - although its not clear to me if it'll work for futures yet, or if thats a later goal.

I love rust. But, wow.

Re: Rust 2024 the Year of Everywhere?

#53

Post by yyyk »

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?

Re: Rust 2024 the Year of Everywhere?

#54

Post by xyzzy_plugh »

ilovecaching wrote: post #4

This is why Rust will eventually become the next C++ - it's becoming just as bloated with type theory, a cumbersome syntax, and will eventually ignite a begrudging dislike by the people that have to find a subset of the language to make sense of just to write simple programs. Everything about this language is overcomplicated by language enthusiasts. The best thing for Rust over the next few years is for it to fall to…

It already is the next C++. It's a powerful language full of incredible abstractions but sadly that attracts incredibly smart developers who worship at the altar of complexity.

I enjoy rust for what it is, and I've had fun writing programs in it. You couldn't pay me to work with it in a professional capacity involving peers. I'll stick to Go, where my code reads and writes like everyone else's.

Re: Rust 2024 the Year of Everywhere?

#55

Post by slurpmaker »

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…

It's really not that hard. You just need to practice a bit and get over some concepts. Highly recommend buying a rust book to supplement the online rust book, or getting involving the a forum/chatroom and asking questions. The community realizes it's a bit of a brain shock, but once you get over it, it's actually pretty easy to do 99% of the things you need to do. Even, easier than in other languages in a lot of cases. A few areas are tricky/hard, but if you walk before you run (which most people SHOULD do in other languages) it's entirely doable.

The problem with an easier rust is... These are the rules for using your computer safely. Like, this is what you should be doing when reading/writing C code. Or C++. So learning rust is hard, but it makes you a better programmer faster IMO. Also... once you write rust code it's usually good, no weird surprises Saturday at 2:00am in production, it's just done and works.

Anyway wishing you the best, but be careful asking for "an easier rust". An easier "Rust" probably isn't safe and you might as well just be writing any other language.

Re: Rust 2024 the Year of Everywhere?

#56

Post by woodruffw »

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.

Unsafe Rust is, in the Rust Language book's own words, a "second hidden language" within Safe Rust[1]. You're absolutely right that it's a superset; that's what makes it distinct and therefore a unique language with unique semantics (even if the syntax is nearly identical).

Procedural macros can be used to define new languages within Rust, which means that grokking them requires the developer to understand their expressive capacity. For example, the paste[2] crate introduces a little bit of novel syntax for combining identifiers.

Attributes are the counterpart to Unsafe Rust: their syntax is described separately from the rest of Rust[3]. Understanding how to use them involves components of Rust that aren't tied to the syntax of programs (e.g. doc and feature attributes, which connect to Rust's standard tooling instead).

I agree that async Rust isn't its own distinct thing. I threw that one in as a possible interpretation, to make the count work.

[1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

[2]: https://docs.rs/paste/latest/paste/

[3]: https://doc.rust-lang.org/reference/attributes.html

Re: Rust 2024 the Year of Everywhere?

#57

Post by webkike »

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?

Re: Rust 2024 the Year of Everywhere?

#58

Post by lumost »

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…

The main advantage of rust is that you can “do anything” with it. It’s fast, it has deterministic performance, you can embed it, you can write low level code, you can write fancy high level code.

Cpp devs never moved because there were always large projects chugging along in cpp and they always had the feeling that they knew what they were doing.

Re: Rust 2024 the Year of Everywhere?

#59

Post by aussiesnack »

mdtusz wrote: post #22
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'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 understand Rust as a language

I don't think that's an uncommon perspective.

Re: Rust 2024 the Year of Everywhere?

#60

Post by kibwen »

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…

> 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 have been stable for years but are still somehow only in the nightly release and haven't made it out of "experimental" status.

Rust stabilizes several new library functions with every release. Which ones are you trying to use? Rust is driven by volunteers, and many functions only get stabilized when people ask for them and present concrete use cases.

Post reply on HN