Live data from Hacker News

Go runtime: 4 years later

go.dev

21–30 of 296 posts

Re: Go runtime: 4 years later

#21

I have been developing in Go for several years and feel like I have seen most it can offer which is quite a lot for backend/networking systems. Besides its GC implementation that works very well most of the time, it also has simple but strong debugging tools to investigate how well you are handling memory allocation and CPU usage. Enforcing consistent coding style also makes it very easy to read other people's code a…

And don't forget, the plugin API has some super strong limitations. I wish that was fixed, otherwise platforms "similar to wordpress" can never become a thing on Go

Re: Go runtime: 4 years later

#23

I have been developing in Go for several years and feel like I have seen most it can offer which is quite a lot for backend/networking systems. Besides its GC implementation that works very well most of the time, it also has simple but strong debugging tools to investigate how well you are handling memory allocation and CPU usage. Enforcing consistent coding style also makes it very easy to read other people's code a…

And don't forget, the plugin API has some super strong limitations. I wish that was fixed, otherwise platforms "similar to wordpress" can never become a thing on Go

Plugins for a compiled binary are just plain hard. Changing the code works better with an interpreted language. Usually you see the software implement it's own interpreter or a scripting language on top to handle this.

Re: Go runtime: 4 years later

#24
post #20
post #14

Earlier quoted context omitted.

No one really care about binary size increase , especially because you can run a Go binary in a docker image with 0 dependencies ( scratch image ) which has a very small size.

do you know how things like tzdata and locale are handled in a single Go executable docker image ?

tzdata, at least, can be embedded in your binary: https://pkg.go.dev/time/tzdata

Re: Go runtime: 4 years later

#25
post #17
post #15

Earlier quoted context omitted.

https://github.com/golang/go/issues/36313

Ah that seems to be the issue some CockroachDB guy complained about. I don't think its high priority for Go team.

The CockroachDB guy didn't understand what he was doing. There's a refute from Russ Cox here: https://news.ycombinator.com/item?id=26834128

Re: Go runtime: 4 years later

#26

Still yearning for an Ocaml-like language that uses the Go runtime.

I've been toying with adding a new generator to Derw (currently targets JS, TS, Elm, English and Derw itself for formatting) that would support Go-based output. It will probably be an experimental branch later this year. Go's performance and distribution makes it an appealing target to hopefully get a faster runtime (particularly interested in making the compiler faster once self-bootstrapping is finished)

Re: Go runtime: 4 years later

#27

Still yearning for an Ocaml-like language that uses the Go runtime.

F# on Go, yeah would be killer! Some time when I have enough free time, if it doesn't exist already, I'd love to build.

what would it give that evolution of the .NET runtime and tooling isn't likely to offer?

Re: Go runtime: 4 years later

#28

Earlier quoted context omitted.

F# on Go, yeah would be killer! Some time when I have enough free time, if it doesn't exist already, I'd love to build.

what would it give that evolution of the .NET runtime and tooling isn't likely to offer?

Go has nice libraries for networking on Linux.

Re: Go runtime: 4 years later

#29
I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs much better enums, needs pattern matching, has error prone C-style 'for', almost everything is statements not expressions, special comments are error prone, has nil pointers, etc.). In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat. That said, I don't know what I'd want to drop from Rust so maybe I'm just fantasizing.

Re: Go runtime: 4 years later

#30
post #29

I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…

> In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat.

OCaml kind of gives you that, but the dev experience isn't as good as Rust or Go in my opinion. Still, I enjoy it a lot, more than Go or Rust.

Post reply on HN