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

Three Months of Go from a Haskeller’s perspective (2016)

memo.barrucadu.co.uk

Post reply on HN
Print view View original

21–30 of 162 posts

Re: Three Months of Go from a Haskeller’s perspective (2016)

#21

Post by lmm »

TeeWEE wrote: post #18

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is bui…

> Often short dense code with complex types is just really hard to read for your overage joe programmer.

I think people make the mistake of measuring how long it takes you to read x lines, when really you need to measure how long it takes to read x functionality.

There've been times when I replaced a 200 line class with 4 lines of Scala. Those lines were very much the kind of complexly-typed code that people attack Scala for. It took time and effort to understand what they did. But they were still a lot more maintainable than a 200 line class.

Re: Three Months of Go from a Haskeller’s perspective (2016)

#22

Post by greyman »

TeeWEE wrote: post #18

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is bui…

I agree with the first sentence, and that I found is one of the strongest points of Go. That you can look at your colleague code and be almost sure what it does, there just aren't hidden traps or clever hacks. It's always the same "dull" code, telling you in plain language what is happening.

Re: Three Months of Go from a Haskeller’s perspective (2016)

#23

Post by lmm »

mappu wrote: post #2

(2016) The versioning and slice sorting have since been solved, by go.mod and sort.Slice respectively. The problem with "Make it an error to not initialise a struct field" is you lose source compatibility when adding new struct fields.

> The problem with "Make it an error to not initialise a struct field" is you lose source compatibility when adding new struct fields.

If you allow the struct definition to specify a default value then the struct author can set default in the cases where there is a sensible default, and leave it compile-time incompatible in the cases where there really is no good default and the person doing the upgrade needs to make a decision.

Re: Three Months of Go from a Haskeller’s perspective (2016)

#24

Post by eru »

dragosmocrii wrote: post #16
kjksf wrote: post #10

Apparently, the author of this blog post had a change of heart: https://memo.barrucadu.co.uk/blub-crisis.html > I have realised in recent conversations about programming languages, and in reflection of my very negative and kind of arrogant blog post about Go, that I have become trapped by the Blub Paradox. I have become dismissive of non-Haskell languages. I think in Haskell. Languages less powerful than Haskell are…

My Blub language has been PHP. While the language has been getting better over the years, especially with the introduction of types, I still felt at one point that I wasn't growing. I had a try at Haskell, and failed miserably. I tried OCaml, but still something felt unnatural to me, although what really intrigued me was the sound type system and the guarantee that if it compiles, then it's probably going to run well…

Erlang has some type annotations. Not sure whether they made it over to Elixir?

Re: Three Months of Go from a Haskeller’s perspective (2016)

#25

Post by thesz »

TeeWEE wrote: post #18

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is bui…

I disagree with only 1 way to write programs in Go.

Go is not an old Fortran (see [1] about "the only real structure is an array") so there is always choice between array-of-structures and structure-of-arrays.

[1] https://www.ee.ryerson.ca/~elf/hack/realmen.html

Haskell (and C++ for that matter) can hide the difference with associated types (and templates).

PS Speaking about arrays - I once read Go's specification for some obscure fun and realized that I read a third of it and still am reading about arrays and stuff and not about programming.

Re: Three Months of Go from a Haskeller’s perspective (2016)

#26

Post by eru »

quickthrower2 wrote: post #19
kjksf wrote: post #10

Apparently, the author of this blog post had a change of heart: https://memo.barrucadu.co.uk/blub-crisis.html > I have realised in recent conversations about programming languages, and in reflection of my very negative and kind of arrogant blog post about Go, that I have become trapped by the Blub Paradox. I have become dismissive of non-Haskell languages. I think in Haskell. Languages less powerful than Haskell are…

Definitely! I couldn't get my head around why people like untyped languages, but I keep an open mind on it. I won't close off that they could be better, if the right patterns/practices are used (whatever they are!)

Well, if your alternative was 90s style Java or C++ static typing, Python-style dynamic typing looks comparatively less insane.

As soon as you have algebraic data types and parametric polymorphism, static typing is less onerous, so dynamic typing is less appealing.

Re: Three Months of Go from a Haskeller’s perspective (2016)

#27

Post by mrmonkeyman »

lmm wrote: post #21
TeeWEE wrote: post #18

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is bui…

> Often short dense code with complex types is just really hard to read for your overage joe programmer. I think people make the mistake of measuring how long it takes you to read x lines, when really you need to measure how long it takes to read x functionality. There've been times when I replaced a 200 line class with 4 lines of Scala. Those lines were very much the kind of complexly-typed code that people attack S…

There is a middle way here. 4 terse lines still sucks. Make it 10-15 readable lines please.

Re: Three Months of Go from a Haskeller’s perspective (2016)

#28

Post by eru »

TeeWEE wrote: post #18

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is bui…

Go impedes its own readability by encourage or even requiring such huge volumes of code.

(And Go ain't very good at concurrency. At least they should have let you mark values as immutable, or communicated entirely via copying like Erlang.)

Yes, tuples are a really weird thing with Go. If they had completely left them, that would be bad but sort of defendable. But instead they give you a half-baked implementation of some of what tuples do with their 'multiple return types'.

(And multiple return types aren't even a good fit for signaling errors. For error-handling you want to return _either_ the result _or_ the error, in a way that the compiler can check that you handled the error.

Instead as far as the types are concerned they are always returning both the result and an error, and human reviewers have to make sure that they are checked properly.)

Re: Three Months of Go from a Haskeller’s perspective (2016)

#29

Post by higerordermap »

TeeWEE wrote: post #18

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is bui…

This is told so often told that people believe it is true

The lack of any type of abstraction is not great for teams. The need to write boilerplate code harms readability more than writeability.

Understanding what a single statement does is not important. Understanding intent is more important. And Go provides very few tools on it.

The reason for Go's popularity is mostly tooling. I like structural typing too. But other than that it is a very tedious language.

Re: Three Months of Go from a Haskeller’s perspective (2016)

#30

Post by nickcw »

> In Go, you import packages by URL. If the URL points to, say, GitHub, then go get downloads HEAD of master and uses that. There is no way to specify a version, unless you have separate URLs for each version of your library.

Go modules has solved this problem.

I find that in practice Go modules work very well. Certainly better than the alternatives and I've been through most of them.

Incrementing the major version of your module is very clunky though.

Post reply on HN