TwentyPosts

> I think Apple by now realizes that Android was a necessary defensive play by Google aimed not at them, but at Microsoft

Huh? Could you elaborate on this? Maybe I am missing some historical context, but it feels like Android is very much eating into Apple's market share, not into Microsoft's. How does this reasoning work out?

Huh. What's the backstory here?

Who or what is SRI?

> They're neutered because they can't suspend and transfer control to a function other than the one that called them ("Note also that "coroutines" here are really "semicoroutines" since they can only yield back to their caller." https://lang-team.rust-lang.org/design_notes/general_corouti...)

Huh? At first glance wanting to do this sounds absolutely insane to me. As in, it sounds a lot like "imagine a function could return not just to its caller function, but to other functions as well! So if you call it, it might be that you won't even end up returning to the same function with which you started, but somewhere completely different".

What am I missing? This sounds absolutely insane at first glance, like a straight-up go-to. What's the most simple use case for these sort of weird yields to other functions?

Huh? Go doesn't use LLVM though, where did you get the idea that it does? That's part of why its compile times are so fast.

Thank you for this nice contribution to HN

>It's pretty widely known that google is bad at c++

No, it's not. This is literally the first time I hear about this. Do you have any sources to support your claim, especially in light of the fact that Google has written and contributed to some of the largest and most important C++ codebases in existence?

You can also just write no code at all if you so desire. It certainly won't cause any memory issues that way. (Hint: What you yourself decide to write or refrain from writing is not the problem. You're not they only person who ever worked on this legacy codebase, and you want guarantees but default, not having to check every line of code in the entire project.)

From what I heard Gemini might be better at translation tasks than GPT4.

I have never used it directly, take what I say with a grain of salt.

As far as I know at least part of the idea was to eliminate the function coloring problem by letting the compiler do some nifty compile-time deductions. This had some issues (I don't know if this is still planned, it seems like the kind of thing that should not work in practice). Additionally, there were all sorts of hard technical issues with LLVM, debugging, etc.

I recommend checking the issue tracker, eg. https://github.com/ziglang/zig/issues/6025

I personally don't understand the domain well enough at all, but honestly, I feel like (if possible) Zig should try to double down on its allocator approach.

Instead of trying to use some compile-time deduction magic explicitly pass around an "async runtime/executor" struct which you explicitly have to interact with. Why not?

I believe what they're trying to get at is related to the following quote from your article:

> This also alleviates the need for considering any sort of question about “what happens if you cancel the cancellation future,” and whether that is recursive or idempotent: once a future begins canceling, “canceling” it again is idempotent, because its already canceling; there is no second future to cancel.

I think the misunderstanding they had is that what you call "async cancellation" requires a second future (which is implicitly constructed from `poll_cancel` or something like that), whose entirely purpose is to run the cancellation code of the first future. If this were the case, then we'd have to ask the question "What happens if the cancellation future is cancelled? Who cleans up after it?"

I don't have enough experience with async Rust in practice yet (sadly), so I was also tripped up when reading at first. I think that you call it "async cancellation" makes people think that it's a separate future, even though (from the type signature of `poll_cancel`) it should be completely clear that it isn't.

Sorry, I hope I got everything right, and that this clears up what I believe to be the misunderstanding for everyone involved!

The borrow checker is really not that big of a deal. It is a hurdle, but the primary issue is just that it's novel and requires you to use different design patterns.

If people get stuck here, it is because they don't understand that the dreaded borrow checker error is (generally) about large, systematic code design patterns, not about local changes.

They try to appease the borrow checker by making small, local changes, which doesn't end up working, since borrow checker issues are about a fundamental issue in the ownership-design of your codebase. Once someone explains this to you, it's really not that hard.

Check out the Q&A in this video to hear it from the man himself, it's the first question: https://www.youtube.com/watch?v=5eL_LcxwwHg

The tl;dr is: "The previous async approach ended up not working, and had to be removed. It's currently an incredibly hard problem with no clear rodemap. The plan is to get there eventually."

To be fair, I ran into a compiler bug in Zig within a few hours of using it. I'd still expect Zig to be a lot less buggy than V, based on what I heard.

Last time I looked at V it just seemed like the language wanted to have it all. No tradeoffs, just "The best parts of Rust and Go" with no explanation how that's remotely achievable (and it wasn't, judging by the attempts to make "auto free" memory management happen, and having to discover first hand that this is not a good approach, and the problem is turing complete).

Feels like we're missing some part of the story here.

Eh. Someone named it after him, and the name stuck. It's a good concept. Why shouldn't he? What does it matter? Who's harmed by this?

Thank you, that article looks quite interesting and I look forward to giving it a proper read.

When I read this, I have to think of a take I heard a few times, namely that "Rust would be better off if the language had opted for a proper effect system from the get go, instead of grafting specialized forms of it onto the language now."

Does anyone have some thoughts on this? I just lack the knowledge to really evaluate that sort of take. There's a lot of discussions on whether async Rust is "good" or "bad", or the right abstraction or not, but it's pretty clear that (at this point) we're more less stuck with it (for better or worse), but that's not what I am asking about.

What I am asking is whether a proper effect system would have genuinely, and legitimately improved or significantly simplified the whole state of Rust async or not, and how. A lot of the async Rust problems sound like "hard" problems, and I'm a bit skeptical that a feature like that would really reduce the "heavy lifting" you have to do.

So you agree with them that it's a problem...?

>which did not work when it came out due to EAC

Nonsense. It worked on the day of release for me, on Linux. I don't know what went wrong on your side, but I played it on release day.

There were two issues, namely:

1. It crashed on start-up roughly half of the time. Not great, but survivable.

2. Swapping to a different workspace (Sway, Wayland) for an extended period of time made the game think your framerate is low, and it forced you to play offline with "FPS unsuitable for online play".

That's all. Other than that, the game experience was buttery smooth.

Well, if you really want to play games then you should just use Linux nowadays.

Not even ironic, I see more issues on Windows nowadays than on Linux. That might say a lot about the games which I play, though.

I assume that "right-wing" and "anti-diversity" are correct labels here, that's not really my problem. It's frankly less about bias, and more about the fact that the Wikipedia article is pretty sparse, and all I could see is the link to Correia's blog.

This is completely disconnected from my own politics, really. I don't need to read articles on how a "right-wing voting campaign got owned at the Hugo awards". That story writes itself. The other side of the story is more interesting.

Is there any summary of what happened from the side of the proponents? Given Wikipedia's track record when it comes to certain topics, it'd be very nice to have some points of comparison here.

I don't know, seems to me like the EU is providing plenty of value to me.

In fact, the EU is making changes that will in fact make it easier for competitors to arise, so I really don't know what you're on about.

This appears to be for "paid subscribers".

Go has panics. You can unwind them, and recover from them. Using these for control flow is heavily discouraged and therefore it's rarely ever an issue, but they are a type of exception handling, or at least very close to that.

Really? The Wikipedia article on trigraphs seems to disagree. Why do you think so?

Wait, no trigraphs anymore???

This is horrible, I loved using `and` and `not` and `or` in C boolean expressions and to pretend I'm writing Python code. It's fun!

This is something much, much more easily learned with your second, or maybe even third programming language rather than with your first.

Thank you, this was a very insightful blog post!