Three Months of Go from a Haskeller’s perspective (2016) • Hacker News Board

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

#111

Post by rkangel » Wed, Nov 04, 2020, 2:43 PM UTC

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…

I personally believe that Elixir is an excellent 'gateway' functional programming language because it is dynamically typed.

Learning OCaml and especially Haskell (I've done some of both) requires understanding a complex type system and learning how to encode what you want in it. On top of that you have to learn to code in the 'functional' way - representing your data, pure code, recursion (or reduces), higher order functions etc.

When you write Elixir you eliminate most of the type system stuff, and you just have to learn to code in a functional way. There is surprisingly little 'language' to learn - functions, tuples, lists, maps, modules and that's about it. There is then the OTP (processes and supervisors) side of it, but that's separate (and if you're writing a web backend in Phoenix, mostly ignorable).

We're just (hopefully) wrapping up a 9 month project with a team of about 8, none of which had written much Elixir before the start (a background of mostly C). It has been a very smooth process, and definitely the right choice of language.

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

#112

Post by simiones » Wed, Nov 04, 2020, 2:48 PM UTC

Philip-J-Fry wrote: post #32

eru wrote: post #28

Earlier quoted context omitted.

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

I think even more than the lack of generics, Go is difficult to read because it forces you to mix the error path with the success path in every function which can possibly fail, often making you bubble errors up the call stack manually.

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

#113

Post by simiones » Wed, Nov 04, 2020, 2:54 PM UTC

bankisan wrote: post #105

eru wrote: post #51

Earlier quoted context omitted.

> 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. I'm not sure what those glaringly obvious reasons are. In Erlang, you just send a copy of the whole struct. Not some kind of references or pointers. See eg https://play.golang.org/p/P3qUtFenp2q But as I am sa…

Regarding the example in your first point, you are still sending a reference `m` of the map. If you wanted to send an immutable type, you could declare the channel to only accept struct values (and not pointers to structs) and you'll get your desired behavior. Here's a playground for reference: https://play.golang.org/p/U2tYZVTtUf-

Given that there is no way to make a non-pointer map in Go, there is no workaround for the example they gave.

The broader point is that there is no way in Go to ensure that data passed over a channel will not be modified concurrently without modifying the type of the data specifically for the channel use case.

A deep_copy() primitive would fix this.

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

#114

Post by kevincox » Wed, Nov 04, 2020, 3:04 PM UTC

LandR wrote: post #45

Philip-J-Fry wrote: post #32

Earlier quoted context omitted.

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

> Go is incredibly readable I find. I'm the opposite, I don't find it readable at all. I find Go too verbose to be readable.

Exactly this. I find that each line of go is readable. However actually trying to figure out what the code is trying to accomplish becomes a chore because I can't keep all of the lines in my head.

Maybe it is because what I am used to but I find I am often "pattern matching" loops into `map`s `filter`s and similar in my head. Of course doing this, and making sure that I didn't miss a side effect or condition that makes it not-quite-a-map takes a lot more brainpower than just seeing `slice.map(|path| path.basename())`.

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

#115

Post by kevincox » Wed, Nov 04, 2020, 3:06 PM UTC

clon wrote: post #71

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…

The argument for Go being a simple language that naturally produces code everyone can easily grok comes up time and time again. I have never gotten it. I find Go code somewhat easy to write, just just give up on trying to be concise or elegant, but not at all easy to read. The excessive boilerplate just makes me feel like my brain does not have the working memory to piece it all together. The constructs are simple, t…

I agree! If people believe that Go is easy to read because it is simple they must love reading brainfuck as there are only a handful of simple operations!

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

#116

Post by tored » Wed, Nov 04, 2020, 3:09 PM UTC

clon wrote: post #71

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…

The argument for Go being a simple language that naturally produces code everyone can easily grok comes up time and time again. I have never gotten it. I find Go code somewhat easy to write, just just give up on trying to be concise or elegant, but not at all easy to read. The excessive boilerplate just makes me feel like my brain does not have the working memory to piece it all together. The constructs are simple, t…

In what way are Go modules a train wreck?

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

#117

Post by giulianob » Wed, Nov 04, 2020, 3:10 PM UTC

Philip-J-Fry wrote: post #77

shaan7 wrote: post #43

Earlier quoted context omitted.

What higerorderma said above applies to this ^ comment as well. It is another of those nonsensical things that keeps getting repeated all the time by some Go programmers. That line of thinking promotes workarounds over long-term solutions. If your team has people who are abusing tools (like types, abstractions etc), the solution is to teach them how to not do that. The solution is NOT to remove the tool itself! That…

Why do you think it gets repeated by Go developers? I was a C# developer writing all these abstractions like every other C# developer does. It's idiomatic C#. OOP exists, you're encouraged to use it to abstract and decouple code. Even if you try and strip all that away, you'll never escape it because every library you depend on is written this way. For example, try understanding https://github.com/protobuf-net/protob…

I've worked professionally on C# and Go. I've seen overly abstracted C# code but I also have seen Go code that was clearly missing good patterns and ended up a ton of spaghetti. The difference that I see is that C# gives you the tools to do it well whereas Go lacks many tools to make a complex code base nearly as maintainable as C#.

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

#118

Post by clon » Wed, Nov 04, 2020, 3:29 PM UTC

tored wrote: post #116

clon wrote: post #71

Earlier quoted context omitted.

The argument for Go being a simple language that naturally produces code everyone can easily grok comes up time and time again. I have never gotten it. I find Go code somewhat easy to write, just just give up on trying to be concise or elegant, but not at all easy to read. The excessive boilerplate just makes me feel like my brain does not have the working memory to piece it all together. The constructs are simple, t…

In what way are Go modules a train wreck?

Here is a good start: https://donatstudios.com/Go-v2-Modules

With the relevant HN discussion: https://news.ycombinator.com/item?id=24429045

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

#119

Post by bankisan » Wed, Nov 04, 2020, 3:29 PM UTC

simiones wrote: post #113

bankisan wrote: post #105

Earlier quoted context omitted.

Regarding the example in your first point, you are still sending a reference `m` of the map. If you wanted to send an immutable type, you could declare the channel to only accept struct values (and not pointers to structs) and you'll get your desired behavior. Here's a playground for reference: https://play.golang.org/p/U2tYZVTtUf-

Given that there is no way to make a non-pointer map in Go, there is no workaround for the example they gave. The broader point is that there is no way in Go to ensure that data passed over a channel will not be modified concurrently without modifying the type of the data specifically for the channel use case. A deep_copy() primitive would fix this.

Right, but they mentioned sending immutable structs which is why I gave the struct example. But you're right that every declared map is a just a pointer.

With respect to your second point, I see what you mean but I still don't think that's a negative of Go. You can pass in copied values without having to have a deep_copy() primitive (loop map values and copy to new map, dereferencing a pointer, etc.). Like other parts of Go, if you want to make your data immutable there is no syntactic sugar. You have to explicitly write it out.

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

#120

Post by jerf » Wed, Nov 04, 2020, 3:59 PM UTC

linspace wrote: post #56

quickthrower2 wrote: post #19

Earlier quoted context omitted.

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!)

I joked with a friend that as people get older they start to prefer static typing. I personally don't have a preference, it depends on the application. I think it's obvious what are the advantages of static typing so let me rant about what is for me the main disadvantage: as soon as you have an advanced type system people will try to get creative writing code in the most abstract possible way. It's inevitable. It's t…

"I joked with a friend that as people get older they start to prefer static typing."

I don't think you can tell that right now. Statically-typed languages have gotten much, much better over the past 30 years (progressively), and over the last 20 years we've all aged, you know, 30 years, so right now I think there's a lot of correlation there rather than necessarily causation. I have also switched to static typing as I've "gotten older", but I would still totally rate things in the order "1990 static It also isn't even necessarily big jumps that make that true as much as a steady development of innovations, since obviously it's not like all modern static languages are Hindley-Milner or anything. But a slow dribble of both little features and improvements in understanding of how to use everything over the years, like type deduction (getting rid of the usually-redundant specification of type on both sides of "="), getting away from the idea that OO === matching physical models, libraries that have learned to take more interfaces instead of concrete types, languages like Go that privilege composition over inheritance instead of the other way around and the general trend towards composition, getting iterators embedded more deeply into languages like C#, control flow improvements like usable threading methodologies ("share memory by communicating, don't communicate by sharing memory", and even as much as I dislike it vs. the alternatives, having async/await is better than not having any options even though I prefer Go-style threading by a mile), and so on and so on... a steady dribble of little improvements that one step at a time changed the cost/benefit tradeoffs of a static vs. dynamic language from clearly dynamic circa 2000 to fairly clearly (IMHO) static for any non-trivial code base in 2020. And that's before we talk about Rust or anything like that.