Comment by fixxer | Hacker News Reader

Comment by fixxer | Hacker News Reader

Parent Full thread

Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly.

I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done. We march on.

Could I have written this service in C++? Absolutely, but it would have taken me 20 hours to get to the same level of confidence. Maybe some could do it on 2 hours; I'm admittedly not a great C++ developer or frequent user.

Could I have written it in Python? Sure, but I would have had to scale and put it behind a load balancer, adding complexity to get equivalent performance.

From what I've seen of Rust, I like it and plan to give it more time now that it is stable. I haven't spent time with D. I played with Erlang. I don't care for Haskell for anything remotely related to "work", but I don't dispute that it has a place in computer science.

In my 2 years with Go, this is not my first positive experience. I have found that Go works well for cranking out high fidelity, snappy services like this. I think this is the result of the language's constraints enforcing simple patterns. Unlike C++ and Python, there are not a huge number of ways to accomplish tasks (at least not ways that feel natural).

Take it or leave it, but I like Go (for certain things).

I don't understand what I am supposed to take away from this though. If you were a strong C, C++, Java, Scala, Clojure etc developer you could equally deliver a highly scalable solution in 2 hours. I haven't seen anything yet to show why Go is fundamentally easier to deliver solutions except for single binary development which isn't really an issue for server side development.

    > If you were a strong C, C++, Java, Scala, Clojure etc 
    > developer you could equally deliver a highly scalable 
    > solution in 2 hours.

I guess the point is, no, you couldn't. An equivalent solution would be less robust/reliable or take (much) longer. Or both.

With some of this languages it would have been much faster AND much more reliable.

    > With some of this languages it would have been much 
    > faster AND much more reliable.

I don't think that statement is validated out by the body of evidence we have about Go. But, this is all hypothetical, anyway.

I think the language doesn't matter It has more Ton so with Ohr Brain. Sole People feeling Continental with go sind bot. Sole Need generis Sole not. Language doesn't matter too much Write The Language which Young Feel is right foR the job

What was your takeaway from the blog post?

> I don't care for Haskell for anything remotely related to "work"

Why not? Haskell seems perfect for this task. It has fast, robust and safe concurrency and GHC's IO manager is highly optimized and insanely fast.

As a * nix geek it's beneath his station. Welcome to the flip side of the academic ivory tower, the scoff at academic stuff because it doesn't "get shit done".

It does "get shit done" for us perfectly, and type-system only helps here. So I still don't see why it's not suitable for *nix geeks. Give it a try!

I read Dewie3's comment as agreeing with you, albeit via sarcasm and cynicism (and some negativity).

Right you are. I'm here all night.

Try building a package with Haskell dependencies for a linux distribution sometime. It is horrifying.

It's not with stackage. You just do pre-setup:

cabal update && cabal install stackage

Building project:

1. clone a project, cd into it

2. stackage sandbox init

3. cabal install --only-dependencies

4. cabal configure && cabal build

If you already used some "lts version", you can put "stackage sandbox init lts-2.4" to second command and it will re-use existing lts-2.4 sandbox without a need to reinstall anything.

That's it. It takes a very long time first time you build with this with some version of lts stackage, and there is some movements towards binary package sets, but I'm not sure on status of that.

IMO this sums up one of the biggest benefits with Go, and unfortunately goes against your own point. There's no need to know about a variety of community built tools, or what's the "best solution" in language X - the std lib gives you what you need. You can stand up a service quickly because it's simple, and there's no "in knowledge" required.

Just built my project on NixOS with no problems. Built it on Ubuntu with a cabal sandbox, no problems. Using stackage LTS I have no problems. Built it using Halcyon as well.

Building with vanilla cabal I might have some issues, but professional haskeller's use the tools mentioned above.

If you have 20 c# devs, why not code it in c#?

cause that's enterprise BS friend, we gotta be more webscale.

Yes, correctly exposed concurrency is a pretty amazing thing. CSP ftw! You could as easily do it in Clojure, Erlang or any language that supports that.

you could also have written it in Java, or C#, and been done quickly with a solid result.

Not sure why you didn't compare to 2 languages at about the same level, and instead went with a lower level and a higher level language.

> Could I have written this service in C++?

Probably. C++ productivity really relies on knowing good libraries, and having the freedom to use them. Without details, I'd wager you could have done it in 300-400 lines. If you gave a brief overview of what you needed, I'd describe my first instinct for doing it in C++.

Reply on news.ycombinator.com