

What's happening in Go tip - radimm
http://dominik.honnef.co/go-tip/2013-08-23/

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

~~~
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](http://stackoverflow.com/tags/dart) \--
1386 questions so no traction.

A few others:

[http://stackoverflow.com/tags/go](http://stackoverflow.com/tags/go) \- 2697.
Not so good.

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

[http://stackoverflow.com/questions/tagged/scala](http://stackoverflow.com/questions/tagged/scala)
\- 17,933 A little light?

[http://stackoverflow.com/questions/tagged/clojure](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...

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

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

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

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

Every enterprise manager's dream!

~~~
bsg75
Nope, that is Visual Basic.

Edit: VB6 - The only Real VB

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

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

------
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/](http://cmr.github.io/blog/categories/this-week-in-rust/)

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

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

