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

51–60 of 363 posts

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

#51

Post by rpeden »

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 miserable experience because you're never able to transcend the feeling that you're working with twigs and poo.

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

#52

Post by cube2222 »

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…

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 I love to write everyday anymore.

Somehow, Go is a really practical language and you end up being very productive in it, at least from my experience.

Saying that people who write Go should be stupid is shallow thinking. Complex languages aren't the only complexity that you should have. Some people concentrate on sophisticated architectural design (like Kubernetes).

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. This is a huge boon to productivity.

Anyways, I never had any problems switching between Go and languages like F# or Scala on a daily basis. Rust looks interesting, though I think it will end up being too complex for a lot of people to understand, which will hinder its growth.

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

#53

Post by kuschku »

andmarios wrote: post #42
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…

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?

A good engineer can build a bridge out of rotten trees.

But they could still build a better bridge, in less time, with proper materials.

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

#54

Post by cube2222 »

merb wrote: post #41
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…

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

Well, the thing is, with compile times of 2 seconds I can run my unit tests as fast as possible. At the same time, I'd just use a mock database for most of the tests.

It's great to be able to compile applications like kubernetes in 2 minutes.

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

#55

Post by cube2222 »

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

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

#56

Post by bborud »

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…

What was hard to get used to when you came from Ruby?

I came from Java, but it should be said that the Java style I've been using since the mid 2005s (some functional influences and a lot of experience-driven minimalism) made learning Go really easy. I should be missing immutable types and types that can only be instantiated if the state is consistent, but for some reason I didn't. Perhaps it is that the Go mindset is just very easy to adapt to?

One thing I would say, though, is that you can feel that Go was a more deliberate language. Unlike most popular languages it wasn't really a language that grew out of inexperience and as a learning exercise for the language implementers. The authors already had a fairly good idea of what they wanted to accomplish and they had the attention to important detail that others tend to miss due to lack of experience.

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

#57

Post by kuschku »

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?

You don’t properly separate and deduplicate dependencies, you can end up with legal issues (if you ever decide to redistribute your source), etc.

One of the few dependency systems I’ve seen that work well is Gradle with Maven dependencies, using Java 9’s versioned modules.

Proper versioning, proper dependencies, etc.

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

#58

Post by kuschku »

pjmlp wrote: post #16
shadowmint wrote: post #9

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…

Especially because Go is in most ways less powerful than Java – a native compiler for Java would have been more useful than this.

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

#59

Post by auxym »

swah wrote: post #45
bad_user wrote: post #11

Earlier quoted context omitted.

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.

Don't know if you are aware, but python now supports optional type hints.

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

#60

Post by rimliu »

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…

  > because in a language like Python there is no such thing as
  > information hiding and coupled with dynamic typing, it
  > means that your tests end up tightly coupled with
  > implementation details, will break on correct refactoring
  > and will be hard to fix.
Would you mind to provide more details about this point? I thought dynamic languages make testing easier, because you don't care about the type of the object as long as it works with the same API (if it quacks…). This also supposedly makes it way easier to mock objects. Now there you are basically claiming (unless I misunderstand your claims) the opposite.
Post reply on HN