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…
Three Months of Go, from a Haskeller’s perspective (2016)
151–160 of 363 posts
Re: Three Months of Go, from a Haskeller’s perspective (2016)
#152It 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…
Re: Three Months of Go, from a Haskeller’s perspective (2016)
#153Earlier 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…
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)
#154Earlier 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.
Re: Three Months of Go, from a Haskeller’s perspective (2016)
#155Earlier 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.
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)
#156Why? 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)
#157Earlier 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.
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)
#158I 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…
Re: Three Months of Go, from a Haskeller’s perspective (2016)
#159Earlier 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?
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)
#160Earlier 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.
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 :-)