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

Everyday hassles in Go

crufter.com

Post reply on HN
Print view View original

51–60 of 297 posts

Re: Everyday hassles in Go

#51

Post by vardump »

bsaul wrote: post #2

Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience : After having implemented a mini web services in go and being fed up with its limited type system, i decided to stop coding in go and start recoding my project in java using what is often advertized here as the most minimal framework : dropwizard. Well, i downloaded the framework, configur…

Not to mention deployment. No JVM to configure. Or application server...

Minimally, just drop the binary and an init.d script. Feel free to use something fancier for manageability etc., the point was the simple option is available.

Re: Everyday hassles in Go

#52

Post by TeeWEE »

While the author has a lot of valid points, he forgets the goal of Go. Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python.

The tradeoff in these designs are to prevent tuple types, always keep using structs, prevent using algebraic types over structs. Allow for nil, but try prevent common Null errors etc.

Haskall is theoretical a much better language. But Golang was designed to be practical & simple over being mathematically sound, and theoretical better.

Re: Everyday hassles in Go

#53

Post by nine_k »

NateDad wrote: post #32
nine_k wrote: post #23

Earlier quoted context omitted.

Rather, I don't like to copy-paste and slightly modify simple loops over and over again. Abstraction is a basic tool of programming; where has it gone?

They're simple loops. You don't need to copy and paste, you just write them out because it's just ridiculously simple logic. Just like you don't copy and paste if statements.

Ridiculously simple and wordy. Exactly the stuff the computer should do for me.

Re: Everyday hassles in Go

#54

Post by friendly_chap »

nhaehnle wrote: post #16

> For those who are bothered about the exponential algorithmic complexity of nub There is nothing exponential about nub. Given only equality comparisons, detecting and eliminating duplicate elements requires quadratic running time.

You are right! Others noted that mistake as well.

Re: Everyday hassles in Go

#55

Post by Iftheshoefits »

mrweasel wrote: post #33
aikah wrote: post #22

Earlier quoted context omitted.

> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive. Or why expose this interface {} feature and allow people to use it in a statically typed language? Peo…

Are generics really that important? Java didn't have generics for 9 or 10 years, C# only got them in version 2. C still doesn't have generics and I never heard anyone complain. As a former C# developer I would agree that life got easier with the introduction of generics, but you can develop the exact same software with and without generics.

Depends on what you mean by "important." You noted yourself that "life got easier" once the language you used introduced generics.

Generics can drastically reduce the time required to implement features because less time is spent on re-implementing (nearly) identical algorithms for different data structures and more on simply using them to write something that works.

The cost paid for this is usually in the form of minor efficiency hits because data-specific efficiencies aren't exploited.

Also, consider me complaining about C's lack of generics. It is in fact the primary reason I prefer C++. If C had robust generics with reasonable syntax I'd strongly consider using it instead of C++.

Re: Everyday hassles in Go

#56

Post by friendly_chap »

NateDad wrote: post #46
friendly_chap wrote: post #21

Earlier quoted context omitted.

Author here. I think that is a very valid point. However, a lot of features I mentioned are present in other imperative languages, like Rust. The Go authors however picked other solutions I consider inferior, hence the article.

It seems like Rust is what Go would become of you added all the Haskell-ness to it. Which is fine, but we already have Rust. So... Maybe we should be asking what Rust is missing from Go? Or if Rust is good enough, just use that.

Well Rust became production ready well after Go and the low level focus it has doesn't match my problem domain. I have the luxury of not caring about the constraint of a single consumer box - hacking mostly on backend stuff living in the cloud, so all those pointer types for example would only get in my way.

Re: Everyday hassles in Go

#57

Post by dalke »

mrweasel wrote: post #33
aikah wrote: post #22

Earlier quoted context omitted.

> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive. Or why expose this interface {} feature and allow people to use it in a statically typed language? Peo…

Are generics really that important? Java didn't have generics for 9 or 10 years, C# only got them in version 2. C still doesn't have generics and I never heard anyone complain. As a former C# developer I would agree that life got easier with the introduction of generics, but you can develop the exact same software with and without generics.

C11 added the _Generic keyword, so someone must have complained. A common complaint is the desire to have, say, cos(x) work on floats, doubles, and long doubles rather than calling respectively cosf(), cos(), cosl().

Re: Everyday hassles in Go

#58

Post by gws »

Every time I read an article criticizing Go I end up appreciating it even more.

Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax.

Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when the former are so difficult to read, figure out what they really do, what is the performance cost, debug...

Maybe it's because of the bogus examples they give like criticizing

> file, _ = os.Open("file.txt")

> file.Chmod(777)

for not handling explicitly a possible error when it's just because the example is ill written and the proper code is

> file, err = os.Open("file.txt")

> if err != nil {

> ... handle error ...

And here I stopped reading the article, it's always the same arguments over and over: more elegant and complex code vs. the un(cool) but oh my, so much simpler Go code.

What I find really amusing though it's how people are so smug in their writing, pointing out the "obvious errors" (billion dollar mistakes!) that the Go authors made and their "ignorance" of proven modern programming language constructs they could implement in Go.

There are two possibilities here, pick your preferred one.

1) Pike, Thompson & co. made obvious errors in designing Go because of their ignorance of programming languages and/or ineptitude

2) These bloggers claiming obvious errors in Go design don't really fully understand the trade-offs involved in what they ask for and ignore the fact that the Go authors have carefully thought about them and optimized accordingly

I will go back to programming in Go, I'd take writing for loops all the time vs. writing a one liner in Haskell and then agonize over using the lazy or strict version of it :)

Re: Everyday hassles in Go

#59

Post by blowski »

spion wrote: post #34
kator wrote: post #3

"Every computer language is an imperfect way of describing a potential solution to a poorly understood problem" -- Me I find it interesting when people wax poetic about how one language is better than another and how if we just did x, y or z then we'd have this perfect solution. That said I appreciate the author's write-up of some challenges with Go. In the end the reality of any "product" is building what the user's…

> This is the nature of our business, to constantly do battle with poorly understood problems using imperfect tools in a world where we are fooled into thinking everything is black and white because at the core of our technology everything is a 0 or a 1. Isn't that extremely sad though? We finally have a perfectly precise tool, yet we keep building gooey piles of uncertainty on top of it. Sure we're just imperfect hu…

> I'm hoping that in the next 5-20 years Rust and Haskell (and later Idris) will change everything.

Unfortunately, they won't. These problems are not a 'bug' of current languages, but the inherent nature of the problem. At some point, the perfectly precise world of computers has to meet the messy world of user requirements. As a programmer, my job is to translate one into the other, within the constraints applied by whoever is paying the bill.

Re: Everyday hassles in Go

#60

Post by kasey_junk »

TeeWEE wrote: post #52

While the author has a lot of valid points, he forgets the goal of Go. Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python. The tradeoff in these designs are to prevent tuple types, always keep using structs, prevent using algebraic types over structs. Allow for nil, but try prevent common Null errors etc. Haskall is theoretical a much better language…

> Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python.

I'd like to see a citation for this as I've never seen this as a stated goal of golang. In fact, if it were the stated goal that is one of the most damning arguments against golang as it very clearly fails at this task.

I've been under the assumption that golang was designed to make writing/deploying/managing simple web services across a wide variety of machines and across a wide variety of teams. While I'm still reserving judgement on it accomplishing this goal, I'd say it is much more likely to accomplish this than trying to have similar power to python.

Post reply on HN