Hacker Newsnew | past | comments | ask | show | jobs | submit | usrnm's commentslogin

> how common is it for go devs to experience leaking goroutines

About as often as leaking memory in C++


F. again i have minimal experience actually ever needing it in go, but guessing this is just generally the exercise of managing the lifecycle of a goroutine well in your code? proper handling so things dont get orphaned in buffer, fire and forget woopsies, etc.

early on i do feel like go kinda advertised batteries included concurrency but i kinda wished they advertised the foot-shooting-mechanisms and gaps in the abstraction a little more. overall i prefer to have enough control to choose how to manage the lifecycle. mem leaks bum me out and kill my steam, at least from my experience with c/cpp.


Browser engines are probably some of the most optimized pieces of software in existence, so it doesn't surprise me at all.

Love2D uses Luajit and directly calls established game libraries. The CPU usage should be far better for 2D games, luajit is faster than a browser's javascript jit. You can also create single exe games that are a few megabytes and not a few hundred megabytes.

Optimized abstraction layer is still an abstraction layer. The web is like two or three of those.

Explain this to electron haters.

Browser engines are optimized for displaying web pages, not for applications.

60MB+ for a calculator is not optimal.


explain that to my webgl TypeScript browser game running at 180+ FPS while rendering a large RPG tiled world with infinite procedurally JIT generated biomes, with heavy processing delegated to webworkers.

As you aren't posting code or stats I can't say much, but I'd bet a native app would still be smaller and more efficient, since you have to wrap what you're doing in an entire Chromium instance and deal with a web stack designed for documents, which is definitionally less efficient than a native alternative. Tiles aren't exactly cutting edge technology.

"Heavy processing delegated to webworkers?" That just sounds like threads but worse.


yep, native is faster for sure.

but webgl + web workers is good enough these days.

I can't share code sorry, the project got big and I have commercial plans.

But you can tell Gemini 3.1, Opus 4.6 or GPT 5.4 High to generate a demo and they do a decent job most of the times.

that's how I got started, seeing how it was possible to have good game performance with multi threaded workloads on a browser.


Nobody ever said in the thread that web is the most efficient platform, stop with your “designed for documents” trauma already.

The first post in this subthread was literally a statement that "A web-based solution is usually better performing, despite all the bloatware necessary." And you literally joined in to support that assertion against "the Electron haters."

And it isn't trauma, it's literal fact. Electron isn't used because it's technically superior to native applications, it's used because web devs are a dime a dozen. It's popular for business reasons, not technical reasons. It works "well enough," but only because computers are really fast but there's only so much slack an OS can take up when even parts of it are Electron apps, and probably vibe-coded to boot.


Meanwhile that same computer could probably run Counter Strike at 400 FPS.

step 1 htop

there isnt step 2, explain is over


Ever heard of hamam?

Hammam is not as hot as sauna and not as dry. Sauna's air temperatures can reach above 100 degress Celsius and humidity is usually relatively low (around 20%).

[1] https://en.wikipedia.org/wiki/Sauna

Hammam's temperatures are around 40-50 degrees Celsius and humidity is close to 100%.

These are very different conditions, with very different body response.


> Hammam's temperatures are around 40-50 degrees Celsius and humidity is close to 100%.

Which makes it absolutely unbearable. By the way, that combination of temperature + humidity will cause severe hyperthermia (which can be deadly) faster than people think.


There is also a World Championship with up to 130°

https://en.wikipedia.org/wiki/World_Sauna_Championships

:-D


Was - there was a world championship

The last time it was held, a Russian died and a Finn ended up in hospital with severe burns.

The problem is that staying as long as possible in a sauna can be fatal.


So, you’re telling me the Finn won?

They were both disqualified as they did not leave the sauna unaided.

A different Finn won.


> The problem is that staying as long as possible in a sauna can be fatal.

One used to read regularly (like a few times a year) about someone who came home drunk and went to (electric) sauna and passed out... and died.

Saunas in new construction now all have timers.


I have not, what is it?

A steam sauna originating in Turkey, popular in many Arabic countries.

It may originate from Roman's thermae: https://en.wikipedia.org/wiki/Thermae

They are not supposed to produce code that doesn't compile, why would they?

Debugger positions on the other hand are a pain with these things.

Uh yes, that's what I meant ;)

In C/C++ you have the #line preprocessor directive. It would be nice if Go had something similar.


Go has apparently got //line directives, and this project uses them.

What are you talking about, there is actually too much unicode awareness in C++. Unicode is not the same thing as utf-8. And, frankly, no language does it right, I'm not even sure "right" exists with Unicode

Too much unicode in standard C++? Where?

c++20's u8strings took a giant steaming dump on a number of existing projects, to the point that compiler flags had to be introduced to disable the feature just so c++20 would work with existing codebases. Granted that's utf-8 (not the same thing as unicode, as mentioned) but it's there.

And yet, unicode support is still abysmal throughout the standard library. I don't disagree though.

Things like char32_t, std::u32string for storing UTF-32 characters.

And yet, none of them work with std::regex etc.

I once spent several days debugging that same mistake. Stuff worked perfectly in tests but broke misteriously in production builds. Couldn't stop laughing for a few minutes when I finally figured it out.

Atomic operations, especially RMW operations are very expensive, though. Not as expensive as a syscall, of course, but still a lot more expensive than non-atomic ones. Exactly because they break things like caches

Not only that, they write back to main memory. There's limited bandwidth between the CPU and main memory and with multithreading you are looking at pretty significantly increasing the amount of data transferred between the CPU and memory.

This is such a problem that the JVM gives threads their own allocation pools to write to before flushing back to the main heap. All to reduce the number of atomic writes to the pointer tracking memory in the heap.


> Just use lambdas/callbacks

"Just" is doing a lot of work there. I've use callback-based async frameworks in C++ in the past, and it turns into pure hell very fast. Async programming is, basically, state machines all the way down, and doing it explicitly is not nice. And trying to debug the damn thing is a miserable experience


You can embed the state in your lambda context, it really isn't as difficult as what people claim.

The author just chose to write it as a state machine, but you don't have to. Write it in whatever style helps you reach correctness.


You still need the state and the dispatcher, even if the former is a little more hidden in the implicit closure type.


High-throughput is not the same thing as low latency. In fact, they're often at odds with each other


Google "Messmer Plan". France built 65 reactors in 15 years as a reaction to the 70s oil crisis, and now the majority of electricity in France comes from nuclear without any significant dependency on fossil fuels. The only thing that we're lacking is political will to change things.


Yep. Once people experience true hardship like having to keep their house just above freezing in the winter due to the cost of energy - all of a sudden impossible things become quite possible.

The only potential issue here would be if the west had collectively hollowed out its manufacturing base so much as to make surging capacity and capability a generational thing vs. immediate.

Coasting on past success eventually brings stagnation and pain. Hopefully the pain isn’t too horrible for normal folks this time around.


The French energy sector is more than 50% fossil [1]. If France decarbonizes over the next decades, it will be due to renewables, not nuclear. While the government and population have been extremely pro-nuclear for a long time, the economics just don't work out. The current plan is to barely build enough reactors to replace old ones going off-line over the next decades.

[1] https://en.wikipedia.org/wiki/Energy_in_France


That seems to be mostly because of oil use which is coming from transportation. Electrical generation is dominated by nuclear and renewables. Electrification of transport will help, provided they don't generate the additional electricity needed by burning gas or coal...


That's why I used the word electricity and not energy. It isn't perfect, but still much better than the majority if the world and even Europe. The fact that even the French themselves cannot replicate it anymore speaks volumes about the weakness of the current political system. As a counter example, the Chinese can and do.


In 2024, China produced 8 times more electricity from renewables that from nuclear [1], and the renewable share is growing much more quickly. Nuclear is as dead in China as it is elsewhere in the world.

[1] https://ourworldindata.org/grapher/energy-consumption-by-sou...


China has a huge advantage over the majority of Europe: abundance of mostly empty land with a lot of sunlight, it's unrealistic in places like Norther Europe. But I'm not talking about nuclear alone, it was the best answer in the 70s and 80s, nowadays we need a healthy mix of nuclear, solar and wind. But above everything else we need a government willing to make significant changes and make them fast.


China has a larger population density than the EU. There is more empty land in Europe.


Chinese population is concentrated in the East. The Western half of the country is pretty much empty. Lots of sunny semi-desertic/desertic areas, too so they do have a lot of actually empty land well suited for solar (China is more to the South compared to Europe: Beijing is about same latitude as Madrid...) and wind.


> There is more empty land in Europe.

Truly empty? Or nature reserves?


And now Flamanville 3 is 7x over budget and 14 years late. Online but not commercially operational.

Their EPR2 fleet are getting an enormously large subsidy at 11 cents kWh CFD for 40 years and interest free loans. Sum freely. With the first reactor online in 2038 of everything goes to plan.

How many trillions in subsidies should we handout to new built nuclear power to ”try for real”?

Or we can just build renewables and storage which is the cheapest energy source in human history.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: