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

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

#131

Post by pdimitar » Wed, Nov 04, 2020, 4:53 PM UTC

Cthulhu_ wrote: post #60

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…

Recently I've become a bit jaded, because I see flaws and the like in every language I've used; I (like to think I) don't have a "blub" language. Mind you I've never gotten along with pure functional languages. I've mostly done CRUD applications and I'm not sure functional languages are appropriate for that use case.

FP languages like Elixir are perfect for CRUD apps IMO (Clojure too but it lacks the runtime guarantees of Erlang's BEAM VM so to me that's a no-go).

Reason being: they are immutable in general but allow you escape hatches that you can relatively easily identify in your code if you need to troubleshoot.

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

#132

Post by carapace » Wed, Nov 04, 2020, 4:55 PM UTC

> whereas Python’s significant whitespace (which is there for exactly the same reason: enforcing readable code) has been much more contentious across the programming community.

Because with gofmt there's nothing to argue about, it is what it is. With Python’s significant whitespace there was plenty of rope to play tug-o-war with: tabs or spaces? How many? That was enough to fuel the flame wars.

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

#133

Post by rkangel » Wed, Nov 04, 2020, 4:56 PM UTC

pdimitar wrote: post #124

rkangel wrote: post #111

Earlier quoted context omitted.

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

I sorely lack Elixir's easy entry experience while I am getting better and better at Rust. :( And I'll look for ways to use it at my $dayjob. Rust is an excellent language but I feel that for some pieces of our stack Rust is kind of a bazooka in a scenario where a 9mm pistol would do.

I could see an argument where Rust is performant and low level enough that you can use it at the bottom of the stack, and has good enough abstractions that it's productive to use higher in the stack. There are certainly benefits to using one language for everything, but this logic reasoning relies on you having a team that is very familiar with it, and having your bits of tooling and libraries worked out for your setup.

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

#134

Post by pdimitar » Wed, Nov 04, 2020, 5:03 PM UTC

rkangel wrote: post #133

pdimitar wrote: post #124

Earlier quoted context omitted.

I sorely lack Elixir's easy entry experience while I am getting better and better at Rust. :( And I'll look for ways to use it at my $dayjob. Rust is an excellent language but I feel that for some pieces of our stack Rust is kind of a bazooka in a scenario where a 9mm pistol would do.

I could see an argument where Rust is performant and low level enough that you can use it at the bottom of the stack, and has good enough abstractions that it's productive to use higher in the stack. There are certainly benefits to using one language for everything, but this logic reasoning relies on you having a team that is very familiar with it, and having your bits of tooling and libraries worked out for your set…

Yep, exactly. Lower-level languages however also give you much more foot-guns.

These days my ideal app is written in Elixir for almost everything due to the insane parallelisation and fault-tolerance that it offers (and the copy semantics that make shared memory bugs impossible) with Rust sprinkled at the critically important-to-be-fast places -- like working with sqlite3 for example.

All of that could be achieved with Rust or any other language really. But it requires tons of tooling, CI/CD jobs, Git hooks, static analyzers, linters, formatters etc. And a good chunk of all that doesn't even exist for many languages.

So I prefer to make my own blend that has the important advantages at the right places.

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

#135

Post by pdpi » Wed, Nov 04, 2020, 5:07 PM UTC

AnimalMuppet wrote: post #130

pdpi wrote: post #78

Earlier quoted context omitted.

There are type systems out there that allow you to model more than "is a string, is a float, is an int". There are CVEs for use-after-free bugs in Firefox, IE, the Linux kernel and more. Rust's type system helps prevent those. There are CVEs for double-free bugs in OpenSSH, OpenSSL, and Kerberos. Again, Rust's type system helps prevent those. There are CVEs for null dereferencing in the Linux kernel, CUPS, and OpenSS…

> Dismissing strong, static typing as "a crutch for bad programmers" is just plain wrong. No, it's correct. The problem is that innocentoldguy doesn't realize that he is a bad programmer. (That's not an attack on him - we all are bad programmers.) So here we are, bad programmers. Here's this crutch - or, less negatively put, here's a tool that can help. Maybe we can be somewhat better bad programmers if we use it.

I get your point, but if we're all bad then "bad" loses its meaning. I'm definitely a better programmer than many of my peers, and worse than a whole bunch of others.

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

#136

Post by [deleted] » Wed, Nov 04, 2020, 5:08 PM UTC

thesz wrote: post #25

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

[deleted]

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

#137

Post by AnimalMuppet » Wed, Nov 04, 2020, 5:11 PM UTC

pdpi wrote: post #135

AnimalMuppet wrote: post #130

Earlier quoted context omitted.

> Dismissing strong, static typing as "a crutch for bad programmers" is just plain wrong. No, it's correct. The problem is that innocentoldguy doesn't realize that he is a bad programmer. (That's not an attack on him - we all are bad programmers.) So here we are, bad programmers. Here's this crutch - or, less negatively put, here's a tool that can help. Maybe we can be somewhat better bad programmers if we use it.

I get your point, but if we're all bad then "bad" loses its meaning. I'm definitely a better programmer than many of my peers, and worse than a whole bunch of others.

We're bad, not in comparison with each other, but in comparison to the external standard of "good enough that we don't need a crutch".

In fact, if you want to be a better (less bad) programmer, learn to use the available crutches more effectively.

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

#138

Post by AnimalMuppet » Wed, Nov 04, 2020, 5:14 PM UTC

redis_mlc wrote: post #36

justasitsounds wrote: post #4

Earlier quoted context omitted.

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.

"Head of Marketing". He was probably serious.

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

#139

Post by pdimitar » Wed, Nov 04, 2020, 5:17 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…

> But I never liked reading other people's code because without the intimate knowledge of the code it is a huge mental load.

But that's exactly where Go projects end up at. Reading any 1-4 Go lines is easy. Trying to mentally decode a function of 70 lines almost never is. It is verbose as hell. And then you are like "a-ha! this goes through those two collections, filters one of them, maps the other and then combines the results through that algorithm". But you lost 20 minutes until you got to that conclusion.

Compare this with OCaml or Elixir for example where such a function would literally be 10-15 lines.

(It's not an unique disadvantage to Go, mind you, but we're discussing it currently. Other languages have the same problem, e.g. C# and Java.)

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

#140

Post by mcguire » Wed, Nov 04, 2020, 5:18 PM UTC

wwright wrote: post #82

eru wrote: post #68

Earlier quoted context omitted.

In general, you'd need something like dependent types for solving this properly. Like eg Agda has.

Ada has this without general dependent types AFAIK

Yes and no. The definitions are in the type system, but the checks are done at runtime, just like you would do manually. You don't really get the benefit of typing.

The reason I can say that: you don't have to provide proofs that a value has to be positive to get things to compile.