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

331–340 of 363 posts

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

#331

Post by mathw »

ruleabidinguser wrote: post #64
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…

>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. As someone whos written code in Haskell (even some medium sized programs) and moved on just fine, no. Frankly, Haskell can be an excercise in frustration.

I'd concur. It's mostly around tooling for me (and Stack has helped here) but whenever I pick up Haskell for an out-of-work project now I end up putting it down again. I find Rust increasingly pleasing, although the lack of constraints on side effects is frustrating compared to Haskell's purity.

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

#332

Post by prance »

crimsonalucard wrote: post #191
TheCondor wrote: post #134

Earlier quoted context omitted.

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…

Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there. The great thing about Haskell and other functional programming languages is that the functional style force…

> Haskell is actually less expressive. It is a functional abstraction on top of what is essentially a procedural machine and with all abstractions placed on top of lower layers you can only lose functionality as you go up rather than gain. You could say assembly language is the most expressive language out there.

That is not what is usually meant by "expressiveness" of a language. You seem to be talking about types of languages (as in the Chomsky hierarchy), by implying that there are problems you can solve in assembler but not in Haskell. That is not the case, as both are Turing-complete (Type-0).

In contrast, "expressiveness" usually refers to the "ease" (one may substitute conciseness in most cases) with which higher level concepts (abstractions) are expressible in the language, and here Haskell clearly wins against assembler, and many other popular languages.

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

#333

Post by Veen »

im_down_w_otp wrote: post #250
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 experience this depression constantly. It's very rare to find people or places using Erlang, the community is extremely small and seemingly getting smaller all the time, and new things attempting to approximate its core strengths (often badly or incompletely) keep coming to the market and only further exacerbating the situation. So I end up stuck working with crappier tech, crappier tools, and dealing with the effe…

What are your thoughts on Elixir?

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

#334

Post by coldtea »

SwellJoe wrote: post #264
notjack wrote: post #263

Earlier quoted context omitted.

Go has one of the largest tech companies on earth actively pushing it and pouring countless programmer hours into developing tooling and support for it. That pretty much trumps all of its misfeatures in terms of gaining adoption.

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…

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

Well, Google doesn't put as much money into Go either (as MS and Sun put into Java and C#). Sun and C# had much bigger teams, much bigger budgets, and tons of marketing money spent on them, including actual ads everywhere. Just the team writing the C# documentation was probably bigger than the whole Google Go team.

But that's relative:

Unlike most OSS/community driven languages (e.g. Nim or Julia), Go has a big enough team that's paid to work on Go. That makes a difference.

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

#335

Post by merb »

cube2222 wrote: post #96
NateDad wrote: post #94

Earlier quoted context omitted.

Does kubernetes take 2 minutes to build? That seems super long. I csn compile juju (1mil LOC) in like 15 seconds.

I haven't compiled it myself but I've read it's something like that. Though I'm not a 100% sure.

with all dependencies (first time compiling) it takes way longer than 2 minutes.

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

#336

Post by _0w8t »

camus2 wrote: post #36
_0w8t wrote: post #31

The author mentioned that code generation "introduces additional, non-standart syntax". One can say exactly the same about generics. Most useful typesystems with generics are Turing-complete. Essentially they introduce own language for types with often very weired rules and syntax that one has to master on top of the basic language. With code generation I can program my types using the same language I use for code wi…

> With code generation I can program my types using the same language I use for code with less things to learn. With code generation you are introducing your own compiler, DSL and all that bullshit that becomes yet another dependency you have to manage. That's busy work, that's bureaucracy, that's brittle. Now your codebase depends on pragma statements, manifests and obviously a specific syntax that aren't even manag…

In Go one can use template library to add custom generics using already known syntax. Essentially it will be Go source with familiar template annotations. Surely it is still a non-standard language, but the setup is trivial and extra flexibility of custom DSL may suits some projects better than hypothetical Go-with-generics.

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

#337

Post by chriswarbo »

mrkgnao wrote: post #136
chriswarbo wrote: post #73

Earlier quoted context omitted.

I've tried to use stack many times; I think I'm up to 5 attempts now? Each time, I've invested many hours trying to make it build; trying to make it find/fetch GHC; trying to make it find/recognise the GHC it's just downloaded; talking to others in IRC/GitHub issues/etc. for help; reading through the source code; trying to hack around brokenness (stack filling up temp dir, GHC misusing bash, etc.). Each time my patie…

Are you on NixOS by any chance? There is a problem with /run filling up that you can fix by using TMPDIR=/tmp stack whatever I switched back to Arch a while back, and I'm not sure if this problem still exists on the NixOS side. (Of course, you can always choose a bigger /run size in configuration.nix.)

> Are you on NixOS by any chance?

Yes. That's the issue I alluded to with "stack filling up temp dir".

Off the top of my head, other issues include:

- Bootstrapping GHC from old versions. This tries to run a script with a non-existent `/bin/bash` shebang. A more portable version would be `/usr/bin/env bash`, but since bootstrapping relies on out-of-date versions this can't be changed. Since such paths can vary depending on the OS, the right thing to do is using what the OS provides, rather than making yet another attempt at cross-OS/distro packaging for a one-off app.

- When using "Nix integration", to try and avoid GHC bootstrap hell, the "lts" releases written in various project's "stack.yaml" files is assumed to correspond to a key in the `(import {}).haskell` attribute set. Except that a) different projects use a variety of these identifiers, which may or may not correspond to actual keys, b) nixpkgs doesn't actually contain any of these identifiers anymore https://github.com/NixOS/nixpkgs/issues/14897

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

#338

Post by pjmlp »

imsofuture wrote: post #197
pjmlp wrote: post #18

Earlier quoted context omitted.

Yet, at least we can use proper versions instead of Git urls that are exposed in source code.

This is a fundamental misunderstanding of how go dependencies work. Dependencies are simply package names. It just happens that names are actually meaningful and tell you where you, the developer can get the package. Using vendoring and/or Godep/glide, you then strictly version and manage your dependencies. `go build` doesn't just run `git clone` or something.

So what is the approach when package X happens to change their Git path, change to another SCM server, or migrate the project to the next cool SCM tool?

On any sensible package management system, as a user of the said package, I won't need to change anything.

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

#339

Post by pjmlp »

dualogy wrote: post #28
pjmlp wrote: post #18

Earlier quoted context omitted.

Yet, at least we can use proper versions instead of Git urls that are exposed in source code.

These import paths aren't really URLs. They're local import paths, where Go's out-of-box tooling additionally allows for far simpler package install/update flows when one chooses to have these local paths replicate remote-repo URL paths. One doesn't have to, but it essentially turns "any CVS" into what would be Hackage/Stackage in the Haskell world. Sure, no curation, but `go get repo-url ` has its charms too for qui…

Those urls will change if upstream happens to change to another SCM provider or tooling.

Whereas in any sensible package management system the package names and versions will be unaffected by such changes.

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

#340

Post by koffiezet »

kuschku wrote: post #115
cube2222 wrote: post #113

Earlier quoted context omitted.

Service Discovery and configuration (Consul, etcd), Monitoring (Prometheus and Influx), non-container cluster management (Nomad), databases (CockroachDB), messaging (NATS, Jocko), Terraform. Other than that, I think everybody noticed the frequent posts "xxx database written in Go". Also, most high scale computing companies now use Go for their infrastructure parts. EDIT: You can also check out all the stuff the CoreO…

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?

In the ops world, these tools are pretty much the standard. If you look at the state of many of the tools targeted at infrastructure were, with in the best scenario a decently maintained Python code-base - it's no surprise the ops world jumped on Go.

Go's main attraction there is that it's a simple, script-like language that compiles to easily deployed static binaries. That enables people who's main job is not necessarily coding, but with a good scripting background to solve problems by writing more complex/performance-critical stuff which was previously not feasible in languages like Python, Ruby, ...

These projects requiring more performance would have required a seasoned dedicated C/C++ coder before, but now they can be started and maintainer by people initially not focusing on programming, but on solving problems they are facing in their daily job. They don't have the time to invest learning a language with complex typesystems where initially, you'll be fighting the language itself more than solving actual problems. For programmers, this investment is useful, it's their main skill and is worth something. Ops people have other things to worry about, and just want to solve problems.

It does mean wheels are being reinvented, but the major projects now have pretty smart people working on them, hitting the limits of the language and it's garbage collector, pushing them forward.

Post reply on HN