Live data from Hacker News

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

barrucadu.co.uk

311–320 of 363 posts

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

#311

Earlier quoted context omitted.

I wouldn't call it a grand plan, but it is one of Google's five officially supported server languages and as a result there's a lot of work being done to build tools and libraries for it. Code generation and relying on language-agnostic building and packaging systems (bazel) are both pretty common Google-isms, which show how the company's development culture influenced the priorities and direction of the language.

What are the other 4? Python, C++, Java, and what other language?

Javascript

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

#312

Earlier quoted context omitted.

That's a great call out, though I see this in most languages, Haskell and go equally have implicit non local behaviours, but I find the functional paradigm tend to have less, because of side effect free functions.

I'm not yet familiar enough with Haskell to be honest, but languages like Scala, C++ (to the extreme) and to a lesser degree C# and Swift have a lot more support for non local redefinition of syntactic expressions than Go. I totally agree with you about pure functions. They can be a real simplification, but only if any deviation from purity requires special syntax at the call site. Otherwise you're back in the guessi…

but only if any deviation from purity requires special syntax at the call site.

Haskell makes it easy to write data and function types that enforce purity at the call site, throwing a type error if you make a mistake. Not just purity though, you can restrict these types to any arbitrary set of methods of your choosing. This lets you do things like parsing a blob of JSON and having all functions that depend on the result be guaranteed not to have to deal with a failed parse or otherwise invalid data. The fact that the data is good has been encoded in the types, preventing you from passing bad data by throwing a type error.

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

#313

Earlier quoted context omitted.

Currently not, as I only used it in smaller projects in the past. In the future I’ll use it likely with QuasselDroid-NG, an app of mine that’s very early in development, and for which I developed it. The use case there is that we have a list of IRC messages, constantly updating and adding messages at any point of the list, and we want to update the UI and animate. The client can also cache, or preload, messages at an…

I'm not sure if I understand, are you actually using Go for your UI backing or using it as a backend for your application?

The application described above is Java. Runs on Android and desktop Java with JavaFX.

I tried to reimplement the desktop version with Go, due to native UI bindings. And failed.

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

#314
post #199

Earlier quoted context omitted.

Honestly the biggest thing go has going for it is gofmt. Its one of the few things I miss when I work with other languages.

Doesn't every semi-decent IDE have an option to reformat your code? What makes gofmt so special?

No external choices the language dictates style. It ships with the sdk & contributors are expected to use it so there is a cultural agreement out of the box. It's a cli tool so it's immensely scriptable and easy to integrate.

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

#315

Earlier quoted context omitted.

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

I agree generally with this sentiment. It's probably the biggest reason I have such a hard time falling in love with Elixir. Because Erlang is simpler, despite them being largely interchangeable, and that simplicity is extremely appealing.

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

#316
post #91
post #46

Earlier quoted context omitted.

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…

>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. You can. Today. But leave that code in a repo for a month, and it will stop compiling, because some of your dependencies got updated.

Incorrect. You apparently stopped at 'that looks like a URL!' and dreamed up the rest of the implementation to fit some narrative.

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

#317
post #88

Earlier quoted context omitted.

> Despite the buzz about it, I don't see many projects for it other than shellcheck, pandoc and xmonad, and for two of those, there's better solutions around (sphinx, awesome/i3) I tried awesome for two weeks and had one crash. I've run XMonad for 5+ years and had no crashes. Just because they are supposed to accomplish the same things does not mean that they're equal. One is better and it's because of the choice of…

On the other side, I used XMonad for a while and it crashed frequently. I did submit a bug report and it did get fixed, but there was another crash I couldn't be bothered to try to track down, and just switched back to the standard ubuntu shell.

> I did submit a bug report and it did get fixed, but there was another crash I couldn't be bothered to try to track down, and just switched back to the standard ubuntu shell.

Interesting. What was the bug, if I may ask? Do you have a URL for it and the resolution to it?

What do you mean, you "switched back to the standard Ubuntu shell", exactly? XMonad is a window manager, it has nothing to do with shells.

On top of that, do you mean you switched back to bash, which is the standard shell of most distros, or do you really mean you switched to the standard Ubuntu terminal emulator?

There are a few things that need clarification, as what you've said doesn't make much sense in the context of window managers.

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

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

https://github.com/begriffs/postgrest - 8k stars

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

#319

Earlier quoted context omitted.

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

I'm skeptical of declaring what stoicism ought to be applied to. It seems like a generic framework that works at the level of perception rather than a finite whitelist of approved things.

I would consider changing organizations to be an immense cost. It would be perfectly reasonable to apply stoic principles to make peace with language choice. Many of the costs associated from using a tool one believes is inferior are related to one's own emotional reaction to it. If you can conquer that, then you've made yourself a lot more flexible.

I can't imagine how anyone could claim that changing organizations is something that's easy. :-/

Thanks for your comment on charity. I admit that I came on a bit strong after rereading my comment. I sometimes get frustrated quite a bit with your commentary on Go, and I let it get the best of me. Sorry about that.

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

#320

Earlier quoted context omitted.

> has been so incredibly successful in such a short time. 1) Our industry is obsessed with new and shiny. 2) There are a lot of developers and companies who don't have the time to invest in a new paradigm or language. 3) By learning/using golang these developers and companies can look "hip" and forward thinking with minimal effort. With a Java background and a 10 hour investment in golang you can write decent softwar…

The problem is, people tell me that if I just learn Haskell, Idris, Closure, Coffescript, Rust, C++17, C#, F#, Swift, D, Lua, Scala, Ruby, Python, Lisp, Scheme, Julia, Emacs Lisp, Vimscript, Smalltalk, Tcl, Verilog, Perl, Go... then I'll finally find 'programming nirvana'. While you might think it's worth spending 100+ hours learning Haskell, I don't (at the moment) have any reason to Haskell as a better time investm…

I don't know about you, but everything I work on is going to be something that someone will have to maintain, or will be actively developed by multiple people with different categories of expertise. Also, I usually want to build on other people's work (i.e. libraries).

So while I'd love to write big chunks of Haskell, if its just me doing it, that code will be nuked and rewritten unless I also undertake a project of education. So accessibility is key. Go/python/js seem to win in that regard, and likewise in access to libraries.

So unless as an organisation there is motivation to step up skilling, e.g. because there is a lot of money at stake if something breaks (e.g. trading software), or because there is a community of practice (compilers) its hard to see Haskell gaining much ground.

Likewise all those other languages has their niche, and it is hard to seem them displacing each other.

Post reply on HN