3 ms·
When you need to start worrying about memory allocation control, garbage collection latency, pointers, byte padding, and CPU instructions per operation, Go migh
by kenhwang 9y ago
When you need to start worrying about memory allocation control, garbage collection latency, pointers, byte padding, and CPU instructions per operation, Go might be not be the best tool for the job anymore. Seems like Rust might be a better choice here? Instead of reverse engineering what the compiler might do, then structuring the code in subtle ways to get the compiler to actually do what you intend to do, why not pick a language that lets you command the compiler do to what you want?
- achille-roussel 9y agoWe've invested a lot in Go at Segment and introducing a new language isn't cost-free, building the expertise, tools, and processes to work with a new technology takes time and energy. It's way more time efficient for us to learn how to build better Go code. While this post focuses on the optimizations, this is only part of the development process, and Go is still an amazing tool to design, implement, and test software, and on top of that it gives us the ability to address those performance issues when they come up.
- blaisio 9y agoGarbage collection simplifies but does not eliminate memory management. That's okay, because even though it does not eliminate the need for memory management completely, it does still save the programmer from an awful lot of work. Anyway, the choice of Rust vs Go should not be based on a single factor like "Rust is not garbage collected". Especially since many common coding patterns require some form of garbage collection, even in Rust!
- pjmlp 9y agoI love the work they are doing in regards to low level systems coding and safety, but in general a GC + ability to statically allocate feels more productive, specially as former Oberon user and Modula-3 fan.
- pjmlp 9y agoLanguages like Eiffel, Modula-3, Active Oberon, Sing#, System C#, D are good examples on how to have GC productivity and control over memory allocation. What Go lacks is the ability to explicit state that a value must live in the stack, leaving it implicit and open to escapes. Using the first example in D, x will definitely be stack allocated. import std.stdio; void main() { auto x = 42; writeln(x); }
- amelius 9y agoWhat happens if you take the address of x in that example, and store it in some data-structure that is on the heap? Would that be a recipe for a "segfault"? Do all these languages allow segfaults to happen?
- augustk 9y agoAt least in Oberon there is no "address of" operator.
- pjmlp 9y agoSure there is. MODULE Crash; IMPORT SYSTEM; VAR source: LONGINT; sourceAddress: INTEGER source2: LONGINT; BEGIN source := 23; sourceAddress := SYSTEM.ADR(source); SYSTEM.GET(sourceAddress, source2); (* .... *) END Crash. The issue is that any module that imports SYSTEM is considered unsafe by the compiler.
- pjmlp 9y agoYes, that can happen. However in some of those languages those type of assignments are only allowed in unsafe code, for example in Modula-3 you can only do that in an unsafe module package and the target variable has to be declared as UNTRACED REF.