>It's the problem with classical stage-oriented compilers. A compiler designed for diagnostics from the beginning I'm not sure any compiler, even one "designed for diagnostics," can gather the "necessary metadata" from…
Honestly I found myself coding very much the same way in Rust as I did in Python and Go, which were my go-to hobby languages before. But instead of "this lock guards these fields" comments, the type system handles it.…
Lifetimes and borrowing are very much a correctness thing and aren't just for tracking when memory is freed. While you won't have use-after-free issues in a GCed language, you will still have all the other problems of…
Honestly I assumed you had read the article and were just confused about how tokio was pretending to have preemption. Now you reveal you hadn't read the article so now I'm confused about you in general, it seems like a…
Actually, no, I misread it trying to make sense of what you were posting so this post is edited. This is just mundane non-blocking sockets. If the socket never needs to block, it won't yield. Why go through epoll/uring…
Are you sure about that? >Rust embraces abstractions because Rust abstractions are zero-cost. So you can liberally create them and use them without paying a runtime cost. >you never need to do a cost-benefit analysis in…
You're confusing IO not happening because it's not needed with IO never happening. Just because a method can perform IO doesn't mean it actually does every time you call it. If I call async_read(N) for the next N bytes,…
>This sort of design solves the problem for any case of "My task that is performing I/O through my runtime is starving my other tasks." Yeah, there's your misunderstanding, you've got it backwards. The problem being…
>Trying to solve the problem by frequently invoking signal handlers will also show in your latency distribution! So just like any other kind of scheduling? "Frequently" is also very subjective, and there are tradeoffs…
The way you used it in your parent comment didn't make it clear that you were using it properly, hence my clarification. I'm honestly still not sure you've got it right, because Rust abstractions, in general, are not…
"Zero-cost abstractions" can be a confusing term and it is often misunderstood, but it has a precise meaning. Zero-cost abstractions doesn't mean that using them has no runtime cost, just that the abstraction itself…
>but Tokio forces all of your async functions to be multi thread safe While there are other runtimes that are always single-threaded, you can do it with tokio too. You can use a single threaded tokio runtimes and !Send…
You don't even need other runtimes for this. Tokio includes a single-threaded runtime and tools for dealing with tasks that aren't thread safe, like LocalSet and spawn_local, that don't require the future to be Send.
There's nothing buggy about a future that never yields because it can always make progress, but people prefer that a runtime doesn't let all other execution get starved by one operation. That makes it a problem that…
>You are right. I concede nil is not useful. You say this sarcastically, but it is actually true. A nil pointer is not useful. Once you have determined that a pointer is nil, you have confirmed that the function…
You are now claiming that they are useful when you must discard them as useless when the error is non-nil. At least with you being caught in such a plain and clear lie I can be done with this. >I love nothing more than…
>No, it is very much written from a consumer perspective. We're talking about from the producer perspective. This is just a lie. It's written about Go and doesn't split its perspectives, the producer should only ever…
>Yes, it says you cannot trust functions, unless documented, to be idiomatic. That is not what it says, in fact, it almost says the opposite. It is idiomatic Go to never return useful values if error is non-nil unless…
>Based on what? ... In fact, Go Proverbs even says so. And the Go style guide says otherwise: if err is non-nil, you shouldn't even check the other return values. The Go proverbs are just words, it doesn't make them…
Since you seem unwilling or unable to follow an argument you started this seems more like an attempt to bait a response that you can report to the mods instead of an honest conversation. If you want to know why the…
>Go Proverb #5: Make the zero value useful. Yeah, it's a nice quip, but that's all it is. It sounds nice on first read to someone who doesn't program much. But it is inaccurate and not followed by Go, and is explicitly…
So you've defined idiomatic Go code in your own way, that no one else's definitions match with, such that no idiomatic Go code actually exists. If no idiomatic Go code exists, then it's definitionally true that all…
>whatever haphazardly written Go code you happened to find Well, if the Go stdlib is haphazardly written and unidiomatic then I think the burden is on you to demonstrate that idiomatic Go, as per your definition,…
I recommend you read your own posts sometimes. Your claim of "in Go values must always be useful" was rebutted multiple times. That you're trying to move the goalposts to something neither of us was arguing speaks…
>As you explain yourself, they cannot be equivalent representations. That's the point. They are not equivalent, they represent different things, and Either is a better fit for the actual code even in Go most of the…
>It's the problem with classical stage-oriented compilers. A compiler designed for diagnostics from the beginning I'm not sure any compiler, even one "designed for diagnostics," can gather the "necessary metadata" from…
Honestly I found myself coding very much the same way in Rust as I did in Python and Go, which were my go-to hobby languages before. But instead of "this lock guards these fields" comments, the type system handles it.…
Lifetimes and borrowing are very much a correctness thing and aren't just for tracking when memory is freed. While you won't have use-after-free issues in a GCed language, you will still have all the other problems of…
Honestly I assumed you had read the article and were just confused about how tokio was pretending to have preemption. Now you reveal you hadn't read the article so now I'm confused about you in general, it seems like a…
Actually, no, I misread it trying to make sense of what you were posting so this post is edited. This is just mundane non-blocking sockets. If the socket never needs to block, it won't yield. Why go through epoll/uring…
Are you sure about that? >Rust embraces abstractions because Rust abstractions are zero-cost. So you can liberally create them and use them without paying a runtime cost. >you never need to do a cost-benefit analysis in…
You're confusing IO not happening because it's not needed with IO never happening. Just because a method can perform IO doesn't mean it actually does every time you call it. If I call async_read(N) for the next N bytes,…
>This sort of design solves the problem for any case of "My task that is performing I/O through my runtime is starving my other tasks." Yeah, there's your misunderstanding, you've got it backwards. The problem being…
>Trying to solve the problem by frequently invoking signal handlers will also show in your latency distribution! So just like any other kind of scheduling? "Frequently" is also very subjective, and there are tradeoffs…
The way you used it in your parent comment didn't make it clear that you were using it properly, hence my clarification. I'm honestly still not sure you've got it right, because Rust abstractions, in general, are not…
"Zero-cost abstractions" can be a confusing term and it is often misunderstood, but it has a precise meaning. Zero-cost abstractions doesn't mean that using them has no runtime cost, just that the abstraction itself…
>but Tokio forces all of your async functions to be multi thread safe While there are other runtimes that are always single-threaded, you can do it with tokio too. You can use a single threaded tokio runtimes and !Send…
You don't even need other runtimes for this. Tokio includes a single-threaded runtime and tools for dealing with tasks that aren't thread safe, like LocalSet and spawn_local, that don't require the future to be Send.
There's nothing buggy about a future that never yields because it can always make progress, but people prefer that a runtime doesn't let all other execution get starved by one operation. That makes it a problem that…
>You are right. I concede nil is not useful. You say this sarcastically, but it is actually true. A nil pointer is not useful. Once you have determined that a pointer is nil, you have confirmed that the function…
You are now claiming that they are useful when you must discard them as useless when the error is non-nil. At least with you being caught in such a plain and clear lie I can be done with this. >I love nothing more than…
>No, it is very much written from a consumer perspective. We're talking about from the producer perspective. This is just a lie. It's written about Go and doesn't split its perspectives, the producer should only ever…
>Yes, it says you cannot trust functions, unless documented, to be idiomatic. That is not what it says, in fact, it almost says the opposite. It is idiomatic Go to never return useful values if error is non-nil unless…
>Based on what? ... In fact, Go Proverbs even says so. And the Go style guide says otherwise: if err is non-nil, you shouldn't even check the other return values. The Go proverbs are just words, it doesn't make them…
Since you seem unwilling or unable to follow an argument you started this seems more like an attempt to bait a response that you can report to the mods instead of an honest conversation. If you want to know why the…
>Go Proverb #5: Make the zero value useful. Yeah, it's a nice quip, but that's all it is. It sounds nice on first read to someone who doesn't program much. But it is inaccurate and not followed by Go, and is explicitly…
So you've defined idiomatic Go code in your own way, that no one else's definitions match with, such that no idiomatic Go code actually exists. If no idiomatic Go code exists, then it's definitionally true that all…
>whatever haphazardly written Go code you happened to find Well, if the Go stdlib is haphazardly written and unidiomatic then I think the burden is on you to demonstrate that idiomatic Go, as per your definition,…
I recommend you read your own posts sometimes. Your claim of "in Go values must always be useful" was rebutted multiple times. That you're trying to move the goalposts to something neither of us was arguing speaks…
>As you explain yourself, they cannot be equivalent representations. That's the point. They are not equivalent, they represent different things, and Either is a better fit for the actual code even in Go most of the…