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

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

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.

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.

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

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.

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.

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

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

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.

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.

That's not true, Python 3 uses codepoint-based indexing but it will break if combining characters are involved. For instance:

    > python3 test.py देवनागरीदेवनागरी
    देवनागरीदेवन

edit: the original version used the input string "ǎěǐǒǔa̐e̐i̐o̐u̐ȃȇȋȏȗ" where clusters turn out to have precomposed versions after all. Replaced it by devanāgarī repeated once (in the devanāgarī script)

    import sys
    import regex
    print(regex.match("\X{,12}", sys.argv[1]).group())

[1]: https://pypi.python.org/pypi/regex

I wouldn't hold your breath. The issue tracker[1] suggests 3.7 or 3.8 as optimistic. Guido made some comment somewhere relatively recently, but I can't find where. It's entirely possible it will never actually happen; time doesn't seem to have made people more enthusiastic.

It's a shame, because the new module is awesome.

[1] http://bugs.python.org/msg230846

Ruby's unicode_utils gem has a nice implementation of the standard grapheme cluster segmentation algorithm, and Python's wrapper around ICU works quite well. Go's concept of runes is certainly an improvement, but it doesn't handle combining characters out of the box...

The good news is Unicode 8 will make them way more frequent! (alternate emoji skin colors are specified via combining characters) much as Unicode 6 made astral characters way more "in your face" (by standardising emoji in the SMP)

    $ perl -CADS -E'say $ARGV[0] =~ /(\X{5})/' देवनागरीदेवनागरी
    देवनागरी

Length of output string is: 5 graphemes, 8 codepoints, 24 octets (UTF-8).

  sub MAIN($s) { say $s.substr(0,12) }

  $ perl6 test.p6 ǎěǐǒǔa̐e̐i̐o̐u̐ȃȇȋȏȗ
  ǎěǐǒǔa̐e̐i̐o̐u̐ȃȇ

Could you retry with the input "देवनागरीदेवनागरी"?

  sub MAIN($s) {
  	say "{$s.chars}: $s";
  	my $b =  $s.substr(0,12);
  	say "{$b.chars}: $b";
  }

  $ perl6 hn-test2.p6 देवनागरीदेवनागरी
  16: देवनागरीदेवनागरी
  12: देवनागरीदेवन

The new string is composed of 10 user-visible characters (5 character repeated twice) but 16 codepoints (and this time I carefully checked that there was no precomposed version):

    DEVANAGARI LETTER DA
    DEVANAGARI VOWEL SIGN E
    DEVANAGARI LETTER VA
    DEVANAGARI LETTER NA
    DEVANAGARI VOWEL SIGN AA
    DEVANAGARI LETTER GA
    DEVANAGARI LETTER RA
    DEVANAGARI VOWEL SIGN II
    DEVANAGARI LETTER DA
    DEVANAGARI VOWEL SIGN E
    DEVANAGARI LETTER VA
    DEVANAGARI LETTER NA
    DEVANAGARI VOWEL SIGN AA
    DEVANAGARI LETTER GA
    DEVANAGARI LETTER RA
    DEVANAGARI VOWEL SIGN II

Yes and no. Yes, because the in-development Rakudo compiler is clearly currently giving the wrong result, and no because it operates on grapheme clusters (but has bugs).

(You can work with codepoints if you really want to but the normal string/character functions that use the normal string type, Str, work -- or more accurately are supposed to work -- on the assumption that "character" == grapheme cluster; afaik it's supposed to match the Unicode default Extended Grapheme Cluster specification.)

Fwiw I've filed a bug: https://rt.perl.org/Ticket/Display.html?id=125927

I don't think so. In my tests standard python (2.7 and 3.5) ignores grapheme clusters.

From the strncpy docs:

"No null-character is implicitly appended at the end of destination if source is longer than num. Thus, in this case, destination shall not be considered a null terminated C string (reading it as such would overflow)."

And often times I'll be memset()'ing the destination to all NULLs when doing a string copy operation. I'm not real happy with string handling in C... as if that should be surprising to anyone.

Say, is there nice, small, suitable for embedded use string library anyone would care to recommend in C? I just want a nice string type that carries around its length and storage length, handles copies properly, and has the usual utilities. I suppose I could just write one...

https://github.com/antirez/sds

Why does this deserve the attention of everyone here? The author did not compare languages, he compared his aptitude with these languages, and considered broken implementations to somehow be comparable.

A more meaningful comparison would be to implement simple, efficient, working solutions to these problems and comparing them. This, as it stands, does not lead to any useful discussion.

Seems silly to pick a language based off this single, silly criteria otherwise why not JavaScript or probably other languages that can make the code even smaller?

console.log(mystring.substring(0, 12));

So it just seems arbitrary and weak in my opinion.

Honestly though, the lack of generics for that Math.min function makes me happy I'm not programming in Go.

    if a > b {
        // use a
    } else {
        // use b
    }

[1] https://golang.org/pkg/math/#Max

> This treats things as byte-array instead of unicode, thus for unicode test it will end up printing just 車賈滑豈.

    fn main()
    {
        if let Some(arg) = std::env::args().nth(1)
        {
            println!("{}", arg.chars().take(12).collect::<String>()); // chars() iteraters over codepoints
        }
    }

    fn main() {
        if let Some(arg) = std::env::args().nth(1) {
            println!("{}", {
                match arg.char_indices().nth(12) {
                    Some((idx, _)) => &arg[..idx],
                    None => &*arg
                }
            });
        }
    }

[1] https://crates.io/crates/unicode-segmentation

    import System.Environment (getArgs)
    main = do
      [str] <- getArgs
      putStrLn $ take 12 str

    import System.Environment (getArgs)
    main = putStrLn =<< take 12 . head <$> getArgs

    printf("(%.12s)\n", argv[1]);

In any case, the problem statement (though it's a bit vague) requires building a truncated string, not just printing it.

The low contrast ratio and bright colors on this blog are a bit hard to read. I normally switch to readability mode in safari when I encounter this, but the sites layout prevents this from working.