What Python developers need to know before migrating to Go

Post by neild » Tue, Jul 09, 2013, 4:20 AM UTC

n1ghtm4n wrote: post #72

callenish wrote: post #59

Earlier quoted context omitted.

Have you never had to indicate how many bytes you are sending over a stream, say in the Content-Length of an HTTP response? Have you never put strings into a byte buffer? But that doesn't matter. Let's say you are correct: when working with strings, you more often want the rune length. It still wouldn't be the right decision, given the other design decisions of Go, because it would have needlessly complicated things…

> What happens when you take a slice of a string? What happens when you slice a unicode string in Go is that it cuts multi-byte characters right in half, unless you get the byte boundaries just right. I know real programmers keep the byte boundaries for all the chars in all their strings in their head at all times, but for people like me this basically makes string slicing unusable for non-ASCII text. Python somehow…

    >>> s = u're\u0301sume\u0301'
    >>> print s
    résumé
    >>> len(s)
    8
    >>> for i in xrange(len(s)):
    ...     print s[i]
    ... 
    r
    e
    
    s
    u
    m
    e

    >>> print ' '.join(s)
    r e ́ s u m e ́

Post by jussij » Tue, Jul 09, 2013, 4:26 AM UTC

anona wrote: post #61

dbaupp wrote: post #54

Earlier quoted context omitted.

They're not universal, but they're essentially so; pretty much everyone who's used C(++), Java, C#, ... has seen && and ||, and knows what it is. And people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed (they have the option of spending longer complaining about it if they want).

I don't think the argument is that people can't understand '&&' and '||', but that using 'and' and 'or' is a better choice.

Post by jussij » Tue, Jul 09, 2013, 4:48 AM UTC

rwedf67 wrote: post #66

so you still trust the google compiler for your business critical apps do you? haha

Post by neild » Tue, Jul 09, 2013, 4:54 AM UTC

n1ghtm4n wrote: post #69

lagom wrote: post #63

Earlier quoted context omitted.

Aside from API, there's a convincing performance argument to have len() return the byte count rather than number of utf8 characters. The implementation of strings in Go is a 2-word struct containing a pointer to the start of the string and the length (in bytes). Under this implementation, len(s) is O(1) and RuneCountInString(s) is O(n). It makes sense to have the default case also be the fast one, particularly since…

Why not a 2-word struct with the rune count instead of the byte count? There's zero performance cost for many strings because the rune count is known at compile time. For the rest, most strings are too short for Big-O analysis to be relevant and I would guess (enlighten me if I'm wrong) that the cost of computing the bounds of each character is negligible on a modern processor. Multi-byte chars in a string are going…

    LATIN SMALL LETTER E WITH ACUTE
    LATIN SMALL LETTER C
    LATIN SMALL LETTER O
    LATIN SMALL LETTER L
    LATIN SMALL LEtTER E

    LATIN SMALL LETTER E
    COMBINING ACUTE ACCENT
    LATIN SMALL LETTER C
    LATIN SMALL LETTER O
    LATIN SMALL LETTER L
    LATIN SMALL LEtTER E

Post by cbhl » Tue, Jul 09, 2013, 5:04 AM UTC

n1ghtm4n wrote: post #46

Some thoughts after spending ~100 hours with Go. - Function overloading is a major convenience that you will miss. There are differently named versions of every function and you will call the wrong version with the wrong arguments all the time . The number of functions in the standard library could be reduced by at least 1/4 if they'd got this right. The official FAQ ( http://golang.org/doc/faq#overloading ) explains…