[crawshaw]

There are several ways to solve this in Go. The first that comes to mind, assuming you want to truncate to the first 12 runes, not bytes:

        func main() {
            v := []rune(os.Args[1])
            if len(v) > 12 {
                v = v[:12]
            }
            fmt.Println(string(v))
        }

Or more in the spirit of the C example in the post:

        func main() {
                res := make([]rune, 12)
                copy(res, []rune(os.Args[1]))
                fmt.Println(string(res))
        }

Note that res will stay on the stack, just like C.

I expect the author is trying to say something about Go that I'm not quite getting. Perhaps that it is not an expression-based language, so to make code readable you need to make use of multiple statements. That's by design, but I understand it may be unappealing if you want to program in an expression-heavy style.

[jerf]

"I expect the author is trying to say something about Go that I'm not quite getting."

I assume "Go sucks because, look, this one weird case is a bit ugly." (that is, as rhetoric, not dialectic; it is not literally claiming "one case bad" -> "Go is bad" in the logical sense.) A weird case that I've programmed many thousands of lines of Go code in but never once encountered. Taking a slice out of a string blind like that is actually a bit rare; usually in some way it turns out you actually have length information somewhere in the environment. It's hardly like "slice index out of bounds" is some sort of terrible error... it is, at least, arguable that Python is in the wrong here for being so willing to return a string generated by [0:12] that is not 12 bytes/characters in length, which seems like a reasonable assumption to make of such an operation.

Now, if we want to talk about little examples like this, let's talk about sending on something like a channel in Python, to say nothing of Python's implementation of the "go" keyword... oh, yes, I see, suddenly this is an unfair way to compare languages.

Yes, it is.

[bsaul]

This posts shows two very common issues that programmer have with the GO language when they start using it (that includes me), especially since go is advertised as compiled with the feeling of a dynamic language :

A low-level feeling when manipulating arrays (or slice), and a poor support for generic functions ( that would be math.min in this example).

[jerf]

If it said that explicitly, I'd be fine with it.

But given the last paragraph, I don't think that's the most likely interpretation.

And it's still a terrible way to judge languages without a lot more context. All langauges have gotchas that fit into 3-5 lines. Python's got a pretty decent set: https://www.google.com/search?q=python%20gotchas It's still a good language.

And let me be very clear: I'm not "defending" Go here... I quite like both Python and Go. I've got no trouble saying Python is incrementally easier than Go when it comes to dealing with strings (but both are beat by Perl). (Especially since the incremental advantage comes at a stiff performance price. Sometimes that's fine, sometimes that's not.) I'm specifically saying as computer language polyglot, this metric for measuring languages is terrible. It's a rationalization, not a rational argument.

[bsaul]

I see your point, but after having coded a full (minor) project in Go, i can assure you that those two points alone (cumbersome array data structure and lack of generic code) made me rethink twice about using this language for the common "web service for CRUD to DB" use.

Then i tried to see how did go data access layer libraries look and it finished to convince me not to use it unless performance and memory usage were a crucial matter.

[rdtsc]

> , let's talk about sending on something like a channel in Python:

  import Queue; q=Queue.Queue(); q.put(1)

> to say nothing of Python's implementation of the "go" keyword...

Why would Python have a go keyword? Go doesn't have the "except" keyword that Python has, not sure what the point it?

[pekk]

Go is frequently presented as a replacement of Python. When people hear that, it sets up an expectation that Go will have the same pleasant qualities of Python, when it doesn't, any more than Python has goroutines.

[nkozyra]

Go is more frequently presented as a replacement for C++/Java with a syntax that feels more like an interpreted language like Python or Ruby.

I find that to be totally true. It's certainly lighter to write in than C++ or Java, "go run" effectively feels like running the interpreter and eschewing {} and ; lends to the latter, as well.

And Python has concurrency options as well - "goroutines" is, obviously, relegated to Go.

[pekk]

Interviews with Pike et al. have always made clear that Go actually was made to compete with Java and C++. I wouldn't argue with that.

But the rank and file as represented on HN among other places presents Go as a replacement for Python all the time. It's one of the most common memes about Go. And this sets up expectations Go wasn't designed to fulfill. When a new user honestly reports that Go doesn't fulfill those expectations, we yell at him as for making a dishonest and unfair comparison when really, we set up the dishonest and unfair comparison ourselves when we promoted Go as a replacement for Python. As long as we continue to promote Go that way, we should expect people to compare them, and we shouldn't yell at them for making honest reports that Go and Python are different in ways they are designed to be.

[derefr]

I don't think anyone explicitly marketed Go as a replacement for Python; instead, Go was instead marketed as, for some use-cases (low-level-ish software) what you should have been using in the first place—places where you should have been using C++/Java, not Python, but where Python was used anyway because the alternatives were too unwieldy.

[Jabbles]

fmt.Printf("%.12s", os.Args[1])

[johannesboyne]

+1 for simplicity

[pjmlp]

I assume it has to do with Unicode support.