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

11–20 of 297 posts

Re: Everyday hassles in Go

#11

Post by sbergot »

lmm wrote: post #4

Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code. Map String Any Is that a function call? A type declaration? What's a parameter to what? The go style map[string]interface{} is, much as I love to hate on all things go, much clearer.

I disagree. You are merely used to different conventions. In haskell, symbols starting with an uppercase are types (or Constructors). You can think about Map as a type constructor which takes two other types as its arguments. So Map Foo Bar is a Map with Foo as keys and Bar as values.

In the go version [] is used for both indexing and type definition.

Re: Everyday hassles in Go

#13

Post by pothibo »

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 annoying at first, but then you understand by reading your code the places where error can occur or where you decided to ignore errors (By using _).

It's a different approach and it's refreshing.

Re: Everyday hassles in Go

#14

Post by dons »

lmm wrote: post #10
dons wrote: post #7

Earlier quoted context omitted.

There's nothing a priori clear about punctuation like [ ] { }, you're just used to seeing lots of syntactic markers.

Sure. But many languages have a standard way of defining what's a function declaration, what's a function definition, what's a type definition, what's a function parameter, what's a type parameter, what's a function call, what's a type instantiation; it doesn't really matter what the specifics are, what matters is that there are standard indicators that stand out from the code (and I think there is a sense in which […

> There are no visual handles to latch onto

Haskell uses syntax and context to distinguish identifiers as follows:

- variables, lower case initial letter

- constructors, upper case initial letter

- type variables, lower case initial letter

- type constructor, upper case initial letter

and similarly for classes and modules. And of course, white space is function application.

So you know if it is a variable or a constructor by looking at the first letter. And you know if it is a value-level variable or a type-level variable (or constructor) by context (types can only appear in certain places, e.g. on the right hand side of `::`).

But, yes, they all look like words. They're not ambiguous though. :)

Re: Everyday hassles in Go

#15

Post by sbergot »

lmm wrote: post #10
dons wrote: post #7

Earlier quoted context omitted.

There's nothing a priori clear about punctuation like [ ] { }, you're just used to seeing lots of syntactic markers.

Sure. But many languages have a standard way of defining what's a function declaration, what's a function definition, what's a type definition, what's a function parameter, what's a type parameter, what's a function call, what's a type instantiation; it doesn't really matter what the specifics are, what matters is that there are standard indicators that stand out from the code (and I think there is a sense in which […

I understand this feeling, but it goes away after a bit of practice.

In java/go/c#, there are lots of statement and small expressions. In haskell expressions tends to be longer and are broken down in multiple local definitions (with let or where).

You learn to recognize important words (fmap, forM_, $, etc). You also learn to recognize how those words are associated, and how data is passed around.

Granted, there are people who abuse point-free notation to build complex and hard to read expressions. However I find that a codebase with rich informative types and a reasonable coding rule set is very pleasant to read.

Re: Everyday hassles in Go

#16

Post by nhaehnle »

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

Re: Everyday hassles in Go

#17

Post by erglkjahlkh »

NateDad wrote: post #12

"Why Go is not Haskell"

While I understand your comment, I have to disagree.

Programming languages should be kind of boring, and support the average developers' work. That is why Haskell will ultimate fail and fade away - most of the developers on this planet are simply not skilled enough to touch any of that stuff. Attempting to add all Ninja concepts to a language will just lead to a massive failure.

Go does a very good job on forcing even the most average developers to reach surprisingly succinct and elegant solutions. However, the lack of generics really forces in some situations to either use the reflection or stop being very DRY or elegant. Go wouldn't have to implement full generics to fix that. Just adding something similar to what interfaces are to methods for variables would do, without the rest of the moving parts.

Re: Everyday hassles in Go

#18

Post by bojo »

vegabook wrote: post #9
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 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.

Re: Everyday hassles in Go

#19

Post by ufo »

lmm wrote: post #4

Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code. Map String Any Is that a function call? A type declaration? What's a parameter to what? The go style map[string]interface{} is, much as I love to hate on all things go, much clearer.

> Is that a function call, A type declaration?

If its following a "::" then its part of a type signature and its a type constructor application. Otherwise, its part of an expression and its a regular function call.

BTW, Haskell capitalization is significant in Haskell. Identifiers starting with lower case are always regular functions. Types and type constructors always start with upper case.

> What's a parameter to what?

Application in Haskell is left associative so its

    ((Map String) Any)
Haskell is a functional language and programs are filled with function applications so using spaces for function application avoids a lot or syntactic noise. The only time I find this really bites me is that, due to automatic currying, passing the wrong number of arguments to a function can lead to hairy type errors. This is not a big deal if you use add a healthy amount of type annotations to your code though.

Re: Everyday hassles in Go

#20

Post by NateDad »

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".
Post reply on HN