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

31–40 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#31

Post by jerf »

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…

"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 unaccounted-for mutation a non-problem. Those are not intended as complete lists, either. I gather Clojure can be used to a large degree this way, for instance. Nor is this a full list of all the possible solutions, just the ones that leap to my mind.

The bad news is, the complexity in Rust is still there for a reason. I see the earlier efforts as something like the same picture as Rust is trying to be, but blurred. Immutability and inability to mutate across threads at all both solve the safety problems, but with a bigger hammer and a blunter flattening of the problem space. Technically, Rust's greater complexity allows it to hug the true parameters of the safety problem space more closely. I suspect that tradeoff is fundamental and you can't have Rust's feature set without roughly equivalent complexity.

Fortunately, not every language has to be Rust. Fortunately, Rust exists for those times when we really, really need it. There can't be one language to rule them all, and Rust isn't going to fill that nonexistent niche. That's OK. Rust only has to be the best Rust it can be, and those other languages can be the best languages they can be, and in the end that's just as good as it can get.

(Also, while this isn't a solution to the safety problem, you can still get a lot of mileage by adopting solutions from those domains into languages that technically unsafe, but work fairly well if you program them with a collection of reasonably safe patterns. I work a lot in Go. It is not particularly safe, technically; safer than C but that's a low, low bar. But in practice I don't have a lot of safety problems with it because I spent years cutting my teeth on Erlang and Haskell and my designs are informed by that.)

Re: Rust 2024 the Year of Everywhere?

#32

Post by ZephyrBlu »

ilovecaching wrote: post #10
ZephyrBlu wrote: post #8

Earlier quoted context omitted.

As someone who generally prefers high level languages (Ruby, Python, JS) I'm enjoying Rust because unlike C and Cpp, I don't really have to care about memory. I don't want to spend my time thinking about memory allocations and deallocations. Rust lets me focus on logic like a high level language does and the compiler tells me whether what I'm doing is memory safe or not. I'm vaguely aware of copying/cloning values, b…

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.

vm = virtual machine/memory?

I'm porting this Python library to Rust: https://github.com/Blizzard/s2protocol.

For the shitty, first pass prototype code I've written so far I've seen a ~30-40x speedup compared to the Python implementation and a ~2x speedup compared to a Go implementation written by someone else: https://github.com/icza/s2prot.

That is why I chose Rust over a GC language like Go (E: I also wanted to learn it ofc). It's a lot faster out of the box, even without me having a strong understanding of memory operations.

Re: Rust 2024 the Year of Everywhere?

#33

Post by Scarbutt »

buzzdenver wrote: post #16
Scarbutt wrote: post #3

Rust is so simple and elegant.

Was it simple and elegant from the beginning, or did it click at some point? I started learning it from the O'Reily book yesterday, and so far it's easily the steepest learning curve for a language.

sarcasm

Re: Rust 2024 the Year of Everywhere?

#34

Post by switchbak »

ilovecaching wrote: post #10
ZephyrBlu wrote: post #8

Earlier quoted context omitted.

As someone who generally prefers high level languages (Ruby, Python, JS) I'm enjoying Rust because unlike C and Cpp, I don't really have to care about memory. I don't want to spend my time thinking about memory allocations and deallocations. Rust lets me focus on logic like a high level language does and the compiler tells me whether what I'm doing is memory safe or not. I'm vaguely aware of copying/cloning values, b…

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.

Re: Rust 2024 the Year of Everywhere?

#35

Post by Thaxll »

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.

For simple CRUD app maybe, but the moment you start to do anything more complicated, aka manipulating data it's a complete different story.

Re: Rust 2024 the Year of Everywhere?

#36

Post by woodruffw »

aussiesnack wrote: post #30
andrewstuart wrote: post #25

Earlier quoted context omitted.

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.

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.

Re: Rust 2024 the Year of Everywhere?

#37

Post by andrewstuart »

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.

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.

Re: Rust 2024 the Year of Everywhere?

#39

Post by aussiesnack »

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.

Ah yes that'd be right. Haven't needed to write any unsafe Rust, so that's kind of under my radar. But agree about the macro langs.

Re: Rust 2024 the Year of Everywhere?

#40

Post by kibwen »

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.

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.
Post reply on HN