Live data from Hacker News

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

barrucadu.co.uk

121–130 of 363 posts

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

#121
post #43
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…

It's stoicism for programming. Accept what you cannot change (tools, language), and focus on what you can change (attitude, striving for great solutions).

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

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

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

We're asked this question a lot (I work at Pusher). I wrote up some of my thoughts on this in reply to a comment on one of our previous blog posts: https://www.reddit.com/r/programming/comments/5fyhjb/golangs... . Right now I'm keen to get more personal experience with Rust, and hopefully in the wider team. I'm particularly interested in [Tokio]( https://tokio.rs/ ), which should address some of our concerns about th…

Small update on that thread: Tokio has now had an initial release, with a lot of docs. Still much more to do, of course :)

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

#123
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…

My biggest problem with it is implicit interface. I genuinely despise that about it.

Why don't you like implicit interfaces, it's the feature I love the most actually?

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

#124

Earlier quoted context omitted.

Go does not have Either monads, or real errors by value. It has a multi-assignment syntax similar to tuple return, but nothing else. For Java, with a tiny library, you can have real Either monads: https://github.com/spencerwi/Either.java I use them in lots of code. For Go, you end up with an assignment syntax where you have to manually check, and get no compiler safety. At all.

You do have errors by value. You return for example two values, the response and error. What do you mean with no compiler safety exactly?

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.

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

#125
post #17
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?

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". But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all dev…

> robust/mature

Needs more context. It's more mature for some things than others, like many young languages.

> how are compile times

Not Go, for sure, but not the worst either.

> how much of a priority are they

Getting them down is a high priority, but has taken some time to make a dent in. The last few releases have all posted speed ups, and "cargo check" in the last release helps. Incremental recompilation is coming, you can try its initial implementation on nightly today. There's a lot more to do, but users really want improvements, so it is and will continue to be actively worked on.

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

#126

Earlier quoted context omitted.

You do have errors by value. You return for example two values, the response and error. What do you mean with no compiler safety exactly?

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.

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

#127
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 prefer less powerful languages (that have sufficient power to clearly express the domain). I've found that "powerful" languages allow me to do clever things(TM) and I hate clever things(TM) retroactively when I come back to them. This gets even worse when you have multiple people on the team doing clever things(TM).

I think it depends what type of "power" we are talking about. Ruby's meta programming stuff certainly falls into the problematic area. A powerful type system might be seen as quite the opposite because it can make code more predictable.

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

#128
post #59
post #45

Earlier quoted context omitted.

But writing Python is a pleasure :( And writing the same thing is Go feels like wasting my wrists for nothing, specially for throwaways and simple web code... Maybe one could write Python and turn a "strict" flag for the module (project?) where you'd have to fill in the types and it becomes Scala-like.

Don't know if you are aware, but python now supports optional type hints.

Is there a runtime that enforces them? I've certainly found them useful in restricting autocompletion, but I've still been able to feed in accidental Nones.

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

#129

Earlier quoted context omitted.

I prefer less powerful languages (that have sufficient power to clearly express the domain). I've found that "powerful" languages allow me to do clever things(TM) and I hate clever things(TM) retroactively when I come back to them. This gets even worse when you have multiple people on the team doing clever things(TM).

> I've found that "powerful" languages allow me to do clever things(TM) and I hate clever things(TM) retroactively when I come back to them. They also allow you to do sensible things(TM) like use the one and single, battle tested, standard library's generic sort, btree, etc implementation, instead of having to roll (and then read) 1000s of your own over the span of a year... And it's a false dichotomy that you can't…

No one is arguing to roll your own when there a generic sort in the standard library. The issue with clever things is that people try to make a all purpose solution for what could be a simple one off solution. The all purpose is only used for 2-3 uses and it never battle tested.

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

#130
post #59

Earlier quoted context omitted.

Don't know if you are aware, but python now supports optional type hints.

Is there a runtime that enforces them? I've certainly found them useful in restricting autocompletion, but I've still been able to feed in accidental Nones.

I have yet to try it, but there are things like mypy and PyCharm apparently has an integrated type checker now.

http://mypy-lang.org/

Post reply on HN