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

91–100 of 297 posts

Re: Everyday hassles in Go

#91

Post by threeseed »

vardump wrote: post #51
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.

You don't need to configure the JVM as in many cases the defaults are fine. And most of the frameworks in use today do not require an application server.

Go is definitely simple. But I wouldnt characterise modern day Java development as being that complicated.

Re: Everyday hassles in Go

#92

Post by rjberry »

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.

All loops encode simple logic? I don't think that's true.

Either way, a very good reason for not using loops is to make code more readable. If I see a loop I have to run it inside my head to figure out what the intent is, and if there's multiple things going on, that can take time. If I see a 'map' I think "right, this is tranforming every element in this list in this way"; if I see a filter, I think "right, this is removing elements in this list that don't satisfy this property", if I see a groupBy, I think "right, this is grouping elements in this list by this property", etc., etc.

Code isn't only more succinct, it's more human friendly.

Re: Everyday hassles in Go

#93

Post by im_dario »

colin_jack wrote: post #72
im_dario wrote: post #39

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

"I realized that if you miss generics in Go, your code is trying to cope with too much." Was wondering what you mean by that (not disagreeing just interested)?

I meant that if you miss generics, your code is probably too complex.

Re: Everyday hassles in Go

#94

Post by jbooth »

rjberry wrote: post #77
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…

I dislike it when people say languages are either 'practical' or 'well designed'. As if a language is only useful if it's not built on sound mathematical ideas ... Generics are not a particularly new idea and nobody who uses language that implement them yearn for the days when they weren't around. See Paul's post on the idea that 'worse is better': http://pchiusano.github.io/2014-10-13/worseisworse.html

The point is that you reach an area where the mathematical ideas don't map perfectly to the underlying functionality you're providing.

You can make your language "unsound" by violating those mathematical principles, or you can make something like the I/O monad. It is indeed "soundness" vs "practicality".

EDIT: Oh, and that link seems to have misunderstood the 'worse is better' philosophy -- C++ isn't the champion of 'worse is better', C is.

Re: Everyday hassles in Go

#95

Post by tarikjn »

rcarmo wrote: post #68
tarikjn wrote: post #61

I couldn't agree more with this article. I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functiona…

Have a go at Hy (hylang.org). You can have your cake and eat it too. :) Other than that, I'm fiddling with LISP Flavored Erlang (lfe.io), but I've had previous Erlang exposure.

That looks pretty interesting, but I don't have that much experience with Python, so the benefits are diminished.

I am looking for a runtime which can take full advantage of multiple cores for a single program, something I believe Python would fall short at.

Re: Everyday hassles in Go

#96

Post by threeseed »

bojo wrote: post #18
vegabook wrote: post #9

Earlier quoted context omitted.

I have to say that I am tempted by Go precisely because I see a lot of comments like yours, namely, it seems just to "work" in a very simple way. I find myself somewhat overwhelmed by the avalanche of new language opportunities I am supposed to invest time in. Most seem to have this huge kitbag of functionality and they seem to merge into each other making it quite confusing which I should go to, and with technologie…

Go is the most boring language I have ever coded in, and that is why I love it. Sure, it doesn't have some fancy bells and whistles people seem to want, but when you can sit down and write something functional, portable, and readable fairly quickly, I'd say that is a huge win.

You know you could replace "Go" with "Java 1.0" and your comment would still be accurate. Funny that.

Re: Everyday hassles in Go

#97

Post by rjberry »

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…

It's not really a different approach. You had to write a lot of vanilla loops in C, too.

Re: Everyday hassles in Go

#98

Post by wtf_is_up »

tarikjn wrote: post #61

I couldn't agree more with this article. I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functiona…

> I am looking for a replacement programming language to solve small problems for which Python/Ruby would have traditionally been used, good file system, stream and networking APIs, but concurrency as a first class citizen, garbage collected, fast startup time.

You just described Go, mostly. I can't think of a more fitting language given your stated requirements.

To your first point: I don't know what Go has to do with your preference of functional programming to imperative. Go doesn't claim to be a functional language so I just am not seeing the connection.

Re: Everyday hassles in Go

#99

Post by [deleted] »

tarikjn wrote: post #61

I couldn't agree more with this article. I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functiona…

[deleted]

Re: Everyday hassles in Go

#100

Post by NateDad »

frou_dh wrote: post #47
NateDad wrote: post #37

Earlier quoted context omitted.

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

> 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. This compiles: package main import "errors" func main() { x, err := f() if err != nil { return } y, err := g() h(x, y) } func f() (x int, err error) { return 1000, nil } func g() (y int, err error) { err = errors.New("boo"); return } fun…

Pretty sure errcheck will catch that too. The thing that bugs me is the people that make up problems that are not at all problems in real day to day coding.
Post reply on HN