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

Why Go gets criticized so much

npf.io

Post reply on HN
Print view View original

231–240 of 251 posts

Re: Why Go gets criticized so much

#231

Post by jrobn »

spinlock wrote: post #122
jrobn wrote: post #106

One of Go's selling points is always it's a pragmatic language. But after using it for awhile and implementing a few web apps and APIs in it. I've crossed it off my list for web app or API development. It's great at making standalone CLI tools, however. I've since moved to using Elixir (erlang) for web app stuff (even some scripts) and I am much happier. I'm not in love with Elixirs syntax, but it's nice and includes…

What's the performance of Elixir been like for you? We're looking into it because of the actor concuttrncy model which we think will be much more performant than our current ruby or clojure solutions.

It's great at IO. Period. Get a request, pipeline it, transform it, call out to a database, get some data back, fire off emails, talk to third party APIs....

All of those can be structured as processes. All of those can be independently fault tolerant. All of those can be inspected while they are running...in production. Seriously, for HA APIs or web apps it feels like a no brainer.

I just wouldn't us it for things that are CPU bound, like image processing for example. Try implementing something that is a bottleneck in your system in elixir and then throw some data at it and see how it performs.

Elixir + Phoenix is a real treat for web app devs.

Re: Why Go gets criticized so much

#232

Post by kavehmz »

innocentoldguy wrote: post #75

The main problem with Go, and this is a deal breaker for me, is that it forces opening curly braces onto the same line, instead of putting them on a line by themselves. This is clearly wrong, and flies in the face of curly good taste.

One reason I love Go for it. Look, it will prevent the replies you got, while I am thinking about solving a problem. :)

Go forces one format. Although you definitely can ignore formatting your code and just compile it. It won't fail.

Re: Why Go gets criticized so much

#233

Post by nostrademons »

qihqi wrote: post #140
Lewisham wrote: post #110

Disclaimer: I work at El Goog. I recently moved teams so that I could use Go exclusively. It's often been said that Go solves the problems Google developers have, and it's 110% true. It's much easier to get things working, and it's much easier to write things like Protocol Buffers. But the key for me is that Go isn't fun in the sense of "wow, I'm so smart that I managed to one line this thing", it's fun in the "wow I…

Indeed Go is a pretty good "Google Language". It almost google's C++ with it's C style guide baked into the language. For almost every feature in Go (or lack of thereof), I can find a line in the C style guide saying the very same thing. (ban of exceptions, rvalue references, don't include what you don't use, CHECK vs. panick... etc) (Though yet many teams didn't adopt Go. Because if none of your teammembers has Go r…

"Those guys are not very pleasant to deal with."

I got Go readability more than 2 years ago, right before I left Google, but in my experience the Go team was very pleasant & professional. Has that changed?

Re: Why Go gets criticized so much

#234

Post by kazinator »

jb613 wrote: post #73
gizmo wrote: post #28

I think there is a better explanation for why people dislike Go. All programming languages currently used for the web have gigantic downsides. They're slow. They have terrible package management. They have poor standard libraries. They have no static typing. They have no visual debuggers. They have no good IDE support. They don't integrate well with frontend code. Some programming languages are more flawed than other…

"The lack of exceptions makes writing correct code really tedious." Tedious up front often translates into time saved down the road. Exceptions are often an easy way out while accruing future debt. Unfortunately, our industry cannot easily measure the time saved down the road and so cannot properly value it. However, many with long term interests in a project will often spend on the "tedious" costs up front to avoid…

Lack of non-local dynamic control transfers with unwinding is the real deal breaker.

Exceptions are a red herring; they are just something you can build if you have dynamic control transfers with unwinding. And if you have macros, or at least some kind of access to the language to bend the syntax. Plus perhaps other goodies like testing whether some object X is of a type which is a subtype of T so you can make exception handling frames decide whether the elevator stops here.

The underlying control mechanism not being there makes the language crippled.

Just give me C. Then I also have forty years of research out the window: but but at least with setjmp and longjmp.

How does Bash recover to the top level prompt when the scriptage fails deeply nested in some function calls? Why, longjmp! I will fake the unwinding if I have to.

Re: Why Go gets criticized so much

#235

Post by kazinator »

jb613 wrote: post #161
mononcqc wrote: post #153

Earlier quoted context omitted.

The general principles for fault tolerance require Separation of Concerns vis. Error Encapsulation (make sure that the contagion doesn't spread), Fault Detection (make sure that you know that someone is infected), and Fault Identification (you have ebola!). Error encapsulation (and this applies equally to modules, components, systems, architectures, organizations) is invariably best done at the lowest level possible,…

"The problem with handling everything right away is that it lacks flexibility to handle things in what could be the optimal manner." You can pass the error (or another) up the stack. The language is flexible.

> You can pass the error (or another) up the stack.

(C++-like) exceptions pass the error up the stack. Directly to the right place, and ensuring that clean-up takes place along the way without tons of repeated test-and-bail code.

Lisp-like are one better: the stack is searched for a binding to a function which handles the error, and then a new call is generated to that function. If the function returns, the search for the next possible one continues. Or the function can then look for a restart point somewhere the stack (the entire stack still being intact), and perform a dynamic non-local transfer (a big return) to that point.

Dumb error return values make it very easy for an error to disappear without being handled. Oh, the caller has a few things to do before returning your value (things such as clean up that could be an unwind block!) and fumbles the ball somehow, and ends up returning a different value: the information is altered like in the telephone game.

That's the problem: every function level between the source of the situation and the place where it is to be handled intercepts the handling effort by being involved in the control flow. When it should just be getting the heck out of the way (like cars pulling to the side when they hear an ambulance).

Bubbling up error values is an excellent example of an "Anti Pattern".

Re: Why Go gets criticized so much

#236

Post by prodigal_erik »

jb613 wrote: post #73
gizmo wrote: post #28

I think there is a better explanation for why people dislike Go. All programming languages currently used for the web have gigantic downsides. They're slow. They have terrible package management. They have poor standard libraries. They have no static typing. They have no visual debuggers. They have no good IDE support. They don't integrate well with frontend code. Some programming languages are more flawed than other…

"The lack of exceptions makes writing correct code really tedious." Tedious up front often translates into time saved down the road. Exceptions are often an easy way out while accruing future debt. Unfortunately, our industry cannot easily measure the time saved down the road and so cannot properly value it. However, many with long term interests in a project will often spend on the "tedious" costs up front to avoid…

It's not just up front. You only have to write the tedious and repetitive code once, but you have to keep reading it forever, because the code you care about is scattered here and there in the middle of it.

Re: Why Go gets criticized so much

#237

Post by jb613 »

kazinator wrote: post #235
jb613 wrote: post #161

Earlier quoted context omitted.

"The problem with handling everything right away is that it lacks flexibility to handle things in what could be the optimal manner." You can pass the error (or another) up the stack. The language is flexible.

> You can pass the error (or another) up the stack. (C++-like) exceptions pass the error up the stack. Directly to the right place, and ensuring that clean-up takes place along the way without tons of repeated test-and-bail code. Lisp-like are one better: the stack is searched for a binding to a function which handles the error, and then a new call is generated to that function. If the function returns, the search fo…

Not handling an error from something you called into will lead you to be bypassed when it jumps "directly to the right place".

Re: Why Go gets criticized so much

#238

Post by kyrra »

sievebrain wrote: post #143
Lewisham wrote: post #110

Disclaimer: I work at El Goog. I recently moved teams so that I could use Go exclusively. It's often been said that Go solves the problems Google developers have, and it's 110% true. It's much easier to get things working, and it's much easier to write things like Protocol Buffers. But the key for me is that Go isn't fun in the sense of "wow, I'm so smart that I managed to one line this thing", it's fun in the "wow I…

The reason Google's Java codebase is impossible to understand is not the language, it's mindless application of 'best practices' like dependency injection on an industrial scale. Guice is open source, anyone can go look at it. Just imagine a big complex server in which the "new" keyword wasn't used anywhere because everything was handled by the dependency injector. You get these things: 1. Things that should be compi…

I will point out that the run time problems of guice are trying to be solved with dagger: http://google.github.io/dagger/

Re: Why Go gets criticized so much

#239

Post by kjksf »

kazinator wrote: post #234
jb613 wrote: post #73

Earlier quoted context omitted.

"The lack of exceptions makes writing correct code really tedious." Tedious up front often translates into time saved down the road. Exceptions are often an easy way out while accruing future debt. Unfortunately, our industry cannot easily measure the time saved down the road and so cannot properly value it. However, many with long term interests in a project will often spend on the "tedious" costs up front to avoid…

Lack of non-local dynamic control transfers with unwinding is the real deal breaker. Exceptions are a red herring; they are just something you can build if you have dynamic control transfers with unwinding. And if you have macros, or at least some kind of access to the language to bend the syntax. Plus perhaps other goodies like testing whether some object X is of a type which is a subtype of T so you can make except…

Go has panic()/recover(), which is better than setjmp/longjmp (thanks to GC you won't leak memory like you would in C with setjmp/longjmp).

I'm not saying using panic()/recover() is a good idea but if your issue with Go is lack of non-local dynamic control transfer then good news: you're mis-informed and Go will be great for you!

Re: Why Go gets criticized so much

#240

Post by fidz »

fixermark wrote: post #147
gizmo wrote: post #28

I think there is a better explanation for why people dislike Go. All programming languages currently used for the web have gigantic downsides. They're slow. They have terrible package management. They have poor standard libraries. They have no static typing. They have no visual debuggers. They have no good IDE support. They don't integrate well with frontend code. Some programming languages are more flawed than other…

> A web service is not a device driver where every edge case has to be carefully considered. Yikes, that's an assumption that is going to bite you hard in your career. I recommend escaping it as soon as possible. ;) The web is full of horror stories from people who assumed their part of a web-accessible product wasn't on a critical security / safety / reliability path. I used to use Python and Ruby on Rails for web s…

> I used to use Python and Ruby on Rails for web services; this is precisely why I left them. I got tired of dealing with typos becoming runtime exceptions.

That is why you must do 100% code coverage on all non-compiled language.

Post reply on HN