Live data from Hacker News

Rust 2024 the Year of Everywhere?

smallcultfollowing.com

191–200 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#191

Earlier quoted context omitted.

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

How does this work? I want to wrap POSIX semaphores. You call sem_init, passing it the address of an int; later you call sem_destroy and pass it the same address. So the location of the int must not change. In C++ you would delete the move constructor: struct sema { int v; void sema(sema &&) = delete; }; In Rust you might try this, but it doesn't work: struct Sema { v: Pin , } there is no way to create a "Pin ". The…

> there is no way to create a "Pin"

Caveat, I haven't worked with Pin that much. Take this with a grain of salt.

My understanding is - you really shouldn't put copyable stuff in Pin. Period. If you want something like that wrap i32 in new struct and declare it !Unpin. Since negative traits are unstable, you just write PhantomPinned marker

   struct NonPinI32 {
       v: i32,
       non_pin: PhantomPinned,
   }

Re: Rust 2024 the Year of Everywhere?

#192
post #182

Earlier quoted context omitted.

The Ratings % line for C: Nov 7 2015 = 17.15%, Aug 2 2017 = 6.48% C# has jumped from 0.77% in Mar 2020 to 4.75% in Apr 2022. One month, 6x increase. Even if you just take relative rankings, they're also total nonsense: TypeScript is 40th, behind Prolog, Visual Fox Pro, Dart, and Rust.

Yeah, that's why many people treat everything beyond the top 25 as noise. There's a lot of churn there.

TypeScript is the 8th most popular language according to Redmonk. TIOBE has issues even in the top 10, and +/- 60% errors bars on their top 2 language!

It's not a problem of noisy data for the long tail languages. It's just wrong data. It's a poor unstable proxy (subject to proprietary query interpretation and anti-spam algorithms that vary over time, query terms don't reflect colloquial names, and name mentions aren't usage), and it's a misrepresentation of the data (searches include historical documents, which is not a reflection of current usage). It's all noise, no signal.

Re: Rust 2024 the Year of Everywhere?

#193

Earlier quoted context omitted.

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

How does this work? I want to wrap POSIX semaphores. You call sem_init, passing it the address of an int; later you call sem_destroy and pass it the same address. So the location of the int must not change. In C++ you would delete the move constructor: struct sema { int v; void sema(sema &&) = delete; }; In Rust you might try this, but it doesn't work: struct Sema { v: Pin , } there is no way to create a "Pin ". The…

pin is purely a property of a pointer, so Pin doesn’t make sense.

While you’re right that Box gives you a stable address, you can still move out of a Box, or swap something into the Box. Pin> prevents that.

Re: Rust 2024 the Year of Everywhere?

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

That's just the most obvious smell. But this also happens if you start passing indices around, using them much like unchecked pointers.

Re: Rust 2024 the Year of Everywhere?

#195

Earlier quoted context omitted.

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.

What I mean is just fix that so it works. If you have split stacks the one for data doesn't have to track function call chains. The advantage of using analysis tools is you only pay for that once. Not with every compile. And the tools are smarter than Rust. You also don't have safe vs unsafe code like you do with Rust.

You wouldn't just need split stacks for this, you'd need a spaghetti stack with some kind of heap allocation for frames. At which point perf goes out of the window already.

Re: Rust 2024 the Year of Everywhere?

#196
post #109

Earlier quoted context omitted.

> if users of Rust on GCC don't have easy access to Cargo. Can you clarify which users you mean? If you mean the developers of GCC-Rust, they don't need Cargo because GCC-Rust is written in C++. And users of GCC-Rust would have no problem using Cargo, assuming that GCC-Rust presents a CLI interface that's more-or-less compatible with rustc (which I assume they would want to do, because being compatible with the exist…

People who use GCC to compile Rust code presumably will not use "cargo build" to build their programs, and presumably may not have "cargo" in their toolchains at all. They may have cmake or bazel instead, with manually-selected libraries. Perhaps you never envisioned that people would want to compile large rust programs without cargo being involved in the build flow? Cargo, NPM, Pip, and other package managers presen…

But, conversely, why should someone take a risk of stabilizing a piece of fluff that nobody actually claims? It's not just that this wastes their time - those standards will be for us for decades to come. Just look at the mess that is POSIX by now.

Re: Rust 2024 the Year of Everywhere?

#197

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…

> My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. If what you said was true, JavaScript itself should have been replaced by something simpler, which didn't happen. My theory is that when some technology is good enough, it gets stuck. The previous JavaScript tools got replaced because they were not good enough.

That doesn't explain why the replacement stuff keeps going in circles so persistently, though.

Re: Rust 2024 the Year of Everywhere?

#198

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…

I broadly agree with you that there are many fads in the industry that are touted as the "next big thing" only to fade into obscurity a decade later. But I don't think Rust is one of those, and the reason doesn't even have anything to do with what the language can or cannot do.

No, it's because all the big players in the industry are very involved. So, on one hand, it's not one company's pet project, like Java was - and yet it's big enough that "no-one ever got fired for buying IBM" kind of reasoning is already starting to show up. And I don't think anyone is likely to back out at this point given the effort already spent. For better or worse, this is what we've bet the industry on.

(To be clear, I think the language is actually great by itself, and it's good to see something striving to be safe-by-default to fill that spot in the industry. But let's not fool ourselves when it comes to programming languages winning on some abstract merits, outside of the broader economic context.)

Re: Rust 2024 the Year of Everywhere?

#200
post #125

Earlier quoted context omitted.

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.

But Go can’t be used for all low level programming. Of course a GCed language is easier to read, it’s simpler at the cost of performance. Rust complexity is more of a debate about low level programming below Go. Where only C/C++ and Rust exist. Can there be a simpler language in that space?

There are far more languages in that space than just C and Rust. Zig is one of the more recent examples, but e.g. Ada is also around, as is Delphi and many others.
Post reply on HN