Live data from Hacker News

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

barrucadu.co.uk

151–160 of 363 posts

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

#151
post #60

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…

That's simply more precarious than making an anonymous object that adheres to a statically-enforced protocol.

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

#152
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 bett…

I enjoy it so much I quit mainstream tech to do Haskell professionally 5 years ago.

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

#153
post #67
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…

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

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

This point actually frustrates me greatly about C# 7. At some point, there was talk about non-nullable references being introduced into the language, which has been put on hold for at least another version. Personally, I think that feature should have been in the language since version 1. Every runtime error due to a null reference is one too many.

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

#154

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.

I think you exaggerate. Consul is probably the go-to discovery service discovery for new projects at startups and tech companies that aren't afraid of the bleeding edge, but if you count installed base and less bleeding-edge companies ZooKeeper probably still reigns supreme.

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

#155

Earlier quoted context omitted.

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

The thing is, I know a lot of companies using it at nationwide scale (non-startups). I think there's a reason you are getting downvoted. Anyways, Service Discovery like this is less niche than containers are. If containers are still niche for you, then there you go.

> I think there's a reason you are getting downvoted.

Well, so are you, your comments are even so grey I can barely read them anymore (and I can’t downvote you).

Regarding the rest: Containers are far less niche than Consul is. For service discovery, the market isn’t nearly as monopolized as containers are. And containers are far more used than consul is – most places I’ve seen build their own service discovery systems, or hardcode a main node and then have services in containers register with that, etc.

While for containers, at the moment, there’s almost only docker, due to the ecosystem.

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

#156
I think comparing Go and Haskell are like comparing two incomparable different species -- a fish vs. a cat.

Why? Because Haskell is an interpreted language while Go is a compiled one. Interpreted language doesn't care much about performance as it isn't designed for that purpose, while in the other hand, compiled language does. As a result, interpreted language tends to be more 'elegant' and has lots of convenient features at the cost of performance. A concrete example is when you talk about preventing unacceptable data type in Haskell. They could make it so in Go, but the performance cost would be undesirable.

IIRC, I read that they designed Go to be practical instead of 'elegant', the reason is so that people can learn it easily, making it a good alternative for other compiled languages like C++ whose learning curve is hugeeee and ugly!

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

#157

Earlier quoted context omitted.

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.

I think you exaggerate. Consul is probably the go-to discovery service discovery for new projects at startups and tech companies that aren't afraid of the bleeding edge, but if you count installed base and less bleeding-edge companies ZooKeeper probably still reigns supreme.

Definitely. And while ZooKeeper is common, (and apparently Consul is now the hot new thing, I guess?), many places also build their own systems.

I wouldn’t call Consul "industry-dominating technology", as you’d do with ElasticSearch, Hadoop, Spark, etc.

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

#158

I think comparing Go and Haskell are like comparing two incomparable different species -- a fish vs. a cat. Why? Because Haskell is an interpreted language while Go is a compiled one. Interpreted language doesn't care much about performance as it isn't designed for that purpose, while in the other hand, compiled language does. As a result, interpreted language tends to be more 'elegant' and has lots of convenient fea…

Haskell is a compiled language.

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

#159
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?

Probably not. As someone who finds Go cringeworthy, I still find it extremely useful for certain types of programs. I write far simpler Microservices in Go, and I don't feel stupid. It's pretty rough and boring tool, and using it is a chore, but if the tool fits the job well enough, you can get good craftsmanship done even with a hammer.

I think it's in the same position Java found itself in the early 2000s, another boring and unimaginative language that ended up being a workhorse.

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

#160

Earlier quoted context omitted.

> Accept what you cannot change Only you can easily change languages... Stoicism was referring to actual things one cannot change. Like, say, death, or their status as a roman slave. So it's less stoicism and more "our way or the highway".

> Only you can easily change languages... That's a ridiculous blanket statement to make. Changing languages can incur a very high cost. Making peace with this as an individual seems like a useful skill to acquire. If you want to insist then there's no connection to stoicism, then fine, but don't try to pass off language choice as something that's easy to change along the way.

>That's a ridiculous blanket statement to make. Changing languages can incur a very high cost.

Yes, but you can always not even get started with Go (or whatever language you don't like) to begin with, so no change cost there.

Also, you can always change organizations, especially in today's "buyer's market" IT landscape. Better than working with something that you feel makes you miserable and non-productive.

And it's best to apply the principle of charity to what one responds to. Things are not always meant at their strictest interpretation. Compared to the "things you cannot change" stoicism was concerned with (like death, your past, some genetic misfortune, etc.), a programming language is nothing especially unchangeable -- which was my point.

That said, I absolutely love your libs and programs and use them all the time :-)

Post reply on HN