sapiogram

Thank you, the comment has value now.

Haters gonna hate. If you're working on a project that needs performance and correctness, nothing can get the job done like Rust.

My feelings exactly. Go was particularly disappointing, it promised everything but only felt like a sidegrade from Java. Screw it, a downgrade, until go errors get stack traces.

Interesting, got any links to more information?

It's the exact same on Linux.

That was absolutely not true in the "early 2010s", not even 5 years ago unless you wanted to seriously compromise on some other aspect of the display.

This issue happens without any scaling at all, on both Linux and MacOS.

It's not, the font renderer just sucks outside of high-DPI displays.

Yes yes, all your friends are rich, good for you.

If that was true, it would be very nice if they just acknowledged that...

I don't know the internals of Zed well, but it seems entirely plausible they're doing text rendering from scratch.

It's not an issue on high-DPI screens. Try again with an external monitor. It's much worse on light mode.

Thank you, I bring this up in every Zed thread on the internet, hopefully the devs will eventually fix it. Until they do, Zed is simply unusable on regular-DPI displays, at least in light mode. See these screenshots:

Example Zed screenshot, using "Ayu Light": https://i.ibb.co/Nr8SjvR/Screenshot-from-2024-07-28-13-11-10...

Same code in VS Code: https://i.ibb.co/YZfPXvZ/Screenshot-from-2024-07-28-13-13-41...

This comment is incorrect, I have tried the editor on both MacOS and Linux, and texts looks like crap on both if you're using your screen at its native resolution. The difference is easily visible in screenshots.

Example Zed screenshot, using "Ayu Light": https://i.ibb.co/Nr8SjvR/Screenshot-from-2024-07-28-13-11-10...

Same code in VS Code: https://i.ibb.co/YZfPXvZ/Screenshot-from-2024-07-28-13-13-41...

No, I think Youtube really is the product. With Premium, you don't see any ads (at least the ones Youtube makes money from), and there's no way "tracking" makes them anywhere near as much money as a simple premium subscription.

Ah, good to know the other side is now throwing out voter fraud accusations as well.

His facts have no sources, so also worthless.

The guy is an American political journalist, his opinions here have exactly zero value to me.

I don't think anyone is going to starve to death because they can only spend 1000EUR...

Wonderful work!

...although the fact that a 3x speed improvement was available kind of proves their point, even if it may be slightly out of date.

> My rule of thumb is that the goroutine that writes to a channel is responsible for closing it. In this case, a deferred call to close the channel in HandlePlayer is sufficient.

This isn't your rule of thumb, it's the only practical way to do it. The problems arise when you have multiple goroutines writing to a channel, which is the case here.

> Still, this example has other issues (naked range over a channel?!) potentially contributing to the author’s confusion.

You sound way more confused than the author. I think you've misunderstood what the (admittedly very abstract) example is supposed to be doing.

As a language user? Just stop using them entirely. It's what most people do eventually.

> So if the default position is unbuffered channels (which it should be), you then realize at some point that this is an inferior version of cooperative async/await.

I feel so validated by this comment.

You joke, but this is not uncommon at all among channels purists, and is the inevitable result when they try to create any kind of concurrency abstractions using channels.

Ugh... I hope I never have to work with channels again.

You're not bad at Go, literally everyone I know who has tried to do this has concluded it's a bad idea. Just stop using channels, there's a nice language hidden underneath the CSP cruft.

Unfortunately, Go also made their channels worse by having their nil semantics be complete lunacy. See the "channel API is inconsistent and just cray-cray" section in the article.

Absolutely nothing has changed at the language level, and for using channels and the `go` keyword directly, there isn't really tooling to help either.

Most experienced Golang practitioners have reached the same conclusions as this blog post: Just don't use channels, even for problems that look simple. I used Go professionally for two years, and it's by far the worst thing about the language. The number of footguns is astounding.

You've misunderstood the example. The `scores` channel aggregates scores from all players, you can't close it just because one player leaves.

I'd really, really recommend that you try writing the code, like the post encourages. It's so much harder than it looks, which neatly sums up my overall experience with Go channels.

> When I moved them over to Kubernetes, I also applied CPU resource limit, each in its own pod. I set the limits based on what I measured when they were all running on PM2 ... but the same code running on Kubernetes ran with 10x less CPU overall. Why? Because the async code were not allowed to just run grabbing as much CPU as it can for as long as it can, and the kernel scheduler was able to fairly run. That allowed the entire system to run with less resources overall.

As someone who has advocated against Kubernetes CPU limits everywhere I've worked, I'm really struggling to see how they helped you here. The code used 10x less CPU with CPU limits, with no adverse effects? What were all those CPU cycles going before?

I appreciate the link, but Australia is an almost entirely tropical/subtropical country, with Sidney being as far from the equator as Northern Africa. I don't believe that analysis can tell you anything about Northern Europe.

This means that solar power output is much more seasonal, and most critically, power consumption in Northern Europe is highest during the winter months. I expect this is not the case for Australia.

Winter nights are long and dark everywhere in Europe, wind speeds definitely correlate somewhat, and transmission losses exist. Unless you're planning to massively overbuild wind power, you do need alternative power sources capable of satisfying almost all your power demand for shorter periods.