3 ms·

> but I'd still stay Go, Rust, and C++ are better How does go fit in with the other two? I hate that it somehow considered low level, when it is closer to JS i

by kaba0 4y ago

> but I'd still stay Go, Rust, and C++ are better How does go fit in with the other two? I hate that it somehow considered low level, when it is closer to JS in execution semantics/performance/everything. Also, Java byte code is typed.

jpgvm 4y ago
Go exists in a weird space. It's not the top performer but is respectable (as long as you don't pressure the GC too much) however it's also not very expressive. This leads to it not being favoured as a high level language because it lacks the primitives to write very concise code. On the other hand it has a big runtime and a GC so it's too high level for many true systems programming tasks. This lack of high level language features coupled with it's higher level runtime means that it finds itself occupying a space between systems languages like Rust and C++ but "lower" than Python/JS/Ruby/Kotlin/Swift/etc. Essentially it ends up competing with Java on the server and supplanting C/C++ for systemsy tools in fields it got to before Rust arrived on the scene.
- kaba0 4y ago
  That’s a good summary. I just see it way too often bundled together with low-level languages and it benefits no one to prefer/not prefer a language based on false knowledge.
chubot 4y ago
With respect to performance and semantics, it's not closer to JS -- it's a typed language that uses types for AoT compilation, like C++ and Rust. The GC is a big difference, but it's also a pretty good one from what I know. The author of esbuild is understands software performance deeply (e.g. architected Figma in the browser in C++). He tried esbuild in both Rust and Go, and preferred Go for performance. https://esbuild.github.io/faq/ https://esbuild.github.io/faq/ There are some comments about it here on HN. edit: found some: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22338442 https://news.ycombinator.com/item?id=22338442 https://news.ycombinator.com/item?id=30094498 https://news.ycombinator.com/item?id=30094498
- kaba0 4y ago
  Go barely does any optimizations, and its GC is quite subpar if anything (it does optimizes for latency, while most other optimizes for throughput, for what it’s worth). It does have value types and pointers (so do C# and D for quite some time), but with a naive compiler it will generally sit at the ~2+x niche of C performance, which.. performant JITted languages also occupy, including JS.
  - chubot 4y ago
    OK, but what's your point? That Go isn't good for writing language processors? For that problem, Go can be put in the family of Rust and C++, and IMO the GC is actually an advantage over them. As mentioned, ASTs are often graphs. Putting Go closer to JS is just wrong, in an absolute sense, and relative to this problem. esbuild proves that Go is good for these workloads (again see those links). I think you're over-generalizing language performance without paying respect to the workload -- performance is very multi-dimensional. On microbenchmarks, Go is probably 2x slower than C, but (1) that's VERY good, and (2) those benchmarks aren't representative of the pointer-rich AST workloads we're talking about here. I have some beefs with Go myself, but it sounds like you just have some beefs with it that aren't all that relevant to the problem being discussed.

by kaba0 4y ago

jpgvm 4y ago

Go exists in a weird space. It's not the top performer but is respectable (as long as you don't pressure the GC too much) however it's also not very expressive. This leads to it not being favoured as a high level language because it lacks the primitives to write very concise code. On the other hand it has a big runtime and a GC so it's too high level for many true systems programming tasks. This lack of high level language features coupled with it's higher level runtime means that it finds itself occupying a space between systems languages like Rust and C++ but "lower" than Python/JS/Ruby/Kotlin/Swift/etc. Essentially it ends up competing with Java on the server and supplanting C/C++ for systemsy tools in fields it got to before Rust arrived on the scene.

kaba0 4y ago
That’s a good summary. I just see it way too often bundled together with low-level languages and it benefits no one to prefer/not prefer a language based on false knowledge.

chubot 4y ago

With respect to performance and semantics, it's not closer to JS -- it's a typed language that uses types for AoT compilation, like C++ and Rust. The GC is a big difference, but it's also a pretty good one from what I know. The author of esbuild is understands software performance deeply (e.g. architected Figma in the browser in C++). He tried esbuild in both Rust and Go, and preferred Go for performance. https://esbuild.github.io/faq/ https://esbuild.github.io/faq/ There are some comments about it here on HN. edit: found some: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22338442 https://news.ycombinator.com/item?id=22338442 https://news.ycombinator.com/item?id=30094498 https://news.ycombinator.com/item?id=30094498

kaba0 4y ago
Go barely does any optimizations, and its GC is quite subpar if anything (it does optimizes for latency, while most other optimizes for throughput, for what it’s worth). It does have value types and pointers (so do C# and D for quite some time), but with a naive compiler it will generally sit at the ~2+x niche of C performance, which.. performant JITted languages also occupy, including JS.
- chubot 4y ago
  OK, but what's your point? That Go isn't good for writing language processors? For that problem, Go can be put in the family of Rust and C++, and IMO the GC is actually an advantage over them. As mentioned, ASTs are often graphs. Putting Go closer to JS is just wrong, in an absolute sense, and relative to this problem. esbuild proves that Go is good for these workloads (again see those links). I think you're over-generalizing language performance without paying respect to the workload -- performance is very multi-dimensional. On microbenchmarks, Go is probably 2x slower than C, but (1) that's VERY good, and (2) those benchmarks aren't representative of the pointer-rich AST workloads we're talking about here. I have some beefs with Go myself, but it sounds like you just have some beefs with it that aren't all that relevant to the problem being discussed.