The Rust I wanted had no future • Hacker News Board

Re: The Rust I wanted had no future

#491

Post by kzrdude » Tue, Jun 06, 2023, 12:25 PM UTC

krupan wrote: post #463

kzrdude wrote: post #404

Earlier quoted context omitted.

Is there a practical issue with this, or is this more philosophical?

I'm not parsing expert, but being hard to parse makes it harder to write tools that work with the language. Personally I find rust to be not easy at all for humans to read, and so it's interesting that it's also hard for parsers to parse. Not sure what was optimized for in the design.

I've coded a moderate amount in Rust since it was born, I think the prevailing rustfmt style is too bent towards machine-perfect neatness (one example: function definitions are split so that every parameter has a new line).

This machine perfect neatness comes from lots of small places in the syntax where Rust decided let's make the syntax permissive so that it's easy to autogenerate code with some macro or to make good diffs.

Then a systematic implementation of trailing commas and allowing leading/trailing separators in some places. The result is quite sterile and to me is no longer organically nicely readable.

tldr: rustfmt has no soul

Re: The Rust I wanted had no future

#492

Post by rowls66 » Tue, Jun 06, 2023, 1:04 PM UTC

hadrien01 wrote: post #197

zamalek wrote: post #168

Earlier quoted context omitted.

C# is horribly OOP. I use it in my day job, and the frameworks wield OOP overcomplexity proudly. It has likely gone beyond Java as the posterchild for OOP: interfaces that are implemented once, classes that are instantiated once. You can't get away from it either, it is practically part of the stdlib and everyone cargocults it. Rust is imperative too, though.

The language doesn't push you towards interfaces implemented once, but many developers indeed persist doing it for no reason at all. With proper code review we're able to make that practice go away on the projects I'm working on.

I have seen way too much of interfaces implemented once in Java, and have argued against it unsuccessfully many times. I am not working in Go, and see the same.

Re: The Rust I wanted had no future

#493

Post by divan » Tue, Jun 06, 2023, 1:20 PM UTC

lmm wrote: post #456

divan wrote: post #261

Earlier quoted context omitted.

It's crazy that the programming community even accepted the concept of async/await as a sane one. Being sync or async is essentially a property of the attention of the caller, not of the action itself. Is "eating a donut" a sync or async action? If I'm focusing all my attention on it, essentially putting all tasks aside (after) - then it's a synchronous action. If I'm reading a book/watching a video/walking/etc, whil…

Does blocking I/O or not is very much a property of the function itself, as is "may finish up running on a different thread from the one it started on" (or, if you prefer, "needs to be run under a runtime that provides that capability"). Sending a letter and getting a reply is an inherently async action; you can stare at the mailbox all day but you probably don't want to. Waiting in line at the bank is inherently syn…

> you can stare at the mailbox all day but you probably don't want to

Yet, it's up to me to decide, not to the mailbox.

Re: The Rust I wanted had no future

#494

Post by sdfghswe » Tue, Jun 06, 2023, 1:23 PM UTC

codedokode wrote: post #488

sdfghswe wrote: post #374

Earlier quoted context omitted.

What's the alternative? What would you expect happens?

Panic so that the invalid value doesn't get stored into the database or somewhere else. The developer then would notice the problem and fix it. Silently using invalid value is the worst choice.

Pardon my ignorance, but what does "panic" mean, specifically?

Re: The Rust I wanted had no future

#495

Post by belmont_sup » Tue, Jun 06, 2023, 2:21 PM UTC

mjmahone17 wrote: post #170

belmont_sup wrote: post #135

Earlier quoted context omitted.

Algebraic effects like how OCaml’s now implementing it may be possible! The ecosystem around effects in OCaml is still really young, but here’s an example of an http request being made that is asynchronous, non-blocking but looks synchronous with no special syntax. https://github.com/mirage/ocaml-cohttp/blob/16e991ec1f7e5f0c... Performing these effects is similar to throwing exceptions up the callstack where whicheve…

As someone who likes OCaml, but hasn’t touched OCaml in ~5 years, that’s a very hard example to read. I can tell it’s making a network request, but I have no clue: - what the type of res is (is it a string? A buffer? Async string? Something else?) - how this code does not block: what is happening in parallel? At which point will it block? I would like to be excited about OCaml’s algebraic effects, but right now I don…

Yawar’s explained it all, but I’ll share tidbits of my own.

When reading ocaml on _text_ like from GitHub, I personally accept that I won’t need to know the type and underlying data structures just yet unless I read and have open the .mli file.

I’m excited first and foremost because we can have async code feel synchronous like Go.

How does the code run? IO runtime is defined in userland, like Rust’s Tokio. That’s the “Eio_main.run” part. Underneath, eio spins up and manages processes in a non blocking manner, even scheduling work.

Since effects are essentially resumable exceptions, this particular http request throws an effect to the runtime. The logic and this particular process pauses (okay I may be wrong here). Logic flow now continues somewhere in our runtime level (the effect handler), where all the async IO work happens. The runtime resumes the child process and returns the http result back to the child via a “delimited continuation”.

Re: The Rust I wanted had no future

#496

Post by belmont_sup » Tue, Jun 06, 2023, 2:29 PM UTC

ohgodplsno wrote: post #48

sph wrote: post #22

Earlier quoted context omitted.

I disagree. You can call an async function in Rust from a regular one, that's true, but the returned value still needs to be passed through an executor to be useful. Async without function coloring means being able to call `async fn add(a, b: usize) -> usize` from anywhere and having an usize back, whether you're calling from a regular or async function. If you need slightly different logic because of async, you got…

Not knowing about function coloring is a stupid dream and has terrible implications on the performance of your code, which is infinitely more important than you losing 2 minutes having to figure out that you really want to `runBlocking { callThatBlocksForADamnLongTime() }`. The insight that function coloring gives you is terribly important. Roman Elizarov (of Jetbrains, author of Kotlin and lead on Kotlin Coroutines)…

I agree that hiding coloring entirely is really a trap. I want to know when some IO work runs because it means potential exceptions unknown with unpredictable latency in my program.

As a design choice of OCaml’s eio - an async runtime, you must pass around a dependency to all your IO functions. With the “net” object passed visible in my function type signature, I can tell some network work may occur. The first benefit is we get synchronous Go-like code.

Re: The Rust I wanted had no future

#497

Post by badrequest » Tue, Jun 06, 2023, 2:58 PM UTC

steveklabnik wrote: post #279

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?

(Not your parent) Many people point to more advanced meta programming, such as variadrics, higher kinded types (though as mentioned GATs advance Rust in this general area), and specialization.

Steve, your comments are always a welcome surprise, I hope all is well with you and yours. :)

Re: The Rust I wanted had no future

#498

Post by FpUser » Tue, Jun 06, 2023, 3:18 PM UTC

steveklabnik wrote: post #464

FpUser wrote: post #448

Earlier quoted context omitted.

for some reason I can not answer your subsequent reply so I do it here: I looked at your example and played a bit with it and yes I agree with you - compiler does help in this case. My old text: So instead of checking if vector is not empty you check that the return result is not empty. I do not see much difference. If Rust compiler would choke when "else" clause in your example is not present I would understand your…

> for some reason I can not answer your subsequent reply so I do it here Hacker News will try and discourage really quick back and forth comments. To do so, the reply button is hidden. However, if you click on the timestamp, to go to the comment's own page, you can reply there.

Thanks for the tip. Did not know it

Re: The Rust I wanted had no future

#499

Post by Lk7Of3vfJS2n » Tue, Jun 06, 2023, 4:35 PM UTC

steveklabnik wrote: post #393

Lk7Of3vfJS2n wrote: post #355

Has Rust gone beyond the point of no return? Have less elegant features possibly been embedded in the language that have put Rust on the track to never become the hypothetically perfect or unblemished language?

The answer to your second question is "yes" for every single language that's ever been made or will be made.

Are you saying a hypothetically perfect language is unattainable? Why? Is there proof for this?

Re: The Rust I wanted had no future

#500

Post by fzeindl » Tue, Jun 06, 2023, 5:44 PM UTC

singingboyo wrote: post #444

fzeindl wrote: post #401

Earlier quoted context omitted.

> I think you're manifesting what I'm talking about. The reason you cannot replace async with threads has nothing to do with the ecosystem, but the simple fact that threading is a model of parallelism and async/await is a model of concurrency. That is an artificial distinction you made up. I have written many apps and desktop applications, all of which where using 3-10 threads, some of them doing "parallel" work mean…

It's not an artificial distinction at all, but it is subtle. 2, 4, even 256 sockets exchanging data can be worked with concurrently on a single thread and gain performance vs blocking and waiting for the first socket to finish. There's no parallelism, since they're never actively reading/writing at the same time, but they're concurrent because they exist and operate in overlapping timeframes. Running two independent…

They should have fixed the overhead of Threads instead of changing the languages. Fibers/virtual threads eliminate this overhead, Java can run millions of them.