Rust 2024 the Year of Everywhere? • Hacker News Board

Re: Rust 2024 the Year of Everywhere?

#171

Post by jerf » Fri, Sep 23, 2022, 2:03 PM UTC

resonious wrote: post #44

jerf wrote: post #31

Earlier quoted context omitted.

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

Aren't Haskell and Erlang both GC? I don't think anyone is touting Rust as newly immutable. The only differentiator (to my understanding) is Rust's safety without GC .

"Aren't Haskell and Erlang both GC?"

I answered the question about safety. You can have the safety of Rust without the complexity of Rust. I never promised there are languages that will have every last attribute of Rust but be simpler, and even typing that sentence out should make it clear that that is fairly unlikely to happen. Adding a GC is one way to simplify Rust. All simplifications of Rust are going to come with side effects. The complications are there for a reason; the question is always, does the code you're writing right now require that complexity, or can you use a simpler safe solution? Usually the answer will be the latter, honestly. Only a fraction of programs require that level of control... but it's a very important fraction!

There are some immutable languages inspired by Rust that are trying to have immutability without garbage collection but they're a ways off from practicality, I think.

Re: Rust 2024 the Year of Everywhere?

#172

Post by fulafel » Fri, Sep 23, 2022, 2:06 PM UTC

biorach wrote: post #158

fulafel wrote: post #130

Earlier quoted context omitted.

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

Yep. Borrowing ideas is good and completely ok, as Rust also does copiously, this is how our languages improve. But of course Ada has a lot of other safety features that Rust does not.

Re: Rust 2024 the Year of Everywhere?

#173

Post by jerf » Fri, Sep 23, 2022, 2:10 PM UTC

stormbrew wrote: post #128

jerf wrote: post #31

Earlier quoted context omitted.

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

I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad. I like haskell, don't get me wrong, but it is not in any way simple to write or read or work with by comparison. And while rust has some heady concepts in its design, for the most part even advanced users don't actually need to understand most of them to use it (I thin…

Haskell is not really that complicated. What it is is capable of hosting dizzying complexity on top of its relatively simple core, which it is capable of hosting precisely because the core is so simple. It is similar to Lisp in that regard.

There's also rather a lot of spazzing out because some very simple concepts like "monad" in Haskell somehow managed to pick up a lot of very bad explanations and an aura of mystique they don't deserve. They're really only complicated if you go in assuming they must be, and that if you have a simple understanding it must be wrong because it has to be complicated. Rust fans may be familiar with the process; I see the borrow checking starting to pick up a bit of a similar mystique with the greater community, though I don't think it'll ever quite reach the same level of fever pitch as "monad" has. And I think there's even a similar process; start with Rust, print out Hello World, then immediately try to jump to writing a custom network application in Tokio and, yeah, the borrow checker is going to look pretty complicated since you're basically trying to swallow it all in one shot. The solution is, don't do that.

I detect some of that mystique in your post. It is a complete myth that you need to be a math postgrad to understand Haskell. It is a complete myth that you must understand group theory to use Haskell. It has even been observed that knowing too much Haskell can make group theory a bit harder to learn, and knowing too much group theory can make Haskell a bit harder to learn, because Haskell has a very programming-language centric view of group theory that means that even though some terminology is shared, everything is just a bit askew from the other. You no more need to be a math postgrad to use Haskell than you do to use a structured programming language, which also used to be a weird math nerd thing. Now it's just how programming languages work.

Re: Rust 2024 the Year of Everywhere?

#174

Post by mikepurvis » Fri, Sep 23, 2022, 2:27 PM UTC

Gibbon1 wrote: post #144

mikepurvis wrote: post #104

Earlier quoted context omitted.

I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do. But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.

> or return a pointer to a local variable that's about to go out of scope I thought of that recently. I wonder about using escape analysis to detect that and simply don't release the stack frame until the reference goes out of scope.

Static analysis/tracing absolutely can do a bunch of that kind of thing, particularly catching trivial cases.

But I think it's still a pretty important upgrade when those things are being checked by the compiler, for free, with guarantees, as part of every build, rather than using some side-tool that may be proprietary, deliver oodles of false positives, and so on.

Re: Rust 2024 the Year of Everywhere?

#175

Post by woodruffw » Fri, Sep 23, 2022, 2:36 PM UTC

biorach wrote: post #157

woodruffw wrote: post #122

Earlier quoted context omitted.

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

The meaning of the operation is not the same, because it is not an operation in Safe Rust.

Re: Rust 2024 the Year of Everywhere?

#176

Post by mwcampbell » Fri, Sep 23, 2022, 2:53 PM UTC

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…

I figured that working outside the borrow checker meant using unsafe.

Re: Rust 2024 the Year of Everywhere?

#177

Post by pornel » Fri, Sep 23, 2022, 3:12 PM UTC

taylodl wrote: post #169

I'm a software developer with over four decades of experience under my belt in every environment you can imagine - startups, manufacturing company, utility, retail, banking, education - and here's a trend I've noticed in that time: many languages come, a few stick, and they're slow to fade away. Very few have stuck around for decades. Today's darling is tomorrow's pariah. Cobol, C/C++, and Java are great examples of…

According to TIOBE, C has lost 60% of its popularity between 2015 and 2017, and then doubled next year. What's more likely: that a 40-year-old language C had such a massive sudden swing, or that TIOBE data is garbage and measures search engine's algorithms, not language relevance?

https://blog.nindalf.com/posts/stop-citing-tiobe/

BTW: According to the TIOBE horoscope Rust is way ahead of TypeScript and Bash.

Re: Rust 2024 the Year of Everywhere?

#178

Post by biorach » Fri, Sep 23, 2022, 3:24 PM UTC

woodruffw wrote: post #175

biorach wrote: post #157

Earlier quoted context omitted.

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

The meaning of the operation is not the same, because it is not an operation in Safe Rust.

it's an operation that is not allowed in safe rust. big difference.

Re: Rust 2024 the Year of Everywhere?

#179

Post by taylodl » Fri, Sep 23, 2022, 3:43 PM UTC

pornel wrote: post #177

taylodl wrote: post #169

I'm a software developer with over four decades of experience under my belt in every environment you can imagine - startups, manufacturing company, utility, retail, banking, education - and here's a trend I've noticed in that time: many languages come, a few stick, and they're slow to fade away. Very few have stuck around for decades. Today's darling is tomorrow's pariah. Cobol, C/C++, and Java are great examples of…

According to TIOBE, C has lost 60% of its popularity between 2015 and 2017, and then doubled next year. What's more likely: that a 40-year-old language C had such a massive sudden swing, or that TIOBE data is garbage and measures search engine's algorithms, not language relevance? https://blog.nindalf.com/posts/stop-citing-tiobe/ BTW: According to the TIOBE horoscope Rust is way ahead of TypeScript and Bash.

I don't see the 60% drop in popularity between 2015 and 2017 as you claim (see https://www.tiobe.com/tiobe-index). C has never not been in the top 5 languages used since the index was created 35 years ago. There have been numerous cycles where it's been #1. There's been very little volatility in the top 10 for the past 10 years, as opposed to the 25-50 ranked languages where Rust resides which has considerably more volatility in their rankings. That's why a lot of people consider anything beyond the top 25 to be just noise.

Re: Rust 2024 the Year of Everywhere?

#180

Post by echelon » Fri, Sep 23, 2022, 3:45 PM UTC

mwcampbell wrote: post #176

kibwen wrote: post #119

Earlier quoted context omitted.

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

I figured that working outside the borrow checker meant using unsafe.

Or interior mutability. Or sync+send. Or...

There are lots of ways to shape your solution.