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

91–100 of 363 posts

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

#91

Post by eptcyka »

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…

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

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

#92

Post by NateDad »

zephyrfalcon wrote: post #66
rimliu wrote: post #60

Earlier quoted context omitted.

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

Tests always rely on implementation details. The implementation details are what you're testing, after all. The problem is relying on the wrong ones.

You can hide all the details you want in the language, unless it's a pure function, there's side effects that can be relied on improperly. Often times this is because of hiding implementation details. A GenerateCert function might read from a config file. It hides the detail that the config file exists, but then to test it you need to create the file in the right spot.

Yes, testing Add(int, int) is easy in any language. No one's struggling with those tests.

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

#93

Post by amelius »

> 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 environment, i.e. by changing the compiler backend?

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

#94

Post by NateDad »

cube2222 wrote: post #54
merb wrote: post #41

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

Does kubernetes take 2 minutes to build? That seems super long. I csn compile juju (1mil LOC) in like 15 seconds.

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

#95

Post by kasey_junk »

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.

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.

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

#96

Post by cube2222 »

NateDad wrote: post #94
cube2222 wrote: post #54

Earlier quoted context omitted.

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.

Does kubernetes take 2 minutes to build? That seems super long. I csn compile juju (1mil LOC) in like 15 seconds.

I haven't compiled it myself but I've read it's something like that. Though I'm not a 100% sure.

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

#97

Post by thesz »

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 tens of thousands of new users actively trying his site. So he added a couple of servers and went to sleep.

GHC development is very active.

And the answer to your last question is No.

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

#99

Post by gothrowaway »

59nadir wrote: post #88
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…

> 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, you already had your mind made up. Just like the blog poster did.

> I tried awesome for two weeks and had one crash. I've run XMonad for 5+ years and had no crashes.

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

And that doesn't make the window manager "better", which is subjective. What are more people using? Awesome and i3. Primarily because they don't want to deal with Haskell when they could be doing lua or a simple config.

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

#100

Post by amelius »

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…

> 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

Post reply on HN