Hacker News Reader

Comment by themihai | Hacker News Reader

>> make some things that needed to be done in C++ or Rust viable in Go.

like "micro controllers, AAA game engines, and web rendering engines"? I highly doubt it! Swift 5+ might have a chance but Go has none(as it is now).

View on HN

Yup, like the post about Discord processing images from yesterday underscored. If you need top tier performance you're going to have to reach for a language like Rust, C or C++ because without discrete control over your allocations and memory placement you will have something slower.

C# is about the closest thing these days thanks to value types but even then Unity had to drop down to C++ to really get the performance they needed at the engine level.

Yeah, but it seems to be fine for something like Docker.

Sounds like you're advocating a Rocker project.

Docker could also have been written in Java or Python, though, because most of the heavy lifting is provided by the kernel.

Docker is more I/O bound than CPU bound, so Go is just fine.

I wrote the most non-idiomatic C# in Unity to create a lighting fast 2D skeletal animation system (100-1000x the performance of the closest competitor) and I'm certain I could've gained yet another order of magnitude had I access to C++ instead of C#.

C# is fine for scripting, but absolutely terrible for performance critical batching where branch predictions and cache misses are your main optimization points.

Also the lack of array slices make it really hard to avoid memory allocations.

Yeah, that's my biggest gripe with the "GC'd language are as fast as native" crowd. You end up doing all sorts of contortions in order to get the allocation/cache coherency that you need that you're better off using a language that has proper support for it.

I love scripting languages for orchestrating logic(luaJIT!) but when you need to massively vectorize your data so that you get full utilization of the prefetcher there really is no substitute.

> Swift 5+ might have a chance but Go has none(as it is now)

As long as it lacks Windows support Swift has no chance to be even considered for an AAA game engine.

That seems relatively easily fixed, if any biggish company cared enough to do it?

Many controllers are not hard-realtime. Think e.g. of microwave ovens or smart locks. Often you might be willing to trade a 10ms GC pause of Go for much lower chances of memory corruption or crashing compared to C.

Many controllers have almost zero memory headroom meaning your GC pauses get an order of magnitude slower if not more as you have less than 2x your working set.

Also, most of the applications never allocate because they can't even afford the overhead of pooling/freelists that come with a stock malloc implementation.

is a gc all that relevant if you're not dynamically allocating in either case?

Garbage collection by its nature implies dynamic allocation.

You're using value types and raw pointers in those targets because even the memory overhead of a heap/freelist/etc can be too much. With things like AVR you're looking at 512B to 16kB of total memory(part of which includes the code you write).

> Garbage collection by its nature implies dynamic allocation

i'm not sure i follow - you're saying that a gc existing implies that one cannot preallocate and avoid dynamic allocation?

> preallocate

This will still use dynamic allocation to do the preallocation. You'll have a heap to track this which comes with its own overhead.

i guess i was using 'dynamic allocation' to mean allocation that occurs in the midst of the main control flow, likely in response to some conditional evaluation (vs upfront).

Yeah, if you allocate in the main loop or preallocate you're still going to pay the overhead of a heap to keep track of those allocation :).

I’m developing software for WiFi routers. I would have liked to use Go but the binaries are simply too large and compilation is sketchy for ARM.

I wonder if Rust could fit your bill better. You can include about as little runtime as you like, no GC or language primitives runtime to carry if you don't choose to.

>> Often you might be willing to trade a 10ms GC pause of Go for much lower chances of memory corruption or crashing compared to C.

I believe the C/C++ developers will look for a Rust-like solution(even if I don't like Rust) rather than Go if crashing is an issue. Go doesn't solve the crashing issues. It has its own crashing issues(e.g. dereferencing nil pointers , deadlocks, data-races, nil and nil interfaces etc). If the GC is not an issue they can choose any other GC language so Go is not that special anymore in this regard. The truth is that Go has its own niche and that's web services.

I don't see Rust as ready for AAA game engines, not by a long shot.

Last I checked it had absolutely terrible reflection capabilities and meta-programming; both of which are used as the foundations of modern engines.

A game engine is also radically different than your usual use of Rust; its almost impossible to model with borrows without going dynamic and those come with runtime overhead; something not acceptable when you're used to zero-cost abstractions.

A web rendering engine has ridiculously less state and moving parts than a game engine. D would be a much better fit for game engines than Rust.

c++ is used in a lot more than just "micro controllers, AAA game engines, and web rendering engines".

C++ is used for everything(including web development) so any language can replace C++ in various use cases.

C++ Applications:

http://stroustrup.com/applications.html

A big list.

Like AA games/game engines, and some micro controllers sure. Desktop applications like text editors where waiting for JITs and high pause times are annoying unlike things running on server as well.

Reply on news.ycombinator.com