I'm really looking forward to SIMD becoming standard in Go. It might sound very niche, however SIMD intrinsics (which is different from how they are available now, which is via non-inlinable assembly) allow to generate similar vector code to C intrinsics, with very little in terms of overhead due to bounds checking, etc. This allows to write programs that are highly optimised for modern CPU and get maybe 80% of performance compared to the same variant in C. This is much better than the current state where C typically outperforms Go by at least 2x/3x, and SIMD typically allows you to get 10x or more speedup already, which gives UNLIMITED POWER to Go when CPU performance is a bottleneck
I find the arena experiment very interesting. If done right, whole programs can be structured as as a set of arenas. I've read some things on arenas here such as https://news.ycombinator.com/item?id=37670740
I am a low-level zig guy right now too. I have been around for a long time, and it’s funny to see arenas come back into vogue as a solution to nearly everything.
Arenas are great for avoiding allocations per tick/request/frame/layer. No symmetric free() to bracket lifetimes! They have a purpose, and we always knew that.
But by definition, your program is over-allocating as a tradeoff. Makes a ton of sense in certain use cases. However, we didn’t invent garbage collection and borrow-checking and realloc() just to publish papers ;)
Half of my time programming zig is spent considering allocation strategies. That’s a feature. “Where are the bytes?”
Once allocators in general click, memory management in C becomes a total breeze.
Combined with typed fat pointers (slices and strings), typed hashmaps and stack-trace-assertions, C in general becomes quite nice. The rest is compiler flags.
Go solves this by being a better language out of the box, but with the Wirthian aspects removed they feel very similar. Perhaps not so surprising.
Hm, that's interesting; chrome://flags does seem to be titled "Experiments"... After, of course, you type "flags" into the address bar to get there. I guess I can see a distinction there, but it's pretty subtle.
I'm really looking forward to SIMD becoming standard in Go. It might sound very niche, however SIMD intrinsics (which is different from how they are available now, which is via non-inlinable assembly) allow to generate similar vector code to C intrinsics, with very little in terms of overhead due to bounds checking, etc. This allows to write programs that are highly optimised for modern CPU and get maybe 80% of performance compared to the same variant in C. This is much better than the current state where C typically outperforms Go by at least 2x/3x, and SIMD typically allows you to get 10x or more speedup already, which gives UNLIMITED POWER to Go when CPU performance is a bottleneck
Perhaps the Go community should take a look at JEP or PEP to better document features and their life cycles and statuses overall.
I find the arena experiment very interesting. If done right, whole programs can be structured as as a set of arenas. I've read some things on arenas here such as https://news.ycombinator.com/item?id=37670740
I am a low-level zig guy right now too. I have been around for a long time, and it’s funny to see arenas come back into vogue as a solution to nearly everything.
Arenas are great for avoiding allocations per tick/request/frame/layer. No symmetric free() to bracket lifetimes! They have a purpose, and we always knew that.
But by definition, your program is over-allocating as a tradeoff. Makes a ton of sense in certain use cases. However, we didn’t invent garbage collection and borrow-checking and realloc() just to publish papers ;)
Half of my time programming zig is spent considering allocation strategies. That’s a feature. “Where are the bytes?”
Once allocators in general click, memory management in C becomes a total breeze.
Combined with typed fat pointers (slices and strings), typed hashmaps and stack-trace-assertions, C in general becomes quite nice. The rest is compiler flags.
Go solves this by being a better language out of the box, but with the Wirthian aspects removed they feel very similar. Perhaps not so surprising.
So, these are feature flags by any name, right?
No. Feature flags are a mechanism for enabling some of the experiments. But what’s being discussed here are the features themselves.
Hm, that's interesting; chrome://flags does seem to be titled "Experiments"... After, of course, you type "flags" into the address bar to get there. I guess I can see a distinction there, but it's pretty subtle.