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

151–160 of 233 posts

Re: Why I’m Frustrated with Go

#151

Post by ludwigvan »

tannhaeuser wrote: post #104
_urga wrote: post #42

Earlier quoted context omitted.

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.

Speaking of Node in the context of error handling, what are current best practices in Node (other than running node-forever respawning)? Up to v0.12, Node used to have heuristic cleanup code for file handles and other resources on exception domain error handler execution, but the domain API has been deprecated for some time now ([1], [2]). [1]: " rel="nofollow">https://nodejs.org/api/domain.html> [2]: " rel="nofollow…

This is pretty informative on handling errors in node: https://www.joyent.com/node-js/production/design/errors

Re: Why I’m Frustrated with Go

#152

Post by fiddlerwoaroof »

rumcajz wrote: post #78
fnord123 wrote: post #71

Earlier quoted context omitted.

>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 + "sorry, try again"). You are correct that this is how it's often done - 9 out of 10 errors probably ARE "handled" by a central error handler. But this is an incorrect approach if the goal is a reduction of catastrophic errors. In the following paper, "Simpl…

Depends on the app. In GUI, yes, why not, display an error message and you are done. In infrastructure software, OTOH, you want to handle errors in thoughtful manner. If you can't it's often better to crash the application than to continue with broken state.

I think the distinction between errors (bugs) and exceptional situations made here[1] is important: if you have a problem because of some transient condition (an exceptional situation like a network outage or a full filesystem) then it makes sense to try to recover somehow. If you hit an error (i.e. A programming error or a bug) all you can do is abort, since you can no longer trust that the program will do the right thing.

[1]: http://joeduffyblog.com/2016/02/07/the-error-model/

Re: Why I’m Frustrated with Go

#153

Post by brango »

Go's been great for creating a web scraper. But it's been an unmitigated disaster for being able to write the data to a database due to the immaturity of ORMs.

Might as well not pretend something is an ORM if it can't do the fundamentals (like upserts), fully hydrating structs, etc.

Re: Why I’m Frustrated with Go

#154

Post by gipp »

jondubois wrote: post #142

It's so interesting how the hype cycle works. Only 1 year ago, people on HN were bashing Node.js hard and saying that you should use Go instead and everyone was praising Go. Now it seems everyone is bashing Go. Moral of the story; never buy into the hype whether it is positive or negative. I think that Go is just fine and so is Node.js. Maybe the author of the article makes a valid point, but no language is perfect a…

I've been reading HN for a couple years now and can't recall there ever being a consensus positive opinion about Go. All the discussions pretty much looked like this one.

Re: Why I’m Frustrated with Go

#155

Post by vbezhenar »

pebers wrote: post #112

> 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. Java doesn't do that well at all though; its immutable maps can be used in place of mutable maps, since there's no way of having a Map interface that extends ImmutableMap to add extra operations, so you can get nasty runtime surprises if you've got the wrong one. Conversely, if…

Java does it well, you can easily make good immutable map interface. The problem is with Java Collections which is just a poorly designed library, like most other standard Java libraries.

I really hope that someone will use JVM with another built from the ground sane library.

The only thing Java misses is covariance/contravariance for generics, but with some unsafe casting it'll work.

Re: Why I’m Frustrated with Go

#156

Post by andreasgonewild »

Young_God wrote: post #143

In addition to what you describe, my other big complaint with Go is the attitude you find from the devs, in threads discussing these types of challenges. "Oh, you think you want an ordered map? No you don't. Your reasons are stupid. You're stupid. Now gtfo and start using Go to write things we deem to be respectable."

Agreed, one of the most dogmatic communities I've had the misfortune of stepping into. But then that's pretty much a requirement given the amount of pretending they need to pull off to keep their bubble intact.

Re: Why I’m Frustrated with Go

#157

Post by rufugee »

dullgiulio wrote: post #41
43224gg252 wrote: post #18

Earlier quoted context omitted.

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

The problem I've found it that you might wrap errors this way, but the libraries you use don't, or approach it differently. So you're either chasing down strings that may or may not be grep'able or you're fighting with delve to track down what's happening. The whole error situation with Go is one of the main drawbacks of the language imho.

Re: Why I’m Frustrated with Go

#158

Post by KallDrexx »

atombender wrote: post #50
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 applic…

I don't think a central exception handler means ONLY handle exception in one very specific point. It means that if you can handle an error handle it, otherwise let the central exception handler handle it.

I really like Elixir and the Erlang VM but supervisor trees are not a perfect solution either. For all the talk about how in Erlang you just let things fail and don't have to do defensive coding, any non-trivial application requires a lot of very thorough design on how to handle error scenarios and keep your application consistent.

If a process fails too many times too often (say your web service it's trying to ping is inaccessible) it can take out your whole supervisor. If that supervisor is holding an ETS table that holds important coordination data (but not data that requires persistence) that ETS table (and all it's data) is now completely gone, and unless that case has been handled you have a lot of processes running but not doing what they should be doing, and your application is inconsistent until you completely shut it down and restart it.

And if you don't plan for a lot of these scenarios then you will be caught completely surprised when it happens in production.

Re: Why I’m Frustrated with Go

#159

Post by xfer »

JamesMcMinn wrote: post #147
xfer wrote: post #125

Earlier quoted context omitted.

You are still talking about immutable data structures, which has nothing to do with generics.

No, YOU are still talking about immutable data structures, where as I am talking about the need to write boilerplate code in Go due to lack of Generics. The blog posts topic was not "immutable data structures", rather the need for boilerplate code in Go because of the lack of generics. The particular example was one of immutable data structures, however that was an example rather than the topic. The author themselves…

The comment i replied to :

> No, Generics make it possible to create a generic immutable data structure

I am sure i can read.

Re: Why I’m Frustrated with Go

#160

Post by brango »

user5994461 wrote: post #40
andreasgonewild wrote: post #2

Go contains many good ideas that may be carried over to more pragmatic languages. Using it for anything beyond simple, self-contained command-line tools and network servers never really worked out for me. And that makes sense, since it was explicitly designed to scale over groups of inexperienced developers at any cost; the opposite of my needs. Modern C++ runs circles around Go for more complex software, and it prov…

So... Go is excellent to write the software it was designed to write and it's no good at other things.

Which is fine if you happen know what it was designed for prior to starting your project, and can also be 100% sure your project will never mutate into anything else...
Post reply on HN