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

41–50 of 363 posts

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

#41

Post by merb »

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

How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP". But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all dev…

> How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP".

I never get the compile time argument. Well I code a big Scala application and the most time it spents is integration testing. the 10 minute test suite would probably still run 9 minutes and 30 seconds on go. we heavily rely on the database and cover a lot of concurrency/parallelism things in our tests. some things which we would need to test in go, too.

the compile time argument always looks good on first, but later on it's just a dumb way to prefer a language since it never matters. (Actually even the go maintainers didn't cared for a while about the compiler performance).

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

#42

Post by andmarios »

camus2 wrote: post #35
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…

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

So, do people who write timeseries databases in Go (like influxdb and prometheus), people who solve complex infrastructure problems (like k8s and docker), people who do distributed software (like consul) feel stupider because they write in Go?

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

#43

Post by manmal »

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's stoicism for programming. Accept what you cannot change (tools, language), and focus on what you can change (attitude, striving for great solutions).

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

#44

Post by ice109 »

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.

Bs. tell me how to compile individual packages from a .cabal in stack? tell me how to pass configure args through stack to cabal. tell me how to get stack to install an executable that isn't just the name of the package (eg if I attach version number to the executable). these are reasonable things you can't do because stack is immature.

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

#45

Post by swah »

bad_user wrote: post #11
jonnybgood wrote: post #3

> 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 cannot speak for Elixir, but coming from the Erlang world, I'm sure it's a fine language that has sane defaults, much like Clojure. However I switched from Python to Scala and besides the performance issues and the poor handling of async I/O that I had with Python, by far the biggest problem with Python was all the insecurity while developing with it. It drove me insane, because we had a production system that alwa…

But writing Python is a pleasure :( And writing the same thing is Go feels like wasting my wrists for nothing, specially for throwaways and simple web code...

Maybe one could write Python and turn a "strict" flag for the module (project?) where you'd have to fill in the types and it becomes Scala-like.

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

#46

Post by XorNot »

pjmlp wrote: post #18
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.

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

Then 4 hours later I remember that I can't deploy any of this to my servers, give up, and go back to waiting for someone to make a sane "get started" bundle for an FP language.

Haskell's package management might exist - but it sucks, and I'll take go get/govendor over pretty much anything currently out there.

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

#47

Post by grey-area »

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 found this comparison really interesting. Yes it is snarky and condescending at times (someone really needs to write the corollary to that blub essay, about programmers spending more time working on powerful abstractions and purity than real work), but it's useful to have an outside perspective - sum types seem nicer than returning type,error to me, the criticism of containers is fair, etc

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

#48

Post by dualogy »

demarq wrote: post #39
dualogy wrote: post #17

Earlier quoted context omitted.

How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP". But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all dev…

My comment is aimed at the OP who has it very clear in their mind what Go's shortcomings are. On the contrary, you haven't pointed out an objective issue that you have with Go. You offered some harsh remarks about the language but backed them up with praise. I'd say you love the language, but apologetically so. You shouldn't it's a great language. If ever you decide it's not for you then look at other alternatives, r…

> I'd say you love the language, but apologetically so. You shouldn't it's a great language.

I just think for me it absolutely shines for certain use-cases and sucks for many others, where I simply won't use it. The question then becomes "why Rust over [Haskell&friends]", not "why Rust over Go" ;)

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

#49

Post by jrobn »

I started out liking Go. It looked like a fairly pragmatic language. As I got deeper into my evaluation project (simple api stuff) it felt more and more like cutting wood with a dull saw.

I started out liking Haskell too! But has I moved along with my small evaluation api project it felt more and more like I was trying to cut wood with gyroscopic laser saw. It worked but it was a lot of fan fair for sawing some wood.

Picked up erlang/elixir. Looked pretty decent. Felt like cutting wood with a Japanese pull saw, so I had to use the vise clamps that came with it. It cut some fucking wood.

~ Ron Swanson out.

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

#50

Post by bad_user »

_0w8t wrote: post #34
bad_user wrote: post #33

Earlier quoted context omitted.

> One can say exactly the same about generics No, it's the same language with a bigger vocabulary and grammar, on which everybody agrees. And generics can be quite sane, as exemplified by the languages in the ML family, which have been around for decades. Java also didn't have generics. They added them eventually, much later in version 5, but then due to backwards compatibility concerns they added them with invarianc…

The ugliness of Java generics comes from type erasing. It allowed to stay compatible with JVM. Go has no such restrictions and I do not see why a truly minimal generics in a style of Virgil cannot be added to Go at some point.

No, type erasure is actually an (unplanned) feature, because it didn't cripple the runtime for other languages.

On this one people miss the forest from the trees. dotNET type reification is about introducing runtime meta-data and checks, which you only need when your type system is not strong / expressive enough, which makes you want to do `isInstanceOf` checks. Well, guess what, needing to check that an instance is a List is a failure of the language ;-)

This issue is also mixed with specialization for primitives. But that's actually unrelated because you don't need reification to do specialization. And actually you don't need runtime support either, as specialization can be compile time.

Also, in actual practice with Java, type reification is only a small usability issue. The real clusterfuck have been those wildcards for expressing use-site variance.

> It allowed to stay compatible with JVM. Go has no such restrictions

That's circular logic, given the JVM release cycle is tightly linked to Java the language and has had evolved in response to new features of Java.

No, the actual reason was to preserve compatibility with older code that weren't using generics (e.g. List vs List) without forking the standard library in pre- and post-generics functionality (like .NET has done).

Go will have exactly the exact same problem.

Post reply on HN