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

31–40 of 162 posts

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

#31

Post by jiofih »

higerordermap wrote: post #29
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 ot…

> other than that it is a very tedious language

And that, is precisely why it is a good language for teams.

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

#32

Post by Philip-J-Fry »

eru wrote: post #28
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 s…

Go is incredibly readable I find. Yes, you tend to find yourself writing a lot of code because of the lack of generics, but that is being fixed as we speak. Generics has a draft and it looks nice from a Go developers perspective.

And Go let's you communicate by copying. That's what a Channel is. Pass a struct and that is copied. Pass a pointer and the pointer is copied. The thing it points to isn't copied for glaringly obvious reasons.

And what would you suggest is a good alternative for returning multiple parameters. Currently this basically forces you to handle any possible errors and results in software you can very easily reason about.

Not sure what you mean about human reviewers needing to check errors.

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

#33

Post by Philip-J-Fry »

jiofih wrote: post #31
higerordermap wrote: post #29

Earlier quoted context omitted.

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

> other than that it is a very tedious language And that, is precisely why it is a good language for teams.

Yeah it's hard to write weirdly complicated code in Go. Stick Java or C# in the hands of a team and before you know it you've got typed factory service factories and every abstraction known to man.

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

#34

Post by ardfard »

greyman wrote: post #22
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.

I had an opposite experience. Go code is just like other code in any other languages. It still can be abused to be unholy mess. I see a Go code that have channels all over the place that it's hard to follow the program flow, a function that can panic deep down the stack when feed with certain input.

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

#36

Post by redis_mlc »

justasitsounds wrote: post #4
throw_m239339 wrote: post #3

Earlier quoted context omitted.

Still no official debugger though. Delve is just full of bugs.

Just do as the Head of Marketing from previousEmployer suggested and "leave out the bugs"

That's next-level.

Was he being ironic, or serious? Love to hear more.

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

#37

Post by panpanna »

jonahx wrote: post #15
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…

I thought the criticisms and praise, and the article's Good/Neutral/Bad structure, were fair and thoughtful on balance. It didn't read as arrogant to me.

It did to me.

He slams go for not doing stuff the Haskell-way (e.g. pure code vs effectful code).

This is not how you approach new things

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

#39

Post by ghayes »

eru wrote: post #24
dragosmocrii wrote: post #16

Earlier quoted context omitted.

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?

Dialyzer is fully integrated into Elixir, yes. But again, it’s optional typing.

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

#40

Post by ghayes »

ardfard wrote: post #34
greyman wrote: post #22

Earlier quoted context omitted.

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.

I had an opposite experience. Go code is just like other code in any other languages. It still can be abused to be unholy mess. I see a Go code that have channels all over the place that it's hard to follow the program flow, a function that can panic deep down the stack when feed with certain input.

Channels for me make Go harder to read than most languages. Once you encounter a channel when reading Go code, good luck understanding the flow from then on.
Post reply on HN