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)

barrucadu.co.uk

Post reply on HN
Print view View original

71–80 of 363 posts

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

#71

Post by pka »

cube2222 wrote: post #52
camus2 wrote: post #35

Earlier quoted context omitted.

> 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 depression. You simply long to use the tools that you know hold much more power yet must resign yourself to the tools you have. I was forced to use go for a job, it actually made me feel stupider, so much that I didn't know how to use the right types anymore when i moved back…

Go has a lot of advantages. Yes, you are a little bit limmited sometimes because of the lack of generics and the like, but at the same time, if you learn to use Go interfaces well, you end up using them most of the time happily. The parallelism primitives are great too. As much as I love complex type systems, pattern matching, algebraic data types etc., I know that if Go had those things, it wouldn't be the language…

> There is one thing in Go, that I haven't met anywhere else. I can really understand any codebase I stumble upon in a matter of seconds.

Care to elaborate a bit more?

I understand that when you see for(...) { b[i] = f(a[i]); } then you instinctively know that it's a loop that maps over some sequence, and so on. But let's say you have a 50-100kloc codebase with a 100 files in it. In what unique to Go way does Go help you understand the big picture/coarse architecture of such a project?

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

#72

Post by runeks »

cube2222 wrote: post #55
icebraining wrote: post #19

Earlier quoted context omitted.

I don't understand. How can they not be comparable? They're the same type of tool, built with the same goal (writing any kind of software). In fact, Go itself was born because its creators felt the current languages weren't good at handling the current computing environment - comparisons with other languages are the at core of its existence. Finally, why even choose Go if it's not because it has some comparative adva…

They're not the same type of tool. Go is mainly aimed at distributed computing evironments and infrastructural tools. I really don't see a sensible Consul/Kubernetes/Docker alternative being written in Haskell.

   > I really don't see a sensible Consul/Kubernetes/Docker alternative being written in Haskell.
The only reason for this is the unpredictable latency issues caused by the current garbage collector in GHC. This should be avoidable once GHC has linear types[1] and someone rewrites its GC to take advantage of this.

[1] https://news.ycombinator.com/item?id=13866787

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

#73

Post by chriswarbo »

dualogy wrote: post #24
AsyncAwait wrote: post #13

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.

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.

I've tried to use stack many times; I think I'm up to 5 attempts now?

Each time, I've invested many hours trying to make it build; trying to make it find/fetch GHC; trying to make it find/recognise the GHC it's just downloaded; talking to others in IRC/GitHub issues/etc. for help; reading through the source code; trying to hack around brokenness (stack filling up temp dir, GHC misusing bash, etc.). Each time my patience has worn out and I've just used Cabal instead.

I know that stack must work on some people's machines, and that's great for them. I don't understand at all why it's regarded as some sort of simple, works-everywhere, "end of cabal hell" thing.

Haskell's infrastructure is probably its biggest pain-point; Cabal isn't great, but it's at least predictable enough and old enough to have stable, reliable workflows. Stack's approach seems to be solving problems by bundling them as yet another stack feature; that doesn't help when stack itself flat-out doesn't work :(

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

#74

Post by BuuQu9hu »

PaulRobinson wrote: post #7

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…

I learned Go in the manner which you describe. It's still a disappointing language. I don't understand the powerful Stockholm Syndrome which appears to grip most Gophers.

For example, compared to MRI, Go has better GC and execution speed, much less flexibility, better concurrency primitives but not better concurrency libraries (EventMachine), and is incredibly verbose.

If you refuse to compare languages, then you are asserting that at least one of the languages is somehow magically incomparable and thus criticism-free, and Go is not so special or good that it should get any pedestal-driven treatment.

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

#75

Post by willsewell »

I worked with Michael on the same project, after also working with Haskell previously. On the whole I agree with the pros/cons stated in the article. Having said that, my conclusion would be a bit different: I would err on the side of Go for the majority of commercial projects.

The article mentions the impressive worst case pause times of Go's GC. Since then we have performed some additional benchmarking. The conclusion was: it is impressive, but there are still a couple of issues that break the sub 1ms claims. We blogged about this here: https://making.pusher.com/golangs-real-time-gc-in-theory-and.... It's hard to guarantee low latency in all cases...

Michael also mentions that there is nothing like ThreadScope, or at least nothing that's easy to find. The latter is true. There is an impressive runtime system event visualiser which can be opened with `go tool trace` https://golang.org/cmd/trace/. You can see a screenshot of this in the GC blog post I linked to above. Unfortunately the only documentation is this Google Doc: https://docs.google.com/document/d/1FP5apqzBgr7ahCCgFO-yoVhk... which is tricky to find, and could be more in-depth.

I'm in the middle of writing a blog post on how to use this too. Watch out for it on our engineering blog in the next month or two. https://making.pusher.com/

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

#76

Post by jwdunne »

ruleabidinguser wrote: post #64
jwdunne wrote: 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…

>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. As someone whos written code in Haskell (even some medium sized programs) and moved on just fine, no. Frankly, Haskell can be an excercise in frustration.

It depends, I imagine, on how much you enjoy working with it. If it was so painful, I think moving to another language would be refreshing as opposed to depressing.

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

#77

Post by jwdunne »

rpeden wrote: post #51
jwdunne wrote: 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…

I agree to a certain extent. There are times when I've seen great beauty in something as mundane as pre-generics Java, when someone put together a well factored set of loosely couple objects to accomplish a task. Other times, though, being forced to work with obtuse tools feels like trying to construct a skyscraper out of sticks and dog crap. No matter how elegant a structure you manage to construct, doing so is a mi…

I understand the analogy but I think many ancient cultures did great things with twigs and poo. In fact, there are many wattle and daub structures still standing - there's one around the corner that's protected by law.

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

#78

Post by jwdunne »

iagooar wrote: post #70
bobsam wrote: post #12

Earlier quoted context omitted.

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

Isn't it possible to choose the best tool AND get to work? Isn't it our responsibility, as software engineers, to ensure that those who pay for our services get the best bang for their buck? That includes choosing a programming language that actually helps developing new features faster, while guaranteeing that the system is available, robust and maintenance costs are low. Choosing a language that makes these things…

You're right. If you have the freedom to choose the best tool, I think you absolutely should.

I think the problem lies in the fact many programmers don't have the luxury of making those decisions. I imagine if one of those programmers refused to use the mandated tools, they'd get the sack. Many of those programmers, again, don't have the leg room to handle that. Plus, I don't think any employer would look favourably on "I got sacked because I refused to use language X because language Y is superior". I know that isn't the kind of attitude to work I would appreciate.

The companies that allow freedom of choice in tools and languages are perhaps the best companies to work for. Unfortunately, those companies hire the best programmers in the first place, or at least set the bar with that in mind. Most programmers, including myself, are not of this calibre.

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

#79

Post by bobsam »

jwdunne wrote: post #78
iagooar wrote: post #70

Earlier quoted context omitted.

Isn't it possible to choose the best tool AND get to work? Isn't it our responsibility, as software engineers, to ensure that those who pay for our services get the best bang for their buck? That includes choosing a programming language that actually helps developing new features faster, while guaranteeing that the system is available, robust and maintenance costs are low. Choosing a language that makes these things…

You're right. If you have the freedom to choose the best tool, I think you absolutely should. I think the problem lies in the fact many programmers don't have the luxury of making those decisions. I imagine if one of those programmers refused to use the mandated tools, they'd get the sack. Many of those programmers, again, don't have the leg room to handle that. Plus, I don't think any employer would look favourably…

Counterpoint: Programmers don't choose the best language, they choose the language they are comfortable using.

Source: at a previous job we had a "use whatever tool you want, just get the job done" policy. After two years we had everything from Perl to JavaScript in the same project.

Edit: ... and this project was a desktop application!

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

#80

Post by cube2222 »

pka wrote: post #71
cube2222 wrote: post #52

Earlier quoted context omitted.

Go has a lot of advantages. Yes, you are a little bit limmited sometimes because of the lack of generics and the like, but at the same time, if you learn to use Go interfaces well, you end up using them most of the time happily. The parallelism primitives are great too. As much as I love complex type systems, pattern matching, algebraic data types etc., I know that if Go had those things, it wouldn't be the language…

> There is one thing in Go, that I haven't met anywhere else. I can really understand any codebase I stumble upon in a matter of seconds. Care to elaborate a bit more? I understand that when you see for(...) { b[i] = f(a[i]); } then you instinctively know that it's a loop that maps over some sequence, and so on. But let's say you have a 50-100kloc codebase with a 100 files in it. In what unique to Go way does Go help…

Oh, that it doesn't.

I meant smaller parts of code, and not for loops actually. (I prefer maps, filters etc.). Things like gofmt and the simplicity (in that, small number of concepts) of the language lead to most people writing fairly idiomatic code. This way most codebases look the same and you read each other's code as it were yours.

Post reply on HN