Live data from Hacker News

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

barrucadu.co.uk

21–30 of 363 posts

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

#21
post #6

I feel like some of the criticism is unwarranted, specifically: > The tooling is bad I feel like the tooling is really impressive, considering the age of the language. Remember that Haskell is something like 25+ years old. Go has done quite a bit in short time - I can only hope it will get better too. > Zero values are almost never what you want I've always felt the defaults to be spot on. Anyway, it's my responsibil…

>it would be nice to have, but the implementation is awkward, so we won't admit to it being nice to have".

That's not the impression I'm getting

https://research.swtch.com/go2017#generics

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

#22
post #12
post #8

It is, I think, going to be very difficult to enjoy writing code in a less powerful language when you are exposed to languages that hold awesome power. In fact, this has been the basis for much writing on Lisp too. Paul Graham has written entire essays along the same lines. If you work in a job that forces the use of a less powerful language than what you've been exposed to, you can, I think, go through a sort of dep…

TL;DR : get off​ your high horses and get to work

I ended up calling this engineering. Language is just a mean to an end, and learning its limits, picking one that match the most the problem at hand.

That said FP/Lisp are very hard to leave, I can understand that.

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

#23
post #6

I feel like some of the criticism is unwarranted, specifically: > The tooling is bad I feel like the tooling is really impressive, considering the age of the language. Remember that Haskell is something like 25+ years old. Go has done quite a bit in short time - I can only hope it will get better too. > Zero values are almost never what you want I've always felt the defaults to be spot on. Anyway, it's my responsibil…

I feel like the tooling is really impressive, considering the age of the language. Remember that Haskell is something like 25+ years old. Go has done quite a bit in short time - I can only hope it will get better too.

That's like hiring a toddler who can do sums for an accounting position. Showing promise is good, but not the same as being good right now.

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

#24
post #6

I feel like some of the criticism is unwarranted, specifically: > The tooling is bad I feel like the tooling is really impressive, considering the age of the language. Remember that Haskell is something like 25+ years old. Go has done quite a bit in short time - I can only hope it will get better too. > Zero values are almost never what you want I've always felt the defaults to be spot on. Anyway, it's my responsibil…

> Remember that Haskell is something like 25+ years old. Yet, I'd argue that tooling is still one of the worst aspects of the language. The whole cabal/stack thing is a mess.

stack isn't a mess at all, it's very well-designed, robust and stable. cabal is a mess (or say, a furball) that is properly "handled" by just using stack.

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

#25

> Go is just too different to how I think: when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour I see statements like this a lot from Haskellers and I think its overstated. Anecdotally, after going from Python to spending 3-4 years in Haskell then going back to a dynamic language (Elixir) I've come to the conclusion tha…

I disagree firmly. I fought many languages, even statically typed like java. The day I found out about lisp and FP I lost it entirely. If I wasn't a young student in a Java era I'd have saved 5 years of headache. I tried, many times, I always end up thinking like mathematicians (at least partially, I have shallow math skills) and/or FP-ers. That's the only time my brain was allowed to function and walk toward solutions. It's how I finally ended up understanding C (before that I couldn't write nested loops without making a mess).

I don't think it's entirely placebo or emotional drive too, because I really liked the Java OOP world at first, and went deep into it; but got nothing.

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

#26

TL;DR: "Go isn't like Haskell, and that means it's not as good" I get that we all have favourite languages, but it is not amazingly helpful to try and compare them like this, for me. I'm sure if you're a Haskeller and you're eyeing up Go, being forewarned might be helpful, but here's another idea: Don't compare. Just use. Take it at face value. Figure out what becomes easy, what becomes hard. I came at Go from 10+ ye…

> Don't compare. Just use. Take it at face value. Figure out what becomes easy, what becomes hard.

Isn't this precisely what the author did? The bad parts he mentioned were mostly "this is stuff that the compiler could've catched, but it didn't and thus gave me a hard time".

If we were going to carry out this argument, it would probably just boil down to the familiar debate of how strict a type system should be. The author is just a proponent of expressive type systems, and he plainly puts it in the title: "a Haskeller's perspective".

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

#28
post #18

Earlier quoted context omitted.

> Remember that Haskell is something like 25+ years old. Yet, I'd argue that tooling is still one of the worst aspects of the language. The whole cabal/stack thing is a mess.

Yet, at least we can use proper versions instead of Git urls that are exposed in source code.

These import paths aren't really URLs. They're local import paths, where Go's out-of-box tooling additionally allows for far simpler package install/update flows when one chooses to have these local paths replicate remote-repo URL paths. One doesn't have to, but it essentially turns "any CVS" into what would be Hackage/Stackage in the Haskell world. Sure, no curation, but `go get repo-url` has its charms too for quick iterations and experimentations. Vendoring is also entirely trivial (have a fork, update it from the original when it seems sensible to do so, undo when it turns out not to be). And guess what, with that you have "reproducable builds".

I like the hackage/stackage model, too. As long as there is always some folks tending to those repos. But, the `go get` model is a fine workflow too.

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

#29
post #5

> There is no way to specify a version [of an imported package] You can do this in your version-control system (e.g. git), via a process called "vendoring". It's ugly but, using one of the popular tools, quite workable.

> It's ugly

What do you find ugly about it?

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

#30
post #16

I don't think anything in the 'The Bad' is unfair, and they're certainly not written from a position of ignorance. Those are things that suck about go; it's not specifically that they suck about go when compared to haskell; they just generally suck (particularly the type system stuff). However, I don't think that the situation is so bad I would go as far as to say, "Other than that, I will probably never choose to us…

The thing with Go, is that it is disappointing what Google is capable of in terms of language design versus what Apple and Microsoft have done in this field. Sure there were languages with such type systems before, and we managed to deliver our work with them. However I don't want to work in 2017 as I used to work in the mid-90's, when templates were an experimental feature in C++, or the only MLs we knew were Caml L…

> is that it is disappointing what Google is capable of

Man, how long will this meme survive? Go only initially originated with some Google developers, it's not in any way "Google's answer to Apple's and Microsoft's strategically-important and accordingly-subsidized-and-evangelized-and-invested-in languages". Just picture a handful of (previously "accomplished" in the field, as it turns out though) guys thinking "this company has a wide mess of Python etc scripts that should really be C programs, except for the problems this would pose"..

Post reply on HN