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

101–110 of 363 posts

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

#101

Post by cube2222 »

kasey_junk wrote: post #95
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.

Honestly the biggest thing go has going for it is gofmt. Its one of the few things I miss when I work with other languages.

I think it may actually be the thing I miss the most. (together with implicit interfaces)

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

#102

Post by XorNot »

eptcyka wrote: post #91
XorNot wrote: post #46

Earlier quoted context omitted.

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…

>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. You can. Today. But leave that code in a repo for a month, and it will stop compiling, because some of your dependencies got updated.

Not any of my code (or any of the projects I know) - the solution of the vendor/ is not "smart" but it's simple and comprehensible. My dependencies are locked and explicit - if you can clone my repository, then you also get the dependencies. And no, I really don't care about wasted disk space measured in megabytes.

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

#103

Post by amelius »

thesz wrote: post #97
amelius wrote: post #93

> GHC’s garbage collector is designed for throughput, not latency. It is a generational copying collector, which means that pause times are proportional to the amount of live data in the heap. To make matters worse, it’s also stop-the-world. This is pretty much unacceptable in today's world of low-latency (web) apps. How active is GHC's development? Would it be possible to efficiently run Haskell using Go's runtime e…

If you have not too much data in the heap, you are safe. Even if you have a lot of data there, you most probably fine too. As an example, see here: https://bazqux.com/ and the discussion is here: https://news.ycombinator.com/item?id=5961570 He was able to survive unexpected slashdot effect from being on the front page of Hacker news without even noticing it. He told me he went up one evening and found that there were…

Okay, but surviving a Slashdot effect is different from having a low-latency server of course :)

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

#104

Post by noir_lord »

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 prefer less powerful languages (that have sufficient power to clearly express the domain).

I've found that "powerful" languages allow me to do clever things(TM) and I hate clever things(TM) retroactively when I come back to them.

This gets even worse when you have multiple people on the team doing clever things(TM).

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

#105

Post by cube2222 »

kuschku wrote: post #53
andmarios wrote: post #42

Earlier quoted context omitted.

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.

You know, I think, maybe it's not a coincidence that almost all high-scale infrastructure tooling is written in Go nowadays.

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

#106

Post by AlphaSite »

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…

My biggest problem with it is implicit interface.

I genuinely despise that about it.

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

#107

Post by 59nadir »

gothrowaway wrote: post #99
59nadir wrote: post #88

Earlier quoted context omitted.

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

> 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. I looked in your history and yup, you are partial to Haskell. Why do you feel a need to immediately judge. Why did you say "hard to take seriously". Why didn't you just ask politely for more details? In my opinion,…

> I looked in your history and yup, you are partial to Haskell.

It's convenient that you have no post history to go through, since you decided that the nonsense you're posting shouldn't be tied to your real account.

Your bias is astounding, yet you go for the "your mind was already made up" card. I like Haskell but by no means am I tied to any single language and I'm not the one making posts about how all the users of a language seem to have undesirable traits.

Even better, you then criticize using "personal anecdotes", when that's exactly what you did in order to condemn the users of two languages. You half-dampen it by saying "Maybe I'm just unlucky", but the entire point of your post is "these two communities suck".

> That's your personal anecdote. There's no evidence that the language could have prevented the crash.

Any ML-family compiler will catch more crap at compile time than any C compiler. Adding lua on top will not solve any of that. None of that is opinion. It's just how the languages are designed and how they use types. Adding automatic memory management to that makes the gap even wider and in short, that stops the vast majority of crashes that you can get.

C + lua is great for lots of things, but everything is a tradeoff and here the tradeoff is that you're very likely to get crashes. Good intentions alone can't prevent segfaults and most C software is proof of that.

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

#108

Post by kuschku »

amelius wrote: post #100
kuschku wrote: post #65

Earlier quoted context omitted.

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

> Generics, and annotation processing with code generation integrated in the compiler, are two example features supported by Java that improve this. I think it is fair to point out that generics were not part of the first Java spec. They were added in version 5, see [1]. [1] https://en.wikipedia.org/wiki/Generics_in_Java

Of course not. Early Java was comparable to today’s Go in many ways, and Generics is part of that.

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

#109

Post by kuschku »

cube2222 wrote: post #105
kuschku wrote: post #53

Earlier quoted context omitted.

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.

You know, I think, maybe it's not a coincidence that almost all high-scale infrastructure tooling is written in Go nowadays.

Almost all high-scale infrastructure tooling? Are there many databases, parallelism frameworks, indexing systems, or machine learning frameworks in go?

I’d be interested if you can name any fields where non-Google go projects dominate. I only know of containers.

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

#110

Post by cube2222 »

kuschku wrote: post #65
bborud wrote: post #62

Earlier quoted context omitted.

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

Very little people who have tried errors by value or Either monads (they are basically the same concept in some sense) think that exceptions are better. Exceptions cause your code to be non-linear. Also, it makes them seem like something exceptional (pun intended), whereas you should really carefully handle each error and decide what it implies.

Also, just something I noticed after almost two years of Go. Thanks to library quality I usually end up writing much less Go than Java/Scala for similar applications.

Post reply on HN