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

61–70 of 363 posts

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

#61

Post by sametmax »

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.

You kinda have this already, it's called mypy.

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

#62

Post by bborud »

kuschku wrote: post #58
pjmlp wrote: post #16

Earlier quoted context omitted.

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.

What do you mean by "powerful"? How is a language powerful? Or not?

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

#63

Post by kuschku »

bad_user wrote: post #50
_0w8t wrote: post #34

Earlier quoted context omitted.

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…

Luckily, Java’s generics are actually changing with Java 10 towards a more powerful system even.

It’s disappointing how Go, in every way, is just Java 2 with a handful of additional libraries.

Simply using Java 2, adding some libs, and compiling with GCJ would net the exact same binaries, with far less work.

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

#64

Post by ruleabidinguser »

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.

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

#65

Post by kuschku »

bborud wrote: post #62
kuschku wrote: post #58

Earlier quoted context omitted.

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

What do you mean by "powerful"? How is a language powerful? Or not?

I mean that you will need to write more, and more duplicate code, to express the same, it’ll be less clear, and less safe.

Generics, and annotation processing with code generation integrated in the compiler, are two example features supported by Java that improve this.

Haskell obviously is a lot better even.

Additionally, it’s also a question if, in the language, any state of the program is immediately obvious from the code – or if the syntax hides things (such as Go’s multi-return errors vs. Java’s exceptions, although Java could use an "ignore" keyword to ignore any error happening in a block or statement)

A powerful static type system can express everything a dynamic type system can, and more. (That’s why I tend to err towards static typing)

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

#66

Post by zephyrfalcon »

rimliu wrote: post #60
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…

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

You are correct. The problem here seems to be that the OP's tests depend on implementation details, which of course shouldn't happen. Presumably this wouldn't occur in a language where you could hide these implementation details (private attributes/methods, etc). That said, Python doesn't force you or encourage you to write your tests like this. Just because it's possible to access the implementation, doesn't mean you should.

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

#67

Post by 46Bit »

rimliu wrote: post #60
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…

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

"Dynamic languages make testing easier," paints a very broad brush. They have some very nice benefits, but also a lot of edgecases.

* An argument might be an int when you expected a float. This can be addressed by casting things with `float()` in every entrypoint, but it's more defensive to require a float and error out otherwise. Either way, problems only appear at runtime. * An object might be null and this only gets picked up at runtime - using Rust it's been very nice to have to explicitly say when things can be null.

I've found it can feel like luck when a complex Python program works correctly for real-world input, but it's also very powerful at getting something done. Tradeoffs.

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

#68

Post by runeks »

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?

This may be solved for Haskell as well in the near-ish future (I assume you're thinking of the GC issues) by the addition of linear types to GHC: https://news.ycombinator.com/item?id=13866787

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

#69

Post by dalailambda »

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 don't see why not, Haskell has green threads, channels, and everything that Go has. The only argument I can see made is that the laziness and current GC implementation aren't suited, and even then, those problems can be solved with strictness pragmas, and a different GC respectively.

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

#70

Post by iagooar »

bobsam wrote: post #12
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…

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 difficult, is a poor choice. We should not accept subpar languages to be used just because.

Post reply on HN