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

31–40 of 297 posts

Re: Everyday hassles in Go

#31

Post by rtpg »

NateDad wrote: post #20
pothibo wrote: post #13

One thing that is perhaps counter intuitive is how you do a lot of for loops compared to other languages (Compiled/Statically typed included). Once you let go your previous expectations, Go gets a lot nicer to use. The amount of for loops you will write will also makes it obvious when you start doing O(n^2) operations in your methods. Same can be said with variables declaration and error verifications in Go. They are…

Yeah, it seems like a lot of the criticisms of go boil down to "I don't like writing simple loops".

maps and filters are things that have existed for a long time, and are extremely commonplace. They are also very representative of common operations in programming.

Not having generics means we can't properly build these ourselves, and Go doesn't offer list comprehensions, so instead we're forced to for loop.

Re: Everyday hassles in Go

#32

Post by NateDad »

nine_k wrote: post #23
NateDad wrote: post #20

Earlier quoted context omitted.

Yeah, it seems like a lot of the criticisms of go boil down to "I don't like writing simple loops".

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.

Re: Everyday hassles in Go

#33

Post by mrweasel »

aikah wrote: post #22
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…

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

Re: Everyday hassles in Go

#34

Post by spion »

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 humans, but that is what compilers and tooling are for - to point out our mistakes and help us get it right

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

Re: Everyday hassles in Go

#35

Post by kasey_junk »

lmm wrote: post #8
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…

I don't think Java will get many defenders here. But try that in Scala, with Spray. There're a couple of lines of boilerplate to create the actor system, but that's about all. And you get a system that's flexible enough to let you write route definitions that look like a config file, but everything's typesafe. Your routes are just functions, you can refactor them like ordinary code. So too are the kind of "cross-cutt…

> use some kind of "magic"

No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window.

You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Are you going to make a fat jar? If not, how are you doing dependency resolution? Is your build artifact something that sbt does out of the box or slightly different (lord help you if it is)? Are you going to do ivy, s3, or maven resolution?

All of that complexity falls away with golang and this is a conscious choice of the golang team. I have lots of things I love about Scala and lots of things I hate about golang, but from a "get simple web service out the door in a scalable way" golang wins hands down.

Re: Everyday hassles in Go

#36

Post by kasey_junk »

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.

You can say the same thing about every language feature there is. Of course it is possible to develop software without some particular feature, it's whether the benefits of the feature out way it's costs. With generics, most of the world has decided to land on the side of wanting them. Even golang has them, just not for users.

Re: Everyday hassles in Go

#37

Post by NateDad »

frou_dh wrote: post #25
pothibo wrote: post #13

One thing that is perhaps counter intuitive is how you do a lot of for loops compared to other languages (Compiled/Statically typed included). Once you let go your previous expectations, Go gets a lot nicer to use. The amount of for loops you will write will also makes it obvious when you start doing O(n^2) operations in your methods. Same can be said with variables declaration and error verifications in Go. They are…

> ... error verifications in Go ... you understand by reading your code the places where error can occur or where you decided to ignore errors (By using _) This compiles: package main import "errors" func main() { f() println("hello erroneous world") } func f() error { return errors.New("boo") }

Which you can catch with a linter like https://github.com/kisielk/errcheck. Errors in Go are just values. There's nothing "more wrong" about ignoring a return value that is an error or one that is file handle, for example. And in cases where a function returns an error and a value (where the error generally indicates the validity of the value), you'll get a compile error if you don't check the error. That's pretty good for basically zero overhead.

Re: Everyday hassles in Go

#38

Post by TazeTSchnitzel »

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.

Java would be a lot nicer to work with had it had generics from the beginning.

Re: Everyday hassles in Go

#39

Post by im_dario »

This article has some good points but I'm going straight for the first one: I don't miss generics.

Indeed, they are useful. I use them in Java every time I find a good reason to do it. So, I should say in another way: I don't miss generics in Go.

Given my experience [0] in Go in the last years, I realized that if you miss generics in Go, your code is trying to cope with too much.

I didn't miss them when I developed Mergo [1], a simple library to merge structs. I think we all agree if we should rewrite this in Java (or other language with similar type system) we would use generics at some point.

[0] https://github.com/imdario?tab=repositories

[1] https://github.com/imdario/mergo

Re: Everyday hassles in Go

#40

Post by NateDad »

rtpg wrote: post #31
NateDad wrote: post #20

Earlier quoted context omitted.

Yeah, it seems like a lot of the criticisms of go boil down to "I don't like writing simple loops".

maps and filters are things that have existed for a long time, and are extremely commonplace. They are also very representative of common operations in programming. Not having generics means we can't properly build these ourselves, and Go doesn't offer list comprehensions, so instead we're forced to for loop.

Yes, loops, just like we learned in CS101.
Post reply on HN