What Python developers need to know before migrating to Go • Hacker News Board

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

#101

Post by wisty » Tue, Jul 09, 2013, 11:57 AM UTC

derefr wrote: post #62

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…

> between chars (or "runes" WTF?) and integers. "Runes" were the original name, as implemented in Plan 9 by the same folks, for what the standards committee later decided to call the relatively blaze term "Unicode codepoints"--and which are not quite the same thing as characters. (In fact, I would say that the notion of a Unicode "character" is ambiguous to the point of uselessness--there are glyphs composed from sev…

> -there are glyphs composed from several codepoints (base glyph + combining accents), which should be treated as one "character"

The solution is to use Normalization Form C (NFC) (which combines accents with characters).

> there are ligatures that hold single codepoints, but which semantically are multiple "characters"

OK, so use Normalization Form KC (NFKC) (which splits ligatures, and combines accents with characters).

You're right that "length" of a unicode string is very ambiguous. Arguably, you shouldn't be able to call "length" without supplying an argument about what you are actually asking.

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

#102

Post by anona » Tue, Jul 09, 2013, 12:04 PM UTC

jussij wrote: post #83

anona wrote: post #61

Earlier quoted context omitted.

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

So what do you do about the bitwise and and or operations. How should they be expressed? Python expresses the bitwise and and or using the & and | characters, the exact same characters as Go. And that also explains why Go chooses to use && and || for and the logical and or operators.

The code is much more readable if the bitwise operators do not look almost identical to the logical ones.

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

#103

Post by liveoneggs » Tue, Jul 09, 2013, 1:23 PM UTC

jlgreco wrote: post #84

liveoneggs wrote: post #67

Earlier quoted context omitted.

I agree with this 100% Who would adopt a NEW google-ism at this point?

Is C an "ATT-ism"?

I keep looking for IEEE or ISO spec for Go and not finding it. I keep looking for alternative compilers and can't find any.

Is there a defined standard library that you can count on for the next decade?

Maybe in 15 years when Go has outgrown its lock-in it may be worth considering. At this point signing on with google is like playing russian roulette.

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

#104

Post by callesgg » Tue, Jul 09, 2013, 1:49 PM UTC

basicly most of the difrences that is mentioned comes down to that one of the languages is compiled.

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

#105

Post by jlgreco » Tue, Jul 09, 2013, 2:14 PM UTC

liveoneggs wrote: post #103

jlgreco wrote: post #84

Earlier quoted context omitted.

Is C an "ATT-ism"?

I keep looking for IEEE or ISO spec for Go and not finding it. I keep looking for alternative compilers and can't find any. Is there a defined standard library that you can count on for the next decade? Maybe in 15 years when Go has outgrown its lock-in it may be worth considering. At this point signing on with google is like playing russian roulette.

> I keep looking for alternative compilers and can't find any.

Really??? How long did you look?

I call bullshit; you did not look. GCC is an alternative compiler. Go away troll.

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

#106

Post by skizm » Tue, Jul 09, 2013, 2:25 PM UTC

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…

> Have you never had to indicate how many bytes you are sending over a stream...

I have and I generally like the syntax to be more explicit (since I so rarely work in bytes): string.getBytes().length

You make all fair points, and I guess it is my opinion that varies then but I think the rule of least surprise would involve returning the rune count for both strings and string slices. Also, wow, range iterates over runes but len returns byte count. That's messed up.

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

#107

Post by ambrice » Tue, Jul 09, 2013, 2:36 PM UTC

wonderzombie wrote: post #48

ambrice wrote: post #47

Earlier quoted context omitted.

Methods for a type have to be declared in the same package as the type.

Fortunately you can embed other people's types within your own type, thereby extending it.

Sure. But that's not monkey patching, that's inheritance.

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

#108

Post by mratzloff » Tue, Jul 09, 2013, 5:05 PM UTC

alok-g wrote: post #8

>> No built-in type for sets (have to use maps and test for existence) Is there any particular reason for this? Sets are so fundamental to mathematics and beyond that I am concerned right away about this. Sure you could use a map as a replacement, but what happens to "user experience"? I do not get this for other languages as well. Data structures that are present in nearly all computer science books are often not bu…

To be fair, Go includes a heap, list, and "ring" (circular doubly-linked list).

I agree that Go should include a Set type modeled after its List. Sets are simple and there's really just one way to implement them. My own is less than 40 lines; a simple set of tests are about 60 lines.

For trees, graphs, etc. I do think it is fair to establish these as the domain of the community. These are more complex, and there is more variety.

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

#109

Post by liveoneggs » Tue, Jul 09, 2013, 5:32 PM UTC

jlgreco wrote: post #105

liveoneggs wrote: post #103

Earlier quoted context omitted.

I keep looking for IEEE or ISO spec for Go and not finding it. I keep looking for alternative compilers and can't find any. Is there a defined standard library that you can count on for the next decade? Maybe in 15 years when Go has outgrown its lock-in it may be worth considering. At this point signing on with google is like playing russian roulette.

> I keep looking for alternative compilers and can't find any. Really??? How long did you look? I call bullshit; you did not look. GCC is an alternative compiler. Go away troll.

gccgo is still from the same google-owned go project.

I'll gladly go away, fanboy.

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

#110

Post by mratzloff » Tue, Jul 09, 2013, 5:53 PM 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…

Have you spent much time in C? Go is directly descended from C, not Python. Its requirements are different.

- If you are passing a number of related arguments, often a struct is a better data structure than default or named parameters.

- I am ambivalent about panic/recover, but have no problem with the rest.

- I do tend to agree that "and" and "or" would be more readable, but it's such a minor issue.

- Regarding your UTF-8 example, I imagine the Go authors believed most Go users would be spending more of their time dealing with bytes than characters. Go is not a language optimized for text manipulation, it is optimized for byte manipulation, like C. This is apparent in the lack of effort put toward optimizing the regular expression engine to date.