Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go runtime: 4 years later

go.dev

Post reply on HN
Print view View original

31–40 of 296 posts

Re: Go runtime: 4 years later

#31

Post by nu11ptr »

Zababa wrote: post #30
nu11ptr wrote: 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.

Agreed - I really like OCaml. Unfortunately it isn't popular enough to get tons of ecosystem love, so I could never find the libraries I need. I'd be pretty happy if it got more popular. Maybe the new multicore work will help.

Re: Go runtime: 4 years later

#32

Post by akira2501 »

nu11ptr wrote: 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…

I haven't found any issues with expression, so far. I wouldn't use it to write a UI, but for writing networking code or automated tasks I find it perfectly suited to the task.

I appreciate it's error handling. It's burdensome, sure, but it presents almost no additional cognitive load when attempting to reason about control flow.

It essentially has no enums. However, it has a comfortable type system that can wrap primitive types, and you can define methods on those wrapped types. It's serviceable, but not elegant.

I have never been a fan of pattern matching outside of functional languages. The phenomenon I notice in languages that do have it, is the majority of uses cases seem to be a pattern match with two outcomes, one a Some() and the other a None(). It really seems like a more annoying way to write if {} else {}.

It has for, but it also has 'range.' It makes up for a lot.

It has nil pointers, which are just a "zero value." It's not uncommon to make it useful and safer in certain contexts. You can request a lookup in a map that is nil. You can ask for the length of a slice that is nil. You get sensible answers still. There are still footguns, but they're all single barrel.. which is _nicer_.

I don't need a perfect language. Good enough with low cognitive load and amazing cross-compile facilities I'll take any day of the week.

Re: Go runtime: 4 years later

#33

Post by nu11ptr »

akira2501 wrote: post #32
nu11ptr wrote: 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…

I haven't found any issues with expression, so far. I wouldn't use it to write a UI, but for writing networking code or automated tasks I find it perfectly suited to the task. I appreciate it's error handling. It's burdensome, sure, but it presents almost no additional cognitive load when attempting to reason about control flow. It essentially has no enums. However, it has a comfortable type system that can wrap prim…

I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. I do wonder how many people who understand Go's limitations (and work around them as you point out above) have truly given Rust a try (takes a few months - can't be done faster). I can't imagine anyone would want to go back tbh, but maybe I'm wrong.

EDIT: In fairness, there is one thing and exactly one thing I miss about Go: compile times. Rust is simply no competition here, but in trade, it is doing a ton of extra work. Trade offs.

Re: Go runtime: 4 years later

#34

Post by User23 »

nu11ptr wrote: 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…

This is pretty much exactly how I feel. I have great respect for the Go team. I broadly agree with their design philosophy. I think CSP is a great theory for concurrency. And I just don’t really like writing Go. I don’t hate it, but I feel like I have to either fight the language or just repeat myself an awful lot.

Honestly, I suspect the deficiency is on my end. Perhaps I’ve just spent too much time with Lisp and have experienced some professional deformation.

Re: Go runtime: 4 years later

#35

Post by Fire-Dragon-DoL »

Xeoncross wrote: post #23
Fire-Dragon-DoL wrote: post #21

Earlier quoted context omitted.

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.

I know, I was thinking C# does something like that though, so I was hoping it would be achievable.

The annoying part about the scripting language is that if something is written in Go, you want developers to also work in Go, otherwise the people writing plugins for your software, knowing better the API and use-cases, have a disconnection with the language actually used for the software, losing potential opportunities for contributions.

Re: Go runtime: 4 years later

#36

Post by KerrAvon »

User23 wrote: post #34
nu11ptr wrote: 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…

This is pretty much exactly how I feel. I have great respect for the Go team. I broadly agree with their design philosophy. I think CSP is a great theory for concurrency. And I just don’t really like writing Go. I don’t hate it, but I feel like I have to either fight the language or just repeat myself an awful lot. Honestly, I suspect the deficiency is on my end. Perhaps I’ve just spent too much time with Lisp and ha…

It's OK to have ergonomic opinions about languages! In scriptingland, I find Python abhorrent. Ruby fits my brain like a glove (the core language, not Rails). Doesn't indicate anything about the quality of the languages or their respective partisans.

Re: Go runtime: 4 years later

#37

Post by cube2222 »

Fire-Dragon-DoL wrote: post #21
tomalaci wrote: post #11

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

Actually, folks usually just use gRPC or Yaegi in Go. You can write an SDK for your software that abstracts all of that away for the plugin developer.

See Terraform[0], Traefik[1], or OctoSQL[2].

Though I agree plugins would be welcome, especially for performance reasons, though also to be able to compile and load go code into a running go process (JIT-ish).

[0]: https://github.com/hashicorp/terraform

[1]: https://github.com/traefik/traefik

[2]: https://github.com/cube2222/octosql

Disclaimer: author of OctoSQL

Re: Go runtime: 4 years later

#38

Post by tbrock »

I am not a fan of new knobs like this. It reminds me of Java where you actually have to think about -xMx blah blah and setting it is a dark art. I would really prefer if we could somehow confer the memory limit from the container environment to go so this could be set intuitively at the container level without mucking about in the go GC internals.

Re: Go runtime: 4 years later

#39

Post by synergy20 »

It is probably a bit misleading when so many say: 'golang is easy', it is not, it is as difficult as Java or other language, probably easier than c++ and rust, but definitely not an easy language.

it makes great sense for network with concurrency, not so with real time or low resource devices to me.

Re: Go runtime: 4 years later

#40

Post by morelisp »

Fire-Dragon-DoL wrote: post #21
tomalaci wrote: post #11

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

If I was going to try to make something "similar to Wordpress" with Go I would replace plugins with optional packages triggered by build flags (or possibly a light codegen step), not an actual dynamic plugin system. The Wordpress model is solved with plugins in PHP (for reasons that were to some degree bad even at the time), but it's not actually "I want to inject some external code into this existing process environment", it's "I want a bespoke N of M features because some Ms are mutually exclusive or have overhead I can't afford".

If you have a language that has a module ecosystem, compiles fast, and generates a single binary, take advantage of that; don't try to reimplement fragile dynamic linking.

Post reply on HN