Re:I’m joining the Go team at Google
by pjmlp on Friday September 23, 2016 @01:25PM
(#12566334)
I didn't say to not use the GC at all, rather to use it less.
We can use the GC for the 90% of the code that isn't performance critical, enjoying the programming productivity of using a GC enabled language.
After profiling the application and find out where those 10% performance/memory critical hotspots are, re-architect the data structures to use static allocation, either via the stack (compiling with escape analysis validation) or the global memory. Or even doing off-GC Heap allocation via syscalls.
Then make use of pointers or array indexes to access the static allocated data.
Plenty of examples in Modula-3, Oberon, Mesa/Cedar research papers.
There are plenty of languages that I would rather use for systems programming instead of Go, but the language is certainly capable of being used in the same scenarios as Oberon.
For example Astrobe, which sells bare metal Oberon compilers for ARM Cortex-M4, Cortex-M3 and Xilinx FPGA Systems.
If anything, comparing Oberon's SYSTEM with Go's unsafe packages, Go could use a few more intrinsics like CPU register access, but those as also doable with a bit of Assembly help. Which ANSI C also doesn't support.
My goal is just creating awareness that alternatives are possible, it doesn't need to be always C.
We can use the GC for the 90% of the code that isn't performance critical, enjoying the programming productivity of using a GC enabled language.
After profiling the application and find out where those 10% performance/memory critical hotspots are, re-architect the data structures to use static allocation, either via the stack (compiling with escape analysis validation) or the global memory. Or even doing off-GC Heap allocation via syscalls.
Then make use of pointers or array indexes to access the static allocated data.
Plenty of examples in Modula-3, Oberon, Mesa/Cedar research papers.
There are plenty of languages that I would rather use for systems programming instead of Go, but the language is certainly capable of being used in the same scenarios as Oberon.
For example Astrobe, which sells bare metal Oberon compilers for ARM Cortex-M4, Cortex-M3 and Xilinx FPGA Systems.
If anything, comparing Oberon's SYSTEM with Go's unsafe packages, Go could use a few more intrinsics like CPU register access, but those as also doable with a bit of Assembly help. Which ANSI C also doesn't support.
My goal is just creating awareness that alternatives are possible, it doesn't need to be always C.