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

Why I’m Frustrated with Go

dev.to

Post reply on HN
Print view View original

41–50 of 233 posts

Re: Why I’m Frustrated with Go

#41

Post by dullgiulio »

43224gg252 wrote: post #18
latch wrote: post #11

I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log +…

>I found it a chore to maintain Go-based systems My opinion is the opposite. Almost every go code base I've seen is extremely consistent compared to other languages. Going from one code base to another is almost always seamless because learning Go involves learning the Go tools which forces you to follow Go coding standards. I'd choose to work on a Go code base over Java or C++ any day of the week. I don't have much…

>> the entire error thing is absurd. Anders Hejlsberg got th is right many years ago: 9 out of 10 errors are "handled" by a central error handler

> This is almost always unacceptable in production, especially when it comes to mission critical hard/software. You need to be able to handle errors in production that you may not even be able to catch in testing and that means you need to catch all the errors and think critically about what should be done when that error is encountered.

Absolutely. My approach is usually that errors are always wrapped not just returned. The wrapping itself ends up looking almost like code documentation: "could not do X: ", "error while doing X: ". Every error string is then unique in the program, easy to grep.

"Could not perform the operation", maybe together with a 500 lines stacktrace in your logs (which are maybe line-by-line bacause that's the default)... you are up to a nice middle of the night debugging session :)

Re: Why I’m Frustrated with Go

#42

Post by _urga »

latch wrote: post #11

I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log +…

The Node event loop (the control plane) is single threaded, but the data plane is multi-threaded, you can easily write C++ bindings to run in the thread pool to handle CPU intensive work.

Re: Why I’m Frustrated with Go

#43

Post by searealist »

humanrebar wrote: post #12

> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. Also, to provide good 'const' support in containers, you usually have to provide extra read…

> Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data.

  const std::set& s // This is a read-only view.
  const std::set  s // This is immutable.
> Another approach is to just declare member variables 'const'. So you have a 'const map' as a member variable. Except for that to work, you need to construct that member variable in the initializer list. The body of the constructor is too late. This likely means taking an already-initialized map as a constructor argument and copying it (probably exposing implementation details in the process) or writing a helper that returns the appropriate map type and copying it. Good optimizers will elide many or all of these copies, but relying on quality of optimizers isn't portable.

  Foo() : s(helper()) {} // This is a move, not a copy.

Re: Why I’m Frustrated with Go

#44

Post by thinbeige »

43224gg252 wrote: post #32
thinbeige wrote: post #27

Earlier quoted context omitted.

> I don't have much experience with elixir, but that's because I like to stay employed. While the previous commenter gave an objective and rational overview why he think Go gives him a hard time you can't resist to get polemic.

I gave rational counter arguments and employment is pretty important too imo. It seems a lot of the anti-Go people tend to favor languages that no one gets paid to use.

Yes, but the discussion wasn't about the employment situation and if--your tone was slightly inappropriate. You could have also written: "I've no experience with Elixir but your words catch my interest. The inferior Elixir enployment situation (compared to Go) held me back from Elixir. But I should give it a try."

Same message and nobody loses his face.

Re: Why I’m Frustrated with Go

#45

Post by rebolek »

jmaa wrote: post #31

Go was explicitly designed to be a simple language, without a rich tapestry of data structures to suit every use case. Languages are like tools. If you need a saw, use a saw, instead of complaining about the knife you are using.

No, languages are like toolboxes, they provide you with set of tools.

Re: Why I’m Frustrated with Go

#46

Post by nhumrich »

dvfjsdhgfv wrote: post #7

I personally tend to choose Go for newer projects as I'm looking for the efficiency of C and safety/elegance of more "modern" languages. However, I always keep an eye on D and Nim. It seems these are the only two languages that can compete with Go in both above aspects.

Go is nowhere near the speed of C. But why not consider Rust?

Re: Why I’m Frustrated with Go

#47

Post by kasey_junk »

alkonaut wrote: post #24

Having to encapsulate data to ensure read only semantics seems like par for the course from an OO perspective. In C# (which is 15ish years old at least) I don't think there has been an immutable map until very recently. Also (and this is probably a code style thing) I can't remember having reached for an immutable ordered map in a long career.

> I can't remember having reached for an immutable ordered map in a long career.

Me neither. But I have reached for a fast single producer, multi consumer queue, futures/promises, concurrent safe maps, non-blocking queues, and even plain async queues with batch semantics, many many times.

So either the author, me and everyone else that is claiming this is a problem are doing it wrong or its actually a problem.

Re: Why I’m Frustrated with Go

#48

Post by Sharlin »

user5994461 wrote: post #36
humanrebar wrote: post #12

> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. Also, to provide good 'const' support in containers, you usually have to provide extra read…

And java doesn't have them either. You need to use an external library, likely the google containers library.

Java does have unmodifiable wrappers but they implement the same basic mutable Map/List/etc. interfaces, just throwing at runtime if mutating methods are called. Not exactly optimal but better than nothing.

Re: Why I’m Frustrated with Go

#49

Post by kuschku »

user5994461 wrote: post #36
humanrebar wrote: post #12

> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map. Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. Also, to provide good 'const' support in containers, you usually have to provide extra read…

And java doesn't have them either. You need to use an external library, likely the google containers library.

But you can build and use generic immutable collections.

Re: Why I’m Frustrated with Go

#50

Post by atombender »

latch wrote: post #11

I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log +…

I don't like the "central exception handler" idea -- it is invariably too far away from the error site to do anything intelligent.

I do like Erlang's approach with hierarchical error domains ("processes" and "supervisor trees"), and I honestly think Go made a mistake here: The semi-recent introduction of Context acknowledges that a control hierarchy is present and an important part of a concurrent, distributed application and that there are aspects of this that need to flow through everything. The Context exists to permit a caller to call functions and launch goroutines that inherit deadlines, the ability to cancel their work, and so on. But this is a rather blunt and intrusive tool that could have been better solved by baking termination into the goroutine scheduling runtime. Of course, one reason goroutines cannot be forcibly terminated is because everything is mutable all over the place, but you could still have termination induce system-level errors that the goroutine would be forced to handle (or maybe you could safely induce a panic)... but that ship seems to have sailed a long time ago.

And yet a hierarchical approach similar to supervisor trees would have been awesome to have in Go. Managing hordes of complex, "crash only" goroutines in Go gets gnarly fast, and you tend to end up with your own ad-hoc type of supervisor trees that uses waitgroups and maps and what not to corral trees of composed workers to ensure they are all able to cancel, retry + back off, and time out appropriately. Even something like retry with backoff isn't part of the standard library, even though it's extremely core to distributed, concurrent programming.

I think I agree with Go's authors that exceptions are bad, but exceptions in an explicitly hierarchical, supervisor-type process model, where processes are "crash only", actually make sense. It means you tend to design your system into discrete parts consisting of dumb workers (that give up and crash on the smallest error) and slightly less dumb supervisors (that react to said crashes). It's not a panacea, but it's better than the loose, somewhat impoverished set of tools that Go gives you.

Post reply on HN