Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust I wanted had no future

graydon2.dreamwidth.org

Post reply on HN
Print view View original

411–420 of 523 posts

Re: The Rust I wanted had no future

#411

Post by pjmlp »

Ygg2 wrote: post #303
pjmlp wrote: post #226

Earlier quoted context omitted.

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).

Yes defaults matter, it doesn't change the fact that protective gear is available, and like seatbelts, helmets and motorrad full body armour, it is up for security conscious people to make do of what is made available to them.

As for your dynamic arguments request, have fun,

https://godbolt.org/z/YYKrnh4Y9

Re: The Rust I wanted had no future

#412

Post by bmacho »

divan wrote: post #261
sph wrote: post #6

Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language. That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I kno…

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…

This was my first (and obviously wrong) mental model of how async works.

There are functions, you can call them sync or async if they handle IO or UI or they will get a necessary data later.

I still don't understand why I can't fetch a URL from top level javascript. Also I don't understand why zig async and await passes the control flow that seemingly total arbitrary way. The naive approach (put async calls in a queue, and periodically check if they are completed or can be executed) seems fast, deterministic, and good enough in every way?

Okay, maybe zig needs the speed, and can't just stop the execution of the sync code time to time to do something else, but why javascript? Maybe javascript async is build upon regular promises and regular objects, instead as a proper language element with proper support in the javascript engines? I don't know. Anyway async as is used with colors is totally against the picture that the words "async" and "await" suggest.

Re: The Rust I wanted had no future

#413

Post by rjbwork »

vips7L wrote: post #203
hadrien01 wrote: post #197

Earlier quoted context omitted.

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.

Isn't this just mostly an issue with mock testing in C#? Developers cargo cult single implementation interfaces because its so hard to mock concrete classes.

>Isn't this just mostly an issue with mock testing in C#

Yes. You have two choices: Interface implemented once, or virtual on all your public members.

I personally think Interface is the sane choice.

Would be nice if the .NET devs let us mock POCO's though...

Re: The Rust I wanted had no future

#414

Post by divan »

joshuamorton wrote: post #400
divan wrote: post #370

Earlier quoted context omitted.

Doesn't matter, donut was just an abstraction. s/eat a donut/make a network request/ Is "network request" a synchronous or asynchronous activity? It depends whether your code blocks and wait's until response (or timeout) or continues executing and handling it when it comes. It's property of the "attention" of the caller, not of activity itself.

But "can be gracefully executed asynchronously" is a property of an action. Something that pegs the CPU to 100% because it's doing intense processing isn't a good candidate for async. Similarly, some code can cause issues when written in a non-streaming fashion. Take the following example (in python): x = [x for x in range(1_000_000_000)] y = (x for x in range(1_000_000_000)) If you spawn a bunch of async workers doi…

Hmm, is it a post-factum rationalization or it's the original logic behind async/await? Let's mark "heavy" functions with a label, so user has to call them differently not to overload the system?

Even if this is an original logic, why language is deciding for me what is considered heavy or not? What if I'm fully aware that I'm doing heavy processing and I want it to be happening in the background. What if I'm writing HFT software and every call is heavy for me. Language is not a right level of abstraction of marking "heaviness" of the code.

It really just doesn't make sense. Why stop there and not start marking functions with how many times per second they can be called? Like you can call "light" function 100 trillion times per second and OOM the system, so let's mark it "func light() async 2_times_per_second {}". It only can be called from functions that have lower per second label.

Plus, if Python cares so much about not OOM-ing the system I would start by not requiring 32-bit int to occupy 28 bytes in the first place.

Re: The Rust I wanted had no future

#415

Post by worik »

> basically every language discovers the long way that financial math is special and, at great length, eventually adds a decimal type.

And every case it is wrong

Financial math is not hard when you know how

Use integer types not horrific cludges like "decimal"

Just because IBM did it does not make it right. It is wrong

Re: The Rust I wanted had no future

#416

Post by wizofaus »

divan wrote: post #370
paulddraper wrote: post #324

Earlier quoted context omitted.

IDK about donuts. But consider a network request. The vast majority of the time is not spent in the CPU. Right?

Doesn't matter, donut was just an abstraction. s/eat a donut/make a network request/ Is "network request" a synchronous or asynchronous activity? It depends whether your code blocks and wait's until response (or timeout) or continues executing and handling it when it comes. It's property of the "attention" of the caller, not of activity itself.

It's only functions that "block and wait" that it makes sense to be async - the point being that blocking and waiting doesn't use up CPU cycles, so you might as well free the thread up to do other stuff. If a function issues a socket write, then continues utilising the CPU while also periodically checking if data's available to read, it's effectively doing manually what async does for you, though I'm not sure there are too many real life examples of such functions. But pre-async it was certainly common enough for block-and-wait functions to tie up a thread and hence execution of programs with limited multi-threading (even today, GUIs often require all events and updates to be processed on the primary thread).

Re: The Rust I wanted had no future

#417

Post by worik »

dmm wrote: post #237
pjmlp wrote: post #226

Earlier quoted context omitted.

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.

Someone much more insightful than me pointed out that most of the safety advantages of Rust are really a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day but when building systems and libraries with Rust, people value safety and Rust enables that as a priority.

> a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day

Yes you could. But I do not think " cultural" is the right term for not putting all your code in an `unsafe` block

Re: The Rust I wanted had no future

#418

Post by pjmlp »

hajile wrote: post #322
jjtheblunt wrote: post #146

Earlier quoted context omitted.

Have you dismissed F# ?

The rest of the world has. If you're going to use .net, there's almost zero chance that you'll get permission to use F#. For whatever reason, C# devs seem incredibly resistant to even just looking at F#.

Do you want reasons? Here are a couple from someone that has learned ML with Caml Light, and most of the latter ML variants.

VS Tooling lacking versus C#/VB, no support for code generators, no support for Roslyn, no support for GUI frameworks, no support for EF tooling, many .NET vendors don't support projects if using F#, community likes to create their own wrappers instead of embracing standard .NET projects, ....

Re: The Rust I wanted had no future

#419

Post by pas »

kaba0 wrote: post #49
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…

Virtual threads (like java’s loom, erlang’s and goroutines) are arguably that. In case of java there really is no compiler magic even, “just” runtime magic.

how big is the overhead for this? and how much easier is working with virtual threads than Rust's async?

Re: The Rust I wanted had no future

#420

Post by dexwiz »

paulddraper wrote: post #325
marcosdumay wrote: post #300

Earlier quoted context omitted.

Almost all high-level languages have builtin containers. I do think it's a bad fit for Rust (at least for what Rust became), but it's not the end of the world by itself. The fact that JS has about 3 of them (is it only 3? I'm not sure of this), with different interfaces, and non-usual behavior is what creates problem there. But other languages quite successfully make their own containers either different enough or si…

Array Map Set WeakMap

TypedArrays are also their own thing. But unless you are reading binary files/WASM, most JS devs don't use them.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

Post reply on HN