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

131–140 of 363 posts

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

#131

Post by IshKebab »

twic wrote: post #116
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?

> I hate to sound like the rust evangelist strike force... I really do. But your complaints are exactly what it would solve... Rust doesn't have lazy evaluation, or a particularly extensive standard library. I'm not aware that Rust has heap or thread profiling any better than Go's. For everything else, though, yes. I found Rust pretty easy to learn (coming from Java with a bit of Python background); i haven't mastere…

Rust's library ecosystem is expanding very rapidly. I think it will overtake Haskell's in months rather than years, if it hasn't already.

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

#132

Post by Chris_Newton »

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…

How much have you used Stack with Haskell? The kind of version-related problems you’re talking about are exactly what it’s supposed to fix, and my experience has been that it mostly Just Works, at least if you’re not trying to do something unusual like, say, cross-compiling. Have you found otherwise?

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

#133

Post by kuschku »

cube2222 wrote: post #119
kuschku wrote: post #115

Earlier quoted context omitted.

I’ve actually never used any of them, and none of the devs or ops people I usually talk to used them either. We never even heard of any of those except for CockroachDB. Are you sure these are "dominating the entire industry"-products, as you mentioned before? Or is it more that they’re only used in SV?

Totally not, I'm working in Poland. And, I'm sorry to say, if you haven't heard about Consul, then you're really not in a position to judge if infrastructure tools are or aren't written in Go. Consul is the de'facto industry standard for service discovery for a few years already. EDIT: Cockroach is actually the most SV'ish of all those.

> Consul is the de'facto industry standard for service discovery for a few years already.

So standard that it doesn’t even have a Wikipedia page? Nor is there even one for this specific type of datacenter-oriented service discovery?

This is all pretty niche tech, used by a handful of startups that engineer technology for billions of users, but not used anywhere else. I’ve never seen any companies on national scale operate with this – nor would they need to.

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

#134

Post by TheCondor »

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 don't know how to ask this without it sounding offensive, and I don't intend it that way. But do these "hardcore" haskellers enjoy writing programs at all? Like are there any well known open source apps that people actually use written in Haskell? There are tons of hobbiests and it has a following but what are the examples of its greatness?

I ask as an old SML guy, I like the math theory, I like the promise of better, more accurate and reliable software, I think you can do some beautiful things with algebraic types but I've been dumbfounded by the lack of great examples out there. Ada suffered/suffers the same fate, it has this "academic" pedigree for robustness but not many examples that you can get your hands on. so much expressiveness that doesn't seem to result in much expression.

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

#135

Post by bogomipz »

The author states:

>"Strict evaluation is typically better for performance than lazy evaluation (thunks cause allocation, so you’re gambling that the computation saved offsets the memory cost), but it does make things less composable. "

Can anyone tell me what a "thunk" is in this context and also why it causes performance problems? The article linked to in the sentence results in a 404.

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

#136

Post by mrkgnao »

chriswarbo wrote: post #73
dualogy wrote: post #24

Earlier quoted context omitted.

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.

I've tried to use stack many times; I think I'm up to 5 attempts now? Each time, I've invested many hours trying to make it build; trying to make it find/fetch GHC; trying to make it find/recognise the GHC it's just downloaded; talking to others in IRC/GitHub issues/etc. for help; reading through the source code; trying to hack around brokenness (stack filling up temp dir, GHC misusing bash, etc.). Each time my patie…

Are you on NixOS by any chance? There is a problem with /run filling up that you can fix by using

    TMPDIR=/tmp stack whatever
I switched back to Arch a while back, and I'm not sure if this problem still exists on the NixOS side. (Of course, you can always choose a bigger /run size in configuration.nix.)

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

#137

Post by maloney »

cube2222 wrote: post #119
kuschku wrote: post #115

Earlier quoted context omitted.

I’ve actually never used any of them, and none of the devs or ops people I usually talk to used them either. We never even heard of any of those except for CockroachDB. Are you sure these are "dominating the entire industry"-products, as you mentioned before? Or is it more that they’re only used in SV?

Totally not, I'm working in Poland. And, I'm sorry to say, if you haven't heard about Consul, then you're really not in a position to judge if infrastructure tools are or aren't written in Go. Consul is the de'facto industry standard for service discovery for a few years already. EDIT: Cockroach is actually the most SV'ish of all those.

etcd is also used quite a bit for service discovery, but it's written in Go too :)

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

#138

Post by staticassertion »

bogomipz wrote: post #135

The author states: >"Strict evaluation is typically better for performance than lazy evaluation (thunks cause allocation, so you’re gambling that the computation saved offsets the memory cost), but it does make things less composable. " Can anyone tell me what a "thunk" is in this context and also why it causes performance problems? The article linked to in the sentence results in a 404.

Thunks are values that have yet to be evaluated. For example '3 + 3' could be represented as a thunk, and there's no cost other than memory because you have not computed '6'.

So you're skipping the cost of computation for a value you may never use, but you still have to represent the expression in memory somewhere. This can lead to large thunks building up, eating up memory.

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

#139

Post by kuschku »

cube2222 wrote: post #126
kuschku wrote: post #124

Earlier quoted context omitted.

I mean that the compiler does not check if I’m handling the error. I can easily just ignore the error and work with the value, and therefore have code that breaks if the value might not be there. Any code that compiles should not be able to ever segfault or have NullPointerExceptions or similar.

Well, I never had segfaults. Anyways, it's true, I miss pattern matching on errors. However, in practice, you just get used to it. I haven't had a situation in the past half year where I'd forget to handle the error / check it.

> However, in practice, you just get used to it. I haven't had a situation in the past half year where I'd forget to handle the error / check it.

But with the same argument, you could as well use PHP7.

And this still doesn’t allow you to replace all stdlib datatypes with your own implementations without using custom precompilers.

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

#140

Post by wtetzner »

woah wrote: post #120
jwdunne wrote: post #82

Earlier quoted context omitted.

This is true, from my experience. When I'm screening candidates, I often ask them to solve a problem in their language of choice. They choose PHP, even though I know the same problem solution can be expressed far clearer and shorter in Ruby. Perhaps we are unearthing various kinds of choices i.e choices for best fit vs best convenience. Perhaps that's a case of engineering vs something other.

Despite its checkered past, isn't php these days a more powerful language than ruby?

That's the first time I think I've heard that. I've heard many times that PHP is much better than it used to be, but in what ways is it more powerful than Ruby?
Post reply on HN