Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Python developers need to know before migrating to Go

blog.repustate.com

Post reply on HN
Print view View original

71–80 of 117 posts

Re: What Python developers need to know before migrating to Go

#71

Post by ak217 »

dbaupp wrote: post #54
count wrote: post #50

Earlier quoted context omitted.

'+' is damn near universal. '&&' && '||' !universal.

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

> people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed

No. Cognitive overhead. You pay for it every time you parse these words in your brain. You pay for it by reducing the number of nested/combined clauses that you can parse on the fly.

(This is far from the only readability issue with Go, by the way, and you're right in that it's among the more superficial ones. The language is designed so well in all ways except the one that matters the most, it hurts.)

Re: What Python developers need to know before migrating to Go

#72

Post by n1ghtm4n »

callenish wrote: post #59
skizm wrote: post #57

Earlier quoted context omitted.

I think the majority of the time you want the number of utf8 characters and not the byte count. In fact I have never wanted the byte count. If I did I would expect something like byteLen and Len. Not the other way around. You should be optimizing the common case, not the exception. Obviously I'm not a language designer so perhaps I'm talking out of my ass but I've heard this complaint A LOT.

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 magically slices unicode strings without chopping characters in half.

In Python:

    s = "нєℓℓσ"
    s[1:4]  # "єℓℓ"
In Go:

    s[1:4] // "�є"

Re: What Python developers need to know before migrating to Go

#73

Post by morpher »

Arnor wrote: post #38
TylerE wrote: post #12

Earlier quoted context omitted.

They are, for sure. The difference, I'd say, is that compared to most other mostly-static compiled languages, Go generally feels a bit more velvet glove about it, rather than iron fist. The language principle of warnings are errors really helps here, as you tend to figure out potential issues sooner rather than later, and via a clear error message rather than subtle misbehavior.

Also, if you're using Google App Engine SDK it can compile in realtime (i.e. every time you save a file in the project). So if you have one terminal open to the dev server process and another for your editor, you get instant feedback each time you save. It's a very Pavlovian experience :)

If you use vim, the syntastic[1] plugin has go support and gives you this sort of feedback directly in the editor (for any go code, not just app-engine -- and many other languages) every time you save.

[1] https://github.com/scrooloose/syntastic

Re: What Python developers need to know before migrating to Go

#75

Post by Arnor »

morpher wrote: post #73
Arnor wrote: post #38

Earlier quoted context omitted.

Also, if you're using Google App Engine SDK it can compile in realtime (i.e. every time you save a file in the project). So if you have one terminal open to the dev server process and another for your editor, you get instant feedback each time you save. It's a very Pavlovian experience :)

If you use vim, the syntastic[1] plugin has go support and gives you this sort of feedback directly in the editor (for any go code, not just app-engine -- and many other languages) every time you save. [1] https://github.com/scrooloose/syntastic

Thanks!

Re: What Python developers need to know before migrating to Go

#76

Post by n1ghtm4n »

ak217 wrote: post #71
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).

> people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed No. Cognitive overhead. You pay for it every time you parse these words in your brain. You pay for it by reducing the number of nested/combined clauses that you can parse on the fly. (This is far from the only readability issue with Go, by the way, and you're right in that it's among the more superficial ones. The…

Thank you for expressing it so eloquently.

Re: What Python developers need to know before migrating to Go

#77

Post by 13b9f227ecf0 »

I keep seeing articles about Go where Python developers seem to be shocked to discover that interpreted dynamically typed languages are very slow. This wasn't obvious from the get-go? Practically anything not disk bound will be many, many times faster in C++ or whatever.

Re: What Python developers need to know before migrating to Go

#78

Post by ANTSANTS »

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…

>Python somehow magically slices unicode strings without chopping characters in half.

You need a byte offset to slice a string, and it's impossible to convert from a Unicode rune offset to a byte offset without parsing the entire string up until that point. I'm not all that familiar with Python, but if the language works as you implied, it is basically doing this behind the scenes in common string processing tasks:

  1. The user uses some kind of pattern matching function or whatever to find where they want to split the string. Python returns a rune index.
  2. The user tells Python to go split apart that string along a rune index. It promptly begins parsing the string all over again until it finds the right byte boundaries.
  3. The language then actually creates the new string in between the byte boundaries.
Sure, a Python implementation could statically optimize this, but... why should it have to in the first place? That's fucking stupid and should be considered a language bug when it could be doing this:

  1. User pattern matches blah blah blah and gets a byte index.
  2. User tells their sane language to split the string apart at the byte index and it just does so.
>I know real programmers keep the byte boundaries for all the chars in all their strings in their head at all times

When the hell would you have to remember the byte or rune boundaries for characters in the first place? Why would you be slicing up a string with magic number indices? If you're getting indices from pattern matching functions, you shouldn't care whether they're in bytes or bits or nibbles, you should just be passing them on to your language's split routines (or whatever else you wanted to do). Unless, of course, you're the one actually writing low-level string processing routines, in which case rune offsets are far less useful than byte offsets for the reason explained above.

This Python "feature" seems to exist entirely to keep newbies from getting confused when they attempt to slice up strings in their REPL, for I cannot fathom a reason why anyone would write "s[1:4]" in production code. IIRC, Python was designed for pedagogy, so I'm not surprised that it would take on such a pointless implementation cost just to spare teachers from explaining why "s[1:4] gave me question marks"

Re: What Python developers need to know before migrating to Go

#79

Post by RHSeeger »

dbaupp wrote: post #49
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…

> Using && and || for logical operators in this day and age is just ridiculous No it's not, it takes 10 minutes to learn that && means and and || means or (maybe a little longer to get the hang of it properly), and this knowledge transfers to many programming languages. (This is a little like arguing "we shouldn't use + when English has a perfectly good word 'add'"; symbol reasoning is valuable.)

Plus, && and || are symbols which makes them stand out from variable names. This is, in my opinion, a benefit. Admittedly, though, I prefer {} to block delimiters over begin/end and their like.

Re: What Python developers need to know before migrating to Go

#80

Post by msluyter »

ak217 wrote: post #71
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).

> people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed No. Cognitive overhead. You pay for it every time you parse these words in your brain. You pay for it by reducing the number of nested/combined clauses that you can parse on the fly. (This is far from the only readability issue with Go, by the way, and you're right in that it's among the more superficial ones. The…

I agree with you, but FWIW, if you're already used to C, then the cognitive overhead of && and || is probably negligible. Given Go's pedigree, that doesn't seem too surprising.
Post reply on HN