awused

6 ms·

1.
by awused 3y ago
> 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 metada
2.
by awused 3y ago
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. Ownership as
3.
by awused 3y ago
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 concurrent m
4.
by awused 3y ago
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 waste of ti
5.
by awused 3y ago
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 unless it r
6.
by awused 3y ago
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 your head,
7.
by awused 3y ago
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, that
8.
by awused 3y ago
>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 be
9.
by awused 3y ago
>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 between t
10.
by awused 3y ago
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-cos
11.
by awused 3y ago
"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 causes no
12.
by awused 3y ago
>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 tasks with LocalSe
13.
by awused 3y ago
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.
14.
by awused 3y ago
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 runtimes and s
15.
by awused 3y ago
> 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 returning it at all was
16.
by awused 3y ago
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 being wrong. T
17.
by awused 3y ago
> 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 ret
18.
by awused 3y ago
> 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 explicitly docume
19.
by awused 3y ago
> 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 true or
20.
by awused 3y ago
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 alleged tangent was relev
21.
by awused 3y ago
> 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 a
22.
by awused 3y ago
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 idiomatic
23.
by awused 3y ago
> 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, exists. > more base
24.
by awused 3y ago
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 loudly. You
25.
by awused 3y ago
>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 time. Go shouldn&
26.
by awused 3y ago
> Most notably, you can derive meaning from its nil-ness. This is sophistry. If I try to "use" a nil pointer I get a crash. I have to carefully check that it's non-null even if error is null. You can "derive" th
27.
by awused 3y ago
I think most of the stuff in this repo is too much and trying to beat a square peg into a round hole, but the little things like Option and Either patch a hole in Go. I don't think I'd use them without them being in the stdlib, th
28.
by awused 3y ago
Yeah, there are counterexamples, but the only way to know is to read the comments or source code of the function you're calling. (T, err) doesn't convey any useful information and, in the overwhelming majority of cases, err != nil
29.
by awused 3y ago
This is nonsense. This isn't about idiomatic Go or not, there is only one way to do things in Go, so a function doing things in that one way doesn't communicate anything to the caller. If you try to open a file, and the file doesn
30.
by awused 3y ago
It's not just cross-platform programs that suck. Applications moving to gtk4 from gtk3 add an extra 100-200ms of startup latency every time because of OpenGL initialization and shader compilation (there is currently no cache), varying

More ›