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

81–90 of 363 posts

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

#81

Post by gothrowaway »

When I look at a programming language, I look at the community and how it gets stuff done and projects that are noteworthy.

Something about Haskell strikes me as different. Despite the buzz about it, I don't see many projects for it other than shellcheck, pandoc and xmonad, and for two of those, there's better solutions around (sphinx, awesome/i3).

The other thing is the general flow I've see with Haskell programmers, many really tie down their identity do it. They see programming as a crossword puzzle for them to solve in short term, not as something other programmers have to read later on. They're not very empathetic to the idea the runways dwindling and you have to ship sooner rather than later.

In addition, I found that the Scala / Haskell developers I knew took golang to be quite the nuisance. They find gophers pesky. I think the reason why is years of Haskell teaches them to overengineer and complicate things needlessly. It's frustrating because they're not aware of it themselves and take offense, even blame you when you point it out to them.

Maybe I've just been unlucky. In 10 years, I've never had people who consistently failed to ship, been mean and arrogant as scala / haskell programmers. They take the slight criticism as an assault on their identity.

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

#82

Post by jwdunne »

bobsam wrote: post #79
jwdunne wrote: post #78

Earlier quoted context omitted.

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!

This is true, from my experience. When I'm screening candidates, I often ask them to solve a problem in their language of choice. They choose PHP, even though I know the same problem solution can be expressed far clearer and shorter in Ruby.

Perhaps we are unearthing various kinds of choices i.e choices for best fit vs best convenience. Perhaps that's a case of engineering vs something other.

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

#83

Post by bboreham »

dualogy wrote: post #29
bboreham wrote: 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?

The idea of copying multiple other repos into mine.

I have used git submodules to avoid copying, but if one library has its own vendor'd copies you can end up with two versions of the same dependency. Which is even more ugly.

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

#84

Post by willsewell »

demarq wrote: post #2

I hate to sound like the rust evangelist strike force... I really do. But your complaints are exactly what it would solve... Sigh I hate to say this I really do. But here goes... So have you checked out rust?

We're asked this question a lot (I work at Pusher). I wrote up some of my thoughts on this in reply to a comment on one of our previous blog posts: https://www.reddit.com/r/programming/comments/5fyhjb/golangs....

Right now I'm keen to get more personal experience with Rust, and hopefully in the wider team. I'm particularly interested in [Tokio](https://tokio.rs/), which should address some of our concerns about the existing concurrency support.

Also, in same reddit comments there's a longer (quite argumentative) discussion on Rust concurrency that you might be interested in: https://www.reddit.com/r/programming/comments/5fyhjb/golangs...

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

#85

Post by literallycancer »

jwdunne wrote: post #77
rpeden wrote: post #51

Earlier quoted context omitted.

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.

Yep: http://www.citymetric.com/skylines/yemen-theres-city-full-50...

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

#86

Post by NateDad »

XorNot wrote: post #46
pjmlp wrote: post #18

Earlier quoted context omitted.

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

And yet I can be up and running and compiling with Go faster then Haskell every time, ready to ship production binaries if I want. With Haskell the process for me has repeatedly been: "okay I'm going to follow this tutorial...okay I need to install it...okay cabal is complaining about versions or exceptions....okay let's try stack....okay this example needs some includes...okay I don't have quite the right ver..." Th…

This is one of the things I love about go. Basically any random tool written in go I can have installed and runnable in 3 seconds from the time I know the github url. All but the largest of applications is made to be compatible with 'go get' and so most of the time it just works.

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

#87

Post by matwood »

cube2222 wrote: post #80
pka wrote: post #71

Earlier quoted context omitted.

> 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.

I'm just getting into Go and have found what you said to be true. It's easy to read other people's code on GH (Java is much the same way). Compare that to something like Scala, where no ones code looks the same.

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

#88

Post by 59nadir »

gothrowaway wrote: post #81

When I look at a programming language, I look at the community and how it gets stuff done and projects that are noteworthy. Something about Haskell strikes me as different. Despite the buzz about it, I don't see many projects for it other than shellcheck, pandoc and xmonad, and for two of those, there's better solutions around (sphinx, awesome/i3). The other thing is the general flow I've see with Haskell programmers…

> Despite the buzz about it, I don't see many projects for it other than shellcheck, pandoc and xmonad, and for two of those, there's better solutions around (sphinx, awesome/i3)

I tried awesome for two weeks and had one crash. I've run XMonad for 5+ years and had no crashes. Just because they are supposed to accomplish the same things does not mean that they're equal. One is better and it's because of the choice of language.

It's very hard to take your post seriously when you include something like this in it and you don't bother to qualify it even in the slightest.

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

#89

Post by cube2222 »

matwood wrote: post #87
cube2222 wrote: post #80

Earlier quoted context omitted.

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.

I'm just getting into Go and have found what you said to be true. It's easy to read other people's code on GH (Java is much the same way). Compare that to something like Scala, where no ones code looks the same.

Check out sourcegraph, it's great for reading Go and Java code and has a GitHub integration.

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

#90

Post by raulk »

icebraining wrote: post #23
joaodlf wrote: 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.

When a decent software engineer builds a project, you not only take into consideration the status quo of the technology, but also its promise, momentum and community development speed. You don't want to pick a stack with weaning manpower because you'll soon be left with legacy software in your hands. Hence, I do think that, for most serverside projects, the "promise" (as you call it) is very relevant and a true factor of decision.
Post reply on HN