5 ms·
The only apt comparison IMO is Rust, the other languages with JIT compiling runtimes aren't really useful comparisons. To me this looks like a discussion about
by cle 6y ago
The only apt comparison IMO is Rust, the other languages with JIT compiling runtimes aren't really useful comparisons.
To me this looks like a discussion about syntax and ergonomics. Go provides the same mechanisms:
* for safe dereferencing, use "val, ok := *valRef"
* for potentially-unsafe dereferencing, use "val := *valRef"
Every language in that list has equivalent mechanisms. In Rust you can use one of these methods: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html or pattern matching. That's a whole lot to pick from.
But Rust also makes it more complicated to reason about your memory, see for example https://doc.rust-lang.org/std/option/#representation https://doc.rust-lang.org/std/option/#representation
So, given Go's design tenets, using pointers makes a lot of sense to me. It is easy to reason about them in terms of memory and resource consumption, there are only a few ways they can be used, pass-by-value semantics further reduces the centrality of them, and they don't require a JIT compiler to be efficient.
- gameswithgo 6y agoWhy does whether a language is JIT or not make any difference? C# is usually jitted but you can AOT compile it just like Go if you want, and you could JIT go if you want.
- cle 6y agoThe memory layout of a pointer is quite different from a full-blown object. E.g. Optionals are only efficient in Java because the HotSpot compiler optimizes them at runtime. And it further obfuscates the memory layout--is it an object or not? How much memory will it use at runtime? How long does it take to become optimized? Am I paying the cost of a method call or not?
- xxs 6y agoAt least in Java it's rather easy with PrintAssembly, if you do care about performance.
- iudqnolq 6y agoAn Option<T> is literally a pointer to T with some compile-time semantics. Which part of the memory model is hard to reason about? Edit: Nevermind, I forgot this is only of T is a reference. Otherwise it's layed out like a normal enum.
- cle 6y agoYes this is basically what I was talking about. It becomes pretty tricky to understand memory layout if you try to masquerade as a regular type (hence my apparently controversial reference to JIT compilers). I guess my point is that Go pointers are language primitives for that reason, and they support the fundamental "safe" and "unsafe" access operations that all those other languages have. So I don't think there's anything fundamentally different between the safety of Go pointers and optional types, but they are easier to reason about from a memory model perspective (they are laid out in memory exactly as you would expect). Relatedly, in practice, a lot of Rust code I've worked with is littered with unwrap() calls.
- Dylan16807 6y agoYou only have to deal with the extra complexity if you choose to put non-pointers into an Optional, though. If you use the same capabilities go has, there's no problem. Not that "maybe it uses an extra byte, maybe it doesn't" is going to matter in 99% of situations.
- deepsun 6y ago> the other languages with JIT compiling runtimes aren't really useful comparisons Interesting side-point re. language comparisons I noticed recently -- Java is often benchmarked together with compiled languages, although I would say it's only half-compiled (to bytecode, not to machine code). That's
- xxs 6y agoByte code compilation does extremely little about performance, it's all about the JIT. Hotspot was simply the 1st JIT compiler that was that good it was comparable to gcc's o2. Java is very much compiled to machine code/assembly.
- deepsun 6y agoBut then why it's not compared in the same ballpark as JS, Python? They all have JIT as well. But Java is compared against AOT compiled languages.