What's happening in Go tip

[StevePerkins]

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.

[laumars]

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.

[melling]

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

[JulianMorrison]

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.

[jacquesm]

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.

[MartinMond]

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"

[AeroNotix]

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!

[nolok]

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

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

[dchest]

Not this again.

[asdasf]

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

[songgao]

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?

[yiyus]

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.

[lucian1900]

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.

[coldtea]

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

[jzelinskie]

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

[newgame]

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

[gtani]

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

[knodi]

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