What's happening in Go tip | Hacker News Reader

What's happening in Go tip

dominik.honnef.co

78 pointsradimm51 comments

I'm a professional Java developer, and thought I was fairly trendy because I've introduced Scala in my company's services tier.

About a month ago I started reading HN, and discovered that I'm irrelevant because I'm still using Scala rather than Clojure.

I ordered a Manning book, but before it even arrived I discovered that I'm irrelevant because I'm learning Clojure rather than Node.js.

So I started a couple of personal projects based on Express. However, before I was completely comfortable with callbacks vs. promises, I discovered last week that I'm irrelevant because I'm working with Node.js rather than Go.

Go has been my favorite of the bunch so far. However, I was just started to learn about goroutines and channels, when I discovered three days ago that I'm irrelevant because I'm using Golang rather than Rust.

I like this board, but it should come with a warning label! I haven't been approaching it with the grain of salt that it requires.

Priceless comment.

The alternative, to be like me, a stuck-in-the-past old guy who knows how to use only a few tools really well is probably also not optimal.

But the chase-the-next-fad attitude can be just as lethal for your productivity as having no options at all.

I'm being a more than a bit tongue-in-cheek here. Of course I do enjoy learning new languages, and accumulating at least a basic understanding of the technologies discussed here.

However, I notice that languages wash over HN like waves. A few weeks ago there were a glut of back-to-back Clojure posts. Last week it was all-Go-all-the-time, and over the past few days Rust has surged.

This wave pattern is a cultural quirk of HN, rather than serious indicators of what you should be pushing for within your company, or where you should be taking your career long-term.

I'm about to deep-dive into Erlang so consider me still susceptible to temptation :)

Erlang, in my opinion, is more of a Lisp or Smalltalk than, say, a Ruby, Python or Go: it gets some things really right, and some people will continue to swear by it, but it'll never see mass adoption, and sooner or later, other languages will rip off enough of the good ideas to be 'good enough'.

Erlang is an interesting hybrid between language and operating environment that offers a unique set of trade-off choices. The language itself is not as interesting as the result of these trade offs that translate into a reliability that seems hard to duplicate using other platforms, or at least the platforms that I'm aware of.

That said it is not a silver bullet, split brain problems and other nasties remain hard.

I don't think you can rip off the good bits of Erlang without using the Erlang VM and associated plumbing.

Right, what makes Erlang interesting is the VM and how it's put together, with its own scheduler. It's fairly unique, but something you could replicate elsewhere. Go has a scheduler too, although it's built differently with different goals in mind.

The problem is that you end up needing to do 'real world' stuff, and hit something like this:

http://www.erlang.org/doc/apps/xmerl/xmerl_ug.html

I just spent nearly 2 years on trying to replicate the 'good' bits of Erlang in a less exotic environment. It's been one hell of a ride (I never knew how much I didn't know) but ultimately fruitless because it is simply too much effort to build this for the one application we have for it. So, reluctantly, we have come to the conclusion that it is better to re-use an existing platform even if that means having to deal with the warts of those platforms.

Very frustrating. But then again, if it were easy it wouldn't make the money that it does. A defensible moat that is made out of hard work is a good thing in many ways.

I'd love it if you'd write something about what you learned through that process, what you tried that didn't work and so on. It's pretty significant that you couldn't make something good enough after two years and were driven all the way to Erlang. If that sounds skeptical, it isn't; I believe you, and that is what makes your remark enticing. I want to hear the story.

The reason why I haven't written this up so far is that this is mixed up in a bunch of other stuff, some of which is quite painful to those involved and it is very hard to keep it generic enough that fingers won't be pointed.

As these things go lots of money was blown, egos got frayed, potential customers were disappointed and time was wasted.

All in all a huge learning experience but ultimately mostly a harsh lesson in not biting off more than you can chew and how not to run a project. I was involved as a coder rather than in any other capacity but some of the responsibility for the way the project was run surely rubs off on me. For one I should have probably thrown in the towel earlier when I realized in how many dimensions we were deficit.

There wasn't a single point in time where I thought 'this is not the right way' other than right at the beginning, but once involved (originally just to fix 'a few bugs') I felt that I should give it my 200% to make it work.

Over the course of 2 years mountains were moved but alas that wasn't enough, and funds ran out before we reached a version stable enough that we could run our application on it. In some ways we got pretty close, in others we were still miles away from completion (most notably, the network core and the actual app). Precious time was spent optimizing things that did not need optimization and most of the lessons start-ups learn were re-learned, sometimes (very unfortunately) against better judgement.

I've been asked to look at salvaging this team/project/company and am working together with one of the founders to get things back on their feet in some form, so it is a very delicate situation.

Let me talk it over with the rest of the guys involved and see if they are willing to let me write it up, I wouldn't do it without their buy-in. One potential snag here is that there is still some lingering hope we can re-boot this thing on an existing platform side-stepping the bulk of the development and just concentrating on the app portion (which was my initial preference anyway so I don't mind that).

That makes sense. I thought I was asking a technical question, but it's never purely technical, is it?

> I thought I was asking a technical question, but it's never purely technical, is it?

Well, this one is technical in many ways and there really is an interesting angle there when you remove all the other stuff. That's still going to be a very harsh thing to see black-and-white in public rather than with context in private.

The tech part essentially boils down to 'the right tool for the right job' and don't try to fit square pegs in round holes when you're on a deadline.

The list of 'lessons learned' is rather longer than that ;)

or where you should be taking your career long-term

Obviously, you have to learn Common Lisp if you're thinking long-term - the one language that people will still be using when all the ones you've named will be history!

There was a period of time when there was an absolute flood of Earlang articles posted here, perhaps a couple years ago.

iirc that was to drown out even less desirable articles.

Languages are a tool. They are fun to learn. I always want to use something new on a new project but then I realize that I need to get it done and I need to find people that can maintain it.

That takes the fun out of it. I do think that one can safely bet on scala or go and have fun.

If you have the right architecture you can be as polyglot as you'd like. It's just risky from a maintenance standpoint.

I think the wave pattern is just do to how the web is structured and the way people find new interesting articles. Nothing about the culture of HN.

I don't look at it as being a language irrelevant thing, but more of a critical mass in adoption, and "burn-in" for non-mainstream languages.

If you've been around long enough, you know that something like Clojure, Go, Scala, Python, or even Ruby aren't adopted until a certain level of acceptance is reached, that being often defined by your industry.

At a start-up, anything might go, but at a Fortune 500 company, you might be stuck on a Java 1.4 project. The "drum banging" on HN is often the initial rumblings, or some other point in the adoption curve.

By the way, you forgot about Dart. :-) The performance advantages seem attractive. Is it gaining any traction? One way I try to find out is by seeing if a lot of people are asking questions on StackOverFlow.

http://stackoverflow.com/tags/dart -- 1386 questions so no traction.

A few others:

http://stackoverflow.com/tags/go - 2697. Not so good.

http://stackoverflow.com/questions/tagged/node.js - 27, 301 Someone's probably asked all the basic questions.

http://stackoverflow.com/questions/tagged/scala - 17,933 A little light?

http://stackoverflow.com/questions/tagged/clojure - 5709 - Really light!

If only a few people ask questions a day, and you get stuck jumping in head first, you might regret that later if you're trying to move fast.

Real world example, ...the guys at Twitter went with RoR and ran into scaling problems. Might be different today because RoR has matured?

I wonder if the guys at FourSquare have some growing pains with Scala? If only the build would compile twice as fast...

On the other hand Clojure dates from 2007, Scala from 2003. Comparatively, Haskell has 12196 questions, but it is more than 20 years old.

It is rather unlikely that people were asking questions about any language on stackoverflow before stackoverflow existed.

Scala is becoming much more popular in enterprise and large scale environments.

Mostly because us developers who are working there know that companies like Twitter, LinkedIn, Foursquare etc. are using it and doing so incredibly successfully. And often frameworks like Play2, Storm, Finagle etc are perfect for our requirements.

Don't forget Akka!

And in the roadmap: async/await, macro paradise, scalaz 7

scalding, spark, delite and associated big data cutters

Play, lift3, slick

(look at talk topics to see a lot of what's happening, but not everything

http://scaladays.org/

> http://stackoverflow.com/tags/go - 2697. Not so good.

No one's asking questions because it's too easy and well documented.

I appropriate your comment is meant to be flippant - and while I did enjoy the humour of it, the point you were seeming to raise bothered me a little.

The reason why HN promotes so many different languages and paradigms is because different solutions are better suited for different people and problems. It's not about hopping languages based on the latest bandwagon, it's about people wanting to share their experiences with their new tools.

What's more, just because many of us have got a little exited about Go / node.js / whatever, it doesn't mean that we're turning our back entirely on older technologies (case in point: I've recently made the switch to Go; both for web development and standalone console apps. However I still use shell scripts if I want to bang out some quick sysadmin routines. And I still use Perl CGI if I just need a very quick page thrown together for internal / personal use).

I think it's great to embrace new technologies, but not at the expense of abandoning older technologies when they're a better fit. And I think most people on here are intelligent enough to realise that. So the diversity of languages you see published on HN are the equivalent of the variety of different IDE's or even OS's around - they're not always there to replace each other as they often set out to solve different goals; and nobody is advocating that members of this community should learn and hop to each new language like a Frogger sprite leaps from log to log. Just as you wouldn't be expected to switch IDE's nor OS's every few months.

Hacker News often suggests languages and I try them out. Go, I now use at work, because it's ridiculously productive. Many of the others, I learned about and learned from, even if I don't use them. For example, I don't use Clojure, but my understanding of time and change in programs is improved by Clojure's ideas.

Go looks like a really nice language, but then I discovered that they don't _want_ to have exceptions. Crazy.

I'm sticking with Erlang, "Let It Crash" (and handle the crash) is better than "add if(err) after everything and good luck with that"

> "Let It Crash" (and handle the crash)

panic() and recover() does that. It's not exceptions, but it does exactly that.

It's the supervisor trees that are missing and cannot currently be implemented though.

As a built-in language feature they are missing, but you can and some codebases do implement a kill channel for child goroutines.

As it happens, I've spent the last two days implementing supervision trees for Go, as I'm looking to port some stuff out of Erlang into Go. (There are a couple of existing libraries out there, but they are pretty weak tea, no offense to the authors in question, one of which is kind enough to label their effort with "this is my first Go code".) You can't implement Erlang-style trees without loss, and it's tricky due to some other things, but it can be done and you do get a substantial portion of the benefits, but also certainly not all.

When I pop it up on github here soon, I'm planning on accompanying it by a blog post that will probably end up being longer than the entire library (including test suite and documentation) discussing all the whats and whys of how much you can and can not bring over of Erlang's approach.

Can be, easily. Your goroutine defers a function that calls recover and notifies the supervisor if it was panicking. It's exactly what Erlang does, just done slightly more manually.

> It's the supervisor trees that are missing and cannot currently be implemented though.

On a language level the support seems to be there, and not radically different from what Erlang offers. The pre-built libraries that make up OTP for Erlang aren't there and you have to build your own, but the underlying structure seems to be there.

Go solves a completely different problem to Erlang. Erlang is built for fault-tolerance and its dependence on concurrency stems from the want of having fault tolerance.

Go does not strive to be Erlang, it doesn't even strive to be fault tolerant. Hell, you can deference a null pointer in Go!

What Go is, is an incredibly simplistic language which can be picked up very easily by even mediocre developers. The language looks and feels like an updated and refreshed C.

Whilst Erlang has a much more rich computation model when it comes to using the concurrent actor system, it also comes at a higher price of complexity. I'm an Erlang developer myself and even I wouldn't like to bestow OTP on a complete newbie. Go doesn't have this, the concurrency features are simple, they're not perfect but they work for their intended use-case.

I'm thoroughly enthralled with Erlang as a language but I know that it has some extremely rough edges. You would know what these are yourself and so I won't enumerate them. Go doesn't (yet) have a lot of rough edges as it feels a lot of careful thought and planning has gone into every feature change. Does this mean that you don't have whizzbang features? Yes. Does it reduce the complexity by a huge factor? Yes!

> What Go is, is an incredibly simplistic language which can be picked up very easily by even mediocre developers.

Every enterprise manager's dream!

Nope, that is Visual Basic.

Edit: VB6 - The only Real VB

I agree with you if you are speaking about VB 6.

Not this again.

>I discovered that they don't _want_ to have exceptions. Crazy

That isn't the crazy part. Exceptions are bad, and should not exist. The crazy part is that they don't want to put in useful error handling, so we're stuck with crappy "if (err)" everywhere.

Curious, what would you consider to be more useful error handling?

I would like haskell without exceptions. Haskell has Maybe, Either, etc and a useful standard library to make the Monad instances of those useful. Which allows for libraries like this: http://hackage.haskell.org/package/errors

Similar to Option/Some/None in Scala which is immensely useful

I'm a bit confused. caption is supposed to be length of underlying array of a slice. What does it mean, concepturally, to create a new slice out of an existing one but with a different length of underlying array?

Another thing is, maybe I'm worrying too much but, what if Go becomes more and more complicated that simplicity is not one of its advantages anymore, and people who're new to the language will get scared?

While I don't think the slice changes are particularly out of character for Go, its simplicity is in general somewhat superficial.

The type system is unsound and lacks power (although the interfaces are mostly nice), there are no generics (except for builtin collections), error handling is hard to compose (except in non-idiomatic ways), no real type inference (although single assignments are easier).

Its simplicity is not composable.

Well, conceptually it means you limit how much you can extend the length of the slice inside the array, not that the array has a different length.

For example, we have:

    full := []int{0, 1, 2, 3, 4, 5}
    half1 := full[:3]  // [0, 1, 2]
    half2 := full[3:]  // [3, 4, 5]

Now, the capacity of half1 is 6, so it can "grow inside" half2, such that:

    append(half1, 666)  // Now, half2 is [666, 4, 5]

This may happen even when you are not using append, for example you could do: half1 = half1[:5] and get into half2 again.

The new syntax solves this problem such that, after defining half1 as full[:3:3], if you try half1[:5] you will get an error (the length cannot be larger than the capacity) and if you use append, a new array will be allocated, leaving the contents of half2 intact in any case.

>Now, why is this an issue in real code? Imagine you’re writing your own memory allocator based on []byte – something that’s common when dealing with a lot of tiny allocations that shouldn’t slow down the GC. When the user asks for N bytes of memory, you return a slice that is a slice somewhere from that []byte, with length N. Now the user does something stupid: He appends to it. As we’ve seen before, this append will “leak” into memory beyond the length of the slice, and beyond what the memory allocator intended. You just overwrote someone else’s memory!

So, first: "writing your own memory allocator [is] common when dealing with a lot of tiny allocations that shouldn’t slow down the GC".

Second: "Now the user does something stupid: He appends to it. As we’ve seen before, this append will “leak” into memory beyond the length of the slice, and beyond what the memory allocator intended. You just overwrote someone else’s memory!".

Is this what we want to be dealing with in a 2013 language?

I'd rather have full C-like control than such BS edge cases and having to re-implement memory management myself.

Does Rust have an equivalent location to get nice summaries of future development?

There is 'This Week in Rust': http://cmr.github.io/blog/categories/this-week-in-rust/

That is literally just the past week; there's not really anything for future stuff (there is so much future stuff that keeping track of it all would almost be more work than just going out and implementing it ;) ) other than skimming the mailing list, the weekly meetings and sometimes the devs blogs (which normally get posted to the mailing list and /r/rust on reddit); although the significant discussions do get linked in TWiR, so I guess I kinda lied.

dunno how up to date this is (last edited 3 months ago

https://github.com/mozilla/rust/wiki/Note-development-roadma...

and release notes

https://github.com/mozilla/rust/wiki/Doc-detailed-release-no...

Can't wait for 1.2 RC, there is some good stuff in the pipeline.

Reply on news.ycombinator.com