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

301–310 of 363 posts

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

#301

Post by ocharles »

TheCondor wrote: post #134
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 bett…

I have been writing Haskell professionally for about 4 years now, and I absolutely love it. I'm constantly finding myself having to answer questions of "So, what do you mean?" or "what is this" so early on in development. Never before have I had a language that is so directly tied to my understanding of problems.

On the practical side, I love having types that let me refactor so mercilessly, along with a very mature compiler with a decent suite of warnings.

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

#302

Post by bborud »

kuschku wrote: post #236
bborud wrote: post #219

Earlier quoted context omitted.

So when you say a language is "powerful" you are talking about its level of abstraction? Because then we should probably try to call it something else so as not to confuse "power" for technical ability to deliver performance or productivity.

Definitely, the measurement of how "powerful" a language is directly corresponding to its level of abstraction. It does not necessarily mean that any dev can code faster – or even similarily fast. But it means that much of refactoring usually is easier (as you’ll have less duplicated code), that you get more guarantees, that you have less boilerplate, etc.

Then I'm not sure if "powerful" is necessarily what I look for in a language.

I have three priorities when programming:

  1. Correct
  2. Understandable
  3. Fast
Priority 1 is non-negotiable (code should be correct, or the rest is moot). Priority 2 is negotiable in situations where priority 3 isn't, however I've had this happen perhaps a handful of times in the last 25 years.

Being able to produce code quickly is nice, but unimportant if the code isn't likely to be correct, understandable or fast. Productivity in production code is measured in how you achieve the above.

Likewise it is nice to have code that is easy to refactor and doesn't require duplication, but duplication is more permissible than the dogmatic avoidance of duplication when it is detrimental to understanding or speed. It can also lead to unnecessarily bothersome abstraction or spending too much time creating abstraction where the domain doesn't naturally lend itself to abstraction.

(Note that points 2 and 1 tend to dictate that duplication should be avoided: it isn't about the typing saved, it is about correctness.)

Priority 3 could be elaborated as "quick response times and avoidance of unnecessary resource use". Any idiot can write code that does X. A craftsperson writes code that does X well. A valuable craftsperson can do X well and quickly. Be a craftsperson.

For rapid prototyping you can throw the rules slightly overboard, but when you write production code things count.

Abstractions and language mechanisms that can give you static guarantees are good when they help you achieve the above. They are counter-productive when they conflict with any of the above. It is easy to become counter-productive when you try to satisfy some dogma.

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

#303

Post by bborud »

cube2222 wrote: post #228
bborud wrote: post #223

Earlier quoted context omitted.

I think Go has made a lot of people re-think their assumptions about what makes a language a good language. I have yet to figure out precisely what it is that makes me more productive in Go (which I have relatively little experience with) than Java (which I've programmed since the first beta).

Make sure to write some blog post about it when you do! I'd be very curious to hear what it is.

At least one thing I can say right away is that they have taken care of a lot of small hygiene factors. Things like the rapid compiler, the "go" command that has a lot of nice things built in, the way they did away with formatting discussions (although I can't articulate how it differs from other languages that try to do the same....probably the tooling).

The Go community also prefers libraries over frameworks. Coming from Java, and its humongous, cancerous framworks, that's a BIG selling point. I notice that when someone posts a link to a "Go framework" I get slightly ticked off and I feel resistance even before I've clicked the link.

As for the language: I don't know yet. It just works for me. :)

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

#304

Post by icebraining »

raulk wrote: post #293
icebraining wrote: post #238

Earlier quoted context omitted.

Yes, but that's a red herring. Outside maybe of the JavaScript world, the available tooling isn't divided into immature and near legacy. Haskell itself is a good example of a mature language still growing in popularity.

All I'm saying is that it's unfair to discredit the argument that Haskell has been around for 25 years, hence its had more time to evolve a more complete tooling offering. It is a valid argument. If Haskell didn't exist and had only been launched a few years ago alongside Go, what would the status of its tooling be today? That would be a fairer comparison. Obviously one can't measure it objectively, but you do have a…

This is sounding like a golang version of "Leave Britney Alone".

The author wasn't accusing the creators of Go of being incompetents and unable to produce good tools. All was said is that currently, the tooling is not as good as Haskell's. That Go is a newer language is not a valid argument for rebutting that claim - it's only an explanation for it.

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

#305

Post by SwellJoe »

im_down_w_otp wrote: post #273
SwellJoe wrote: post #264

Earlier quoted context omitted.

So, it's previous analogs are Java and C#? That doesn't feel quite right, either, in that Google makes no money from Go; Java and C# are both direct moneymakers for their respective stewards. I haven't really seen Google pushing Go that hard; it feels like a skunkworks project that just happened to catch everybody's eye (including the company it came out of), rather than a grand plan to conquer the world of programmi…

It seems like everyone wants to believe they have Google-shaped problems, and thus should mimic Google in as many ways as they possibly can. Is some component of it that? Whether or not it's part of some grand plan? This happens in hiring practices, in programming languages, in infrastructure tech, in data tech, etc. It's extremely rare to encounter a data scale problem that actually requires a Hadoop-ish deployment,…

There's a lot of Java at Google, so it wouldn't be surprising that Go would be Java-esque. But, I find it more like C. It has literally no accommodation for "enterprise" things. It's kind of its own thing that bubbled up out of a parallel timeline (which is kinda true, since it evolved out of the Plan 9 ecosystem and from Plan 9 developers), without much baggage from the couple of decades of commercialization of languages.

It's a pretty close to pure expression of a few language designer's vision, with very little in the way of corporate influence (that I can discern). And, I think that's the point of Go; it's the language its designers wanted for the tasks they wanted to work on (web scale services). It just happens that a lot of people want/need to work on the same sort of thing.

I agree that most people embracing massive scale are doing so way too early and probably aint gonna need it. But, that doesn't mean Go isn't a useful tool, anyway. I've watched a few videos, and read a few tutorials, and the brevity of Go for things like network servers is breathtaking. The cleverness of interfaces is...well, it really has to be seen to be understood. It's not OO, it's not functional. It's...something else. Contrary to the impression that maybe I've given in other comments, Go does have some features that aren't commonly seen elsewhere (or, if they are, they're bolted on). It has some fancy features, but only a few, and only in specific areas.

It seems like a very well thought out language, to me. Which might have been true of Java in its very early days...I'm not sure. I've never really been a Java developer, though I've read some Java code now and then.

So, Go might be merely "good enough" on some fronts, but I think it's great on a few specific fronts. And, it does it without requiring total buy-in on a new paradigm, which is probably its killer feature. It looks a little like Python or whatever in syntax, but acts a little like Erlang on a few specific details. Pretty good combination, and the community seems to agree.

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

#306

Post by the_why_of_y »

theseoafs wrote: post #158
blacksoil wrote: post #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 fea…

Haskell is a compiled language.

There is no such thing as a "compiled language" or an "interpreted language", as this is a property of language implementations: interpreters (GHCi, Hugs) and compilers (GHC, JHC).

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

#307

Post by crimsonalucard »

platz wrote: post #266
ngrilly wrote: post #262

Earlier quoted context omitted.

I don't understand the downvote. The main argument looks valid: > If you have several tasks to execute, what is your first thought on how to plan out those tasks? A task list (aka list of functions) or a series of composed tasks placed in a single sentence (aka expression)? The answer is obvious: humans think about the list first because procedural programming comes more naturally. This I believe is the main reason w…

I'm not the downvoter, but I still don't understand the assertion why Haskell doesn't allow the "task list". There is nothing preventing using these "task lists" (e.g. lists/steps/procedures) in Haskell. In fact, "do notation", a core language feature every beginner learns, features it.

You are right, but no beginner truly understands do notation. It's just magic to them. Do notation is an abstraction on top of monads which is an incredibly hard to understand abstraction on top of functional programming.

Functional programming in essence does not allow procedures, but with special incredibly complex abstractions you can simulate procedures. If you program using said abstractions I would argue that it makes functional programming even Harder to understand.

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

#308

Post by platz »

crimsonalucard wrote: post #307
platz wrote: post #266

Earlier quoted context omitted.

I'm not the downvoter, but I still don't understand the assertion why Haskell doesn't allow the "task list". There is nothing preventing using these "task lists" (e.g. lists/steps/procedures) in Haskell. In fact, "do notation", a core language feature every beginner learns, features it.

You are right, but no beginner truly understands do notation. It's just magic to them. Do notation is an abstraction on top of monads which is an incredibly hard to understand abstraction on top of functional programming. Functional programming in essence does not allow procedures, but with special incredibly complex abstractions you can simulate procedures. If you program using said abstractions I would argue that i…

Look, I'm not saying Haskell is easy to learn, it's one of the steepest learning curves I know of in programming.

But I don't think do notation is what trips up beginners (not sure if this discussion is about beginners per se). It is explained by simple mechanical plug-and-chug transformations that I think beginners understand, but am willing to hear if there is evidence otherwise.. I just think it's the other things that will eventually trip them up (I was only responding to specific claims made earlier). Also, on the point of resting on abstractions being a problem, I don't find compelling, because I'm also sure that Python beginners don't understand what "class MyStuff(object):" is really doing, but if the abstraction isn't leaky try don't need to know right away, and they can delve later.

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

#309

Post by jrobn »

Buttons840 wrote: post #292
jrobn wrote: post #49

I started out liking Go. It looked like a fairly pragmatic language. As I got deeper into my evaluation project (simple api stuff) it felt more and more like cutting wood with a dull saw. I started out liking Haskell too! But has I moved along with my small evaluation api project it felt more and more like I was trying to cut wood with gyroscopic laser saw. It worked but it was a lot of fan fair for sawing some wood.…

My impression of Elixir and Erlang are that they are the only dynamic languages I'm aware of that seem to have dynamic typing for solid technical reasons. Many languages are dynamic just for user experience reasons. But the way the BEAM VM handles hot code swapping, concurrency, and memory management, etc, required using a dynamic language. (As far as I'm aware?)

I think it's because of the built-in nature of message passing in the language. It's just easier to send around messages to processes. Hot code swapping would be possible with other JITed languages (BEAM isn't a JIT).

Also since erlang has excellent pattern matching (even on binary data!) and a supervisor system (OTP) errors are easy to recover from. Erlang takes a very pragmatic approach of building tools that deal with errors by recovering from them instead of trying to exhaustively trying to prevent them.

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

#310

Post by psiclops »

SwellJoe wrote: post #305
im_down_w_otp wrote: post #273

Earlier quoted context omitted.

It seems like everyone wants to believe they have Google-shaped problems, and thus should mimic Google in as many ways as they possibly can. Is some component of it that? Whether or not it's part of some grand plan? This happens in hiring practices, in programming languages, in infrastructure tech, in data tech, etc. It's extremely rare to encounter a data scale problem that actually requires a Hadoop-ish deployment,…

There's a lot of Java at Google, so it wouldn't be surprising that Go would be Java-esque. But, I find it more like C. It has literally no accommodation for "enterprise" things. It's kind of its own thing that bubbled up out of a parallel timeline (which is kinda true, since it evolved out of the Plan 9 ecosystem and from Plan 9 developers), without much baggage from the couple of decades of commercialization of lang…

I post this pretty often when the conversation of design choices behind Go comes up. [0] There is definitely a heavy C and Plan 9 influence on it.

[0] https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Post reply on HN