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

151–160 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#151

Post by pdimitar »

kibwen wrote: post #119
verdagon wrote: post #105

Earlier quoted context omitted.

In my experience learning Rust (and in watching others learn Rust) that first "aha!" moment is actually rather misleading. That moment comes when one learns how to technically accomplish any task in Rust. One knows the minimum set of tools needed to refactor enough to work around the borrow checker's limitations. Learning what the borrow checker prefers becomes second nature and, as you say, becomes natural. However,…

> The real challenge comes in figuring out when to work within it, and when to work outside it, in my opinion. You don't need to feel bad about "working outside" the borrow checker, and maybe that's a signal that needs boosting. I've been using Rust for ages and I'm not averse to cloning things when I need to. It's cool that you can create zero-allocation libraries by threading lifetimes everywhere, and I certainly a…

Yep, very much this. I code async CLI apps and I seriously don't care that the CLI args and the data structures they get transformed to are cloned 250 times at startup because after that 99% of the actual heavy-duty code is working with channels and references with nearly zero memory pressure. Memory usage gets bumped up by about 2% after the first 1-2 minutes of operation and it stays constant for next 11 hours during which I've monitored it.

I don't even need to benchmark anything. The apps are working ultra fast on a Celeron J450 CPU at ~20MB RAM usage and barely hit 10% CPU (since they're mostly network-bound).

No need for premature optimization. I haven't dived in the lifetime hell of Rust yet but I'm already quite productive and I will only be using zero-allocation techniques if my current code proves inadequate the the ever-increasing demand that these apps will soon face.

Re: Rust 2024 the Year of Everywhere?

#152

Post by qalmakka »

Ygg2 wrote: post #149
pjmlp wrote: post #147

Earlier quoted context omitted.

Dunno, maybe it is Stockholm syndrom from using C++ since 1993, but I definitly find easier to understand template metaprogramming than the upcoming GAT, or the whole Pin and PhatomData stuff.

Sure, but you are comparing meta programming facility to a type/lifetime feature that serves as Higher Kinded Type replacement. In Rust same thing holds, macros are easier than GAT I don't get why PhantomData or Pin are that hard to grasp? PhantomData is just a type marker that has no purpose other than help compiler. See https://doc.rust-lang.org/nomicon/phantom-data.html Pin is a way to create self referential stru…

> Pin is a way to create self referential structs, by pinning memory and preventing moves.

This, exactly. Pin works more or less like a C++ class with a deleted move constructor. Copies may be allowed if clone/copy (aka, the implicit/explicit copy constructor) are defined, but move and RVO are not.

Lots of Rust's concepts can often be described in terms of C++'s techniques, but more often than not in C++ it tends to be a hack, while Rust has a formalism for that, like Pin for instance. In C++ you can have moveable self-referencing structs because you can update the self references in the move constructor, but moves in Rust are always memcpy - which is saner IMHO than the whole move constractor and rvalue shenanigans.

Re: Rust 2024 the Year of Everywhere?

#153

Post by eggy »

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 feel the same way. I've dove in three or four times on Rust, but I get stuck learning Rust and not producing what I first set out to do in it.

Currently, I have committed to learning Zig for my low-level or C-type projects, and I have been having fun.

When I need what Rust claims to offer, I drop back to SPARK2014. A formally defined programming language with a set of verification tools. It meets all high integrity standards, and it has been around for a while with some helicopter operational code and the NATS iFACTS air traffic control system with over 500k lines of SPARK code.

It's nice to see now that AdaCore is teaming up with Ferrous Systems[0] to try and bring some of this to Rust. It shows the Ada/SPARK community want to propagate high-integrity software and not just promote a PL. As much as I like terse and expressive languages like J or APL or Haskell even, I find SPARK2014 to be more writable, readable, and it covers Rust's domain, even embedded [1].

It's Pascal-like block structure with 'end' delineates the program structure nicely for me, and in my opinion, much easier to follow than Rust. Elixir has sort of won the BEAM PL of choice category (it has 'end' blocks too). I think Rust will only get more complex. A SPARK on BEAM would be something!

[1] https://blog.adacore.com/how-to-prevent-drone-crashes-using-...

[0] https://blog.adacore.com/adacore-and-ferrous-systems-joining...

Re: Rust 2024 the Year of Everywhere?

#154

Post by pjmlp »

Ygg2 wrote: post #149
pjmlp wrote: post #147

Earlier quoted context omitted.

Dunno, maybe it is Stockholm syndrom from using C++ since 1993, but I definitly find easier to understand template metaprogramming than the upcoming GAT, or the whole Pin and PhatomData stuff.

Sure, but you are comparing meta programming facility to a type/lifetime feature that serves as Higher Kinded Type replacement. In Rust same thing holds, macros are easier than GAT I don't get why PhantomData or Pin are that hard to grasp? PhantomData is just a type marker that has no purpose other than help compiler. See https://doc.rust-lang.org/nomicon/phantom-data.html Pin is a way to create self referential stru…

I am only listening some of the concepts that I find harder to grasp, regardless of the context.

Macros are easier than GAT, maybe, there is a whole talk how serde goes crazy with macros.

PhantomData or Pin are hard to grasp, not as concept, rather to keep track when they are needed, many times it isn't clear that the way to fix some compilation error is to plug one of those types. A bit like having to do references to constant literals as well, another gotcha.

Re: Rust 2024 the Year of Everywhere?

#155

Post by pg_1234 »

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 is what Rust is ... the simpler, safer alternative to C++.

It is possible that, for the demanding domain spaces that have historically required C++, Rust is the end of the line for how far you can dumb down a language and still have the required sophistication and performance.

Re: Rust 2024 the Year of Everywhere?

#156

Post by biorach »

woodruffw wrote: post #97
rascul wrote: post #93

Earlier quoted context omitted.

What syntax is different with unsafe?

Unsafe Rust's syntax is a superset of Safe Rust, meaning that there is syntax in Unsafe Rust that will not compile in Safe Rust[1]. [1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

It's the same syntax. There are no special operators in unsafe rust. All unsafe code is syntactically valid safe code. The reason it will not compile it because certain operations are not permitted, not because of syntax errors

Re: Rust 2024 the Year of Everywhere?

#157

Post by biorach »

woodruffw wrote: post #122
kibwen wrote: post #116

Earlier quoted context omitted.

> that's what makes it distinct and therefore a unique language with unique semantics Unsafe Rust doesn't have different semantics from Safe Rust, it's the exact same language but it allows more operations. Which is to say, for any given expression that compiles with Safe Rust, if you wrap that expression in an unsafe block it will have precisely the same semantics. For the book to describe it as a "second, hidden la…

> Unsafe Rust doesn't have different semantics from Safe Rust, it's the exact same language but it allows more operations. "Allows more operations" seems like a straightforward meaning for "different semantics" to me. In Safe Rust, you can't access union members. In Unsafe Rust you can. I agree that it's a little fanciful, but I also don't think it's really wrong. > To suggest that this means that the language itself…

> "Allows more operations" seems like a straightforward meaning for "different semantics" to me. In Safe Rust, you can't access union members. In Unsafe Rust you can

The semantics are the same. The meaning of the operation is same. In both safe and unsafe accessing union members is the same operation with the same meaning. The only difference is that in unsafe Rust you are allowed do this. This is a difference in permission, not meaning

Re: Rust 2024 the Year of Everywhere?

#158

Post by biorach »

fulafel wrote: post #130
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? In Rust the complexity comes from elsewhere (eg rejecting GC), there are lots of easier languages that match the safety. Rust is not really the paragon of safety, its guarantees are similar to easy languages like F# or even Java. And behind Ada.

> And behind Ada.

https://lwn.net/Articles/908057/

> The biggest problem of Ada IMO is that it was always supposed to be about safety, but it never addressed the most common source of bugs: pointer safety. Not even with SPARK. It's like discussing about how can you fortify the door in a house with three walls. I suspect they planned to solve it like everyone else (with tracing GC), but that never materialised (because most Ads users don't want tracing GC) thus was always kinda weird “safe” language which doesn't tackle the most common source of bugs.

> Finally, in year 2020, it solved that problem. By picking ideas from Rust, of course.

> But by that time momentum was lost and it would be very hard to overcome that “safe language without safety” stigma.

Re: Rust 2024 the Year of Everywhere?

#159

Post by gorilla0 »

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 am personally still doubtful of Rust's adoption. I consider the 2008-2014 period the peak hype cycle for Haskell and don't see that it changed professional programming much. I predict it will be similar for Rust.

Re: Rust 2024 the Year of Everywhere?

#160

Post by rob74 »

infogulch wrote: post #99

Every time there's a new post about 'big new features' in current or future Rust releases there's someone shouting in fear of how Rust is getting more and more complex. Rust may be complex, but 99% of newly added features have not made it more complex than the initial release. Consider a different language with three orthogonal features. You could think of its 'design space' as a cube , where each feature corresponds…

Maybe this will be an unpopular opinion here, but I guess that's one of the reasons why Go is easier to use than Rust. Ok, the main reason is of course that you don't have to think about memory management complexities. And Go also has fewer of these "orthogonal features" than Rust. But for those features that are there, they made sure that, as far as possible, every feature was working together with every other feature from the start, and not "we'll start by allowing this only for A, B and C, and then let's see where it goes from there"...
Post reply on HN