The Rust I wanted had no future • Hacker News Board

Re: The Rust I wanted had no future

#301

Post by TremendousJudge » Mon, Jun 05, 2023, 4:12 PM UTC

badrequest wrote: post #253

dataflow wrote: post #244

Earlier quoted context omitted.

> Rust ending up as a replacement C++ helped it If anything, it's more a C replacement than a C++ replacement. It will take some market share from both of course (and other languages to a lesser extent too), but functionality-wise, it just isn't (currently, at least) practically able to replace some C++ use cases.

I'm interested in more on this. What can I do in C++ that I can't do in Rust?

Write unsafe code wrapped in layers of those advanced features that half the team didn't even know existed, and push it into production.

Re: The Rust I wanted had no future

#302

Post by zozbot234 » Mon, Jun 05, 2023, 4:16 PM UTC

logicchains wrote: post #271

chrismorgan wrote: post #158

Earlier quoted context omitted.

Are you aware of generic associated types , which landed in 1.65 (late last year)? To a considerable extent, they’re Rust’s answer to higher-kinded types. Less expressive in some ways, but fitting Rust way better, as basically a relaxation of a former restriction, rather than a new feature. If I’m reading your snippet right, GATs let you express exactly that, though minus `template`’s duck-typiness so you’d have to s…

>less expressive in some ways, but fitting Rust way better, as basically a relaxation of a former restriction, rather than a new feature They're not expressive enough to implement a monadic async library, as far as I'm aware, so they don't fulfill the role of proper HKTs in this context. >minus `template`’s duck-typiness so you’d have to spell out what contract the container must adhere to. Do you think it's consiste…

> They're not expressive enough to implement a monadic async library, as far as I'm aware

AIUI you need GC in order to do that. There's a reason why Rust's async/await support needs compiler magic.

(I'd like to see standard interfaces for "pluggable" garbage-collected arenas in Rust, but this will need to wait until after Allocators/Storages get fully stabilized.)

Re: The Rust I wanted had no future

#303

Post by Ygg2 » Mon, Jun 05, 2023, 4:16 PM UTC

pjmlp wrote: post #226

Ygg2 wrote: post #17

Earlier quoted context omitted.

Performance, but with sanity. Say you use a vector in C++. You push one element and pop two. In Rust that's a None. In C++ the answer is UB (in my case 43).

In C++ it is an error, if one bothers to enable bounds checking. https://godbolt.org/z/vYcMhE9h7 > Error: attempt to access an element in an empty container.

It's not an error by default and more importantly it's not an error under right circumstances (e.g. lets say number of pops and inserts is supplied via arguments).

Re: The Rust I wanted had no future

#304

Post by Ygg2 » Mon, Jun 05, 2023, 4:19 PM UTC

FpUser wrote: post #200

Ygg2 wrote: post #17

Earlier quoted context omitted.

Performance, but with sanity. Say you use a vector in C++. You push one element and pop two. In Rust that's a None. In C++ the answer is UB (in my case 43).

And what should be defined behavior? There are quite a few choices that depend on particular situations. Feature designers have no knowledge about what would you want so they left it up to application programmer to check the situation upfront and act accordingly to their wishes. If you want same behavior across the whole application you can always write generic function doing just that.

Return either value or an EMPTY placeholder. Look Java did it. It returns a nullable value or Optional.

Re: The Rust I wanted had no future

#305

Post by vanderZwan » Mon, Jun 05, 2023, 4:19 PM UTC

TremendousJudge wrote: post #301

badrequest wrote: post #253

Earlier quoted context omitted.

I'm interested in more on this. What can I do in C++ that I can't do in Rust?

Write unsafe code wrapped in layers of those advanced features that half the team didn't even know existed, and push it into production.

Am I the only one who works at a place where things don't make it into production unless at least one other person on the team fully understands the code during review?

Re: The Rust I wanted had no future

#306

Post by olalonde » Mon, Jun 05, 2023, 4:23 PM UTC

> Explicit lifetimes

I never understood that one either. There is always only one "solution" that will make your program compile, so why not just let the compiler figure it out?

Re: The Rust I wanted had no future

#307

Post by marcosdumay » Mon, Jun 05, 2023, 4:25 PM UTC

kaba0 wrote: post #212

LinXitoW wrote: post #134

Earlier quoted context omitted.

To me, one thing missing from most popular web languages is the single best part of Rust: A well-defined handling of the non-happy path. I'm talking about things like exhaustive "switches", built-in, ENFORCED handling of "missing" values (null, undefined), and finally useful error handling. I actually don't need any of the baremetal features of Rust. It's just that most of it's "zero-cost" abstractions are still far…

Haskell, Scala, F#, OCaml. (Some dislike it, but Java’s checked exceptions are exact homologous of result types)

The problem with Java exceptions is that they have very poor generic support.

Outside of that, yeah they just differ in very low-level aspects that most developers don't even know about.

Re: The Rust I wanted had no future

#308

Post by hgomersall » Mon, Jun 05, 2023, 4:25 PM UTC

ninkendo wrote: post #228

hgomersall wrote: post #220

Earlier quoted context omitted.

So don't use it. Why object to those that do have a use case for it?

Because it's possible the crate you want to use, uses it.

Or alternatively the crate you want to use doesn't exist.

Re: The Rust I wanted had no future

#309

Post by tomjakubowski » Mon, Jun 05, 2023, 4:27 PM UTC

Freedom2 wrote: post #274

duped wrote: post #255

Earlier quoted context omitted.

Developers should learn the difference between concurrency and parallelism because async isn't equivalent to threading.

Yep, it's pretty alarming that a developer would toss away async when threading isn't a fit for all situations - what happened to the right person tool for the job? As a professional, I 'hate' some things too, but I'm not going to blindly make my work harder and less efficient out of some small preference I have.

async has fragmented the crates ecosystem. If you want to want to write async-free code with threads, you'll probably still have to opt-in to an async executor for some dependency because these days many libraries will implement only an async interface

Re: The Rust I wanted had no future

#310

Post by junon » Mon, Jun 05, 2023, 4:28 PM UTC

> I was weirdly focused on [the Actor] model that in practice has many issues

I maintain the actor model is probably the most theoretically perfect concurrency and distributed computing model. The holy grail. We just don't have the right hardware for it and it's extremely limited by addressability issues with current technology.

So I don't really find this surprising, nor disagreeable. It's just not a model that Works Well at present.