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

41–50 of 296 posts

Re: Go runtime: 4 years later

#41

Post by Philip-J-Fry »

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

I've written plugins in Go. You don't really need to use the plugin package, and you probably shouldn't anyway.

One way I've done it in the past is via sub processes talking via stdin/stdout. Another way I've done it is just via a regular REST API.

You'll never get enough performance for a lot of tasks if you need to pass a lot of data between applications. But depending on your needs it's more than serviceable. The benefit of this is that plugins don't need to be written in Go, as you have a simple interface.

A good example of this is something like LSP. LSP plugins are abundant and each one is written in a different language. VSCode is Typescript, the Go language server is written in Go. Both can speak to eachother fast enough.

Re: Go runtime: 4 years later

#42

Post by mort96 »

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…

I sorely wish CSP was enforced in any way by Go, but it's not. The only thing which arguably makes Go more "CSP-y" than, say, C++ is that it comes with a decent built-in concurrent queue and some syntax sugar. Goroutines have full mutable access to all the variables in their scope, and lots of Go code ends up being your good old mutex hell -- just more of it, since threads are so easy to create.

I think something way more radical than "C++ threads but with a built-in concurrent queue" is needed. If the default was to share nothing, and any shared memory had to be explicitly shared somehow, that would be a great step in the right direction. Maybe the compiler could even check that explicitly-shared variables are protected by a mutex; something like how Rust mutexes "own" the things they're protecting and you can't access the underlying object without having the lock.

Re: Go runtime: 4 years later

#43

Post by JustSomeNobody »

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…

> That isn't meant as a slight or anything other than simply my opinion.

That's fine, we all have our preferences. I love Python, but I can't stand Ruby. I love Go, but hate C++. I make my living with C#, but won't touch Java.

It's okay. We're not wrong. We're just different.

Re: Go runtime: 4 years later

#44

Post by mort96 »

synergy20 wrote: post #39

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.

I always found languages which require you to always remember to manually call destructors to be quite hard, be they C or Go or JavaScript, when the system has lots of moving parts and performance is a concern. A single mistake and you're leaking.

Re: Go runtime: 4 years later

#45

Post by ikiris »

nu11ptr wrote: post #33
akira2501 wrote: post #32

Earlier quoted context omitted.

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 o…

The problem with rust is explicitly that cognitive load in large codebases. It is much easier to read go code than rust when working on many things. Rust fits great if you don't scale though.

Re: Go runtime: 4 years later

#46

Post by wahern »

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.

Plugins for ELF- and Mach-O-based systems aren't any different than regular shared libraries, modulo slightly different symbol precedence. AFAIU, while a quite different architecture, Windows PE linking treats them quite similarly, too.

Perhaps you meant statically compiled binaries? Even then I'm not so sure about that. Right now I'm working on a project that statically compiles a plugin so its various libraries can't leak or be overridden by the loading application, yet which itself can load other plugins. OTOH, this is in C, C++, Objective-C, and Lua (basically C from the perspective of binary linking), all of which have mature linking semantics. (Well, at least this is true for C. Controlling symbol namespace pollution by C++ and Objective-C code requires more complexity than for C, but at least the necessary compiler and linker flags exist and are mature.)

When you use languages or toolchains that don't invest in an ABI, or which make linking too automagic (with no or little recourse for exposing various linking features a platform may offer), then runtime linking is likely to become a major limitation in some solution areas. For example, there's probably no way to coax XCode to compile my plugins properly, without outsourcing some logic to additional scripts. Ultimately a Makefile is likely the best solution--and the one I chose, anticipating these headaches--as it keeps most of the build transparent. Fortunately, XCode seems to just be a wrapper around a bunch of command-line utilities, so you don't actually need XCode at all.

Re: Go runtime: 4 years later

#47

Post by mort96 »

tbrock wrote: post #38

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.

I'm sure the goal will always be to be as good as humanly possible out of the box. 99.999% of users will probably never have to think about it. But if your mission-critical application just happens to hit a case which the default behavior handles poorly, would you rather: 1) redesign your system and hope that a different design just happens to not hit the same bad case, or 2) tweak a knob until the GC fits your use case?

I think I'd prefer 2. But 1 will always remain an option I suppose.

Re: Go runtime: 4 years later

#48

Post by cheriot »

throwamon wrote: post #3

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

I'd settle for the CoffeeScript of Go. Keep most of it, add sum types, expand generics, and replace nil with options. If you're feeling spicy, make whitespace significant.

Re: Go runtime: 4 years later

#49

Post by stouset »

nu11ptr wrote: post #33
akira2501 wrote: post #32

Earlier quoted context omitted.

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 o…

Anecdote:

I have had year+ long breaks between writing Rust applications. I have been able to get back into it without issue very quickly. At least one of those times I successfully completed a large, sweeping refactoring of a project of mine that had lay untouched for three years. I can confidently say it would have been extremely difficult to do that same task in other languages I consider myself very proficient in and use daily.

Re: Go runtime: 4 years later

#50

Post by vlunkr »

nu11ptr wrote: post #33
akira2501 wrote: post #32

Earlier quoted context omitted.

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 o…

> 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)

This is basically the "Anyone who doesn't love my favorite movie hasn't watched it enough times" argument. Programming language design is a complex space, there are no "correct" opinions.

Post reply on HN