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

41–50 of 117 posts

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

#41

Post by cmccabe »

beering wrote: post #23

Some of the things they listed are dubious... Writing to a file, there’s File.Write([]byte) and File.WriteString(string) – a bit of a departure for Python developers who are used to the Python zen of having one way to do something Simply because it's not currently feasible to write a function that can have multiple type signatures (via overloading, generics, etc.). Going between []byte and string. regexp uses []byte…

you can't monkey-patch functions into external libraries like you can with Python modules

You can add functions to existing types in Golang.

no preemptive multitasking, so one goroutine can wedge the entire program

That's pretty misleading. If all you write is go code, you can't "wedge the entire program" in Golang just from one thread. You could wedge a native thread if you were using C methods. Assuming you don't want to fix your broken code, you can just set GOMAXPROCS to something high and work around even that.

passing around arrays and structs is by value, leading to unexpected allocation and memory usage

Most developers pass pointers. Pointers are not really that hard in Golang, because there is no pointer arithmetic or undefined behavior.

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

#42

Post by cmccabe »

alok-g wrote: post #40
Zergy wrote: post #16

Earlier quoted context omitted.

Every possible way to represent a set is a very thin wrapper around an existing data structure that is commonly implemented. There isn't a generally applicable way to represent a set. All sets are simply existing structures (BitVectors, Linked Lists, BST, or HashTables) with functions like Union and Intersection being tacked on and all have very different performance considerations. Basically there really isn't a gen…

This would make sense for the case of a set. But does then Go provide (or intend to provide) these other data structures ("BitVectors, Linked Lists, BST, or HashTables")? Does it provide a sorted linked list?

A bitvector: []bool

Most of the time, you would use map[key]value rather than your own hash table or BST.

If you need an implicit linked list, there is one in the standard library: http://golang.org/pkg/container/list/

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

#43

Post by alok-g »

cmccabe wrote: post #42
alok-g wrote: post #40

Earlier quoted context omitted.

This would make sense for the case of a set. But does then Go provide (or intend to provide) these other data structures ("BitVectors, Linked Lists, BST, or HashTables")? Does it provide a sorted linked list?

A bitvector: []bool Most of the time, you would use map[key]value rather than your own hash table or BST. If you need an implicit linked list, there is one in the standard library: http://golang.org/pkg/container/list/

Yes, I noted that list container. If I need a sorted list, do I need to do that myself (which is OK though not ideal)? Or again there is some other container that can work possibly with a wrapper around it to emulate a sorted linked list?

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

#44

Post by pallinder »

"If you’re using JSON and your JSON is a mix of types, goooooood luck. You’ll have to create a custom struct that matches the format of your JSON blob, and then Unmarshall the raw json into an instance of your custom struct. Much more work than just obj = json.loads(json_blob) like we’re used to in Python land."

Could just load it into a map[string]interface{} and then just make sure he does type assertion on the value before using it.

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

#46

Post by n1ghtm4n »

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 that leaving out overloading is "simpler", meaning simpler for them.

- Default parameters are a major convenience that you will miss. Using strings.Replace() to remove some chars from a string? Don't forget to pass the -1 at the end, asshole! The -1 says don't put a limit on the number of replacements. In Python there would be a max=None default parameter and this would never bite anyone.

- No named arguments, because fuck readability.

- Forcing me to handle errors is great. Having 20 different ways to do it is not great. Examples: fmt.Errorf(), fmt.Fprintf(os.Stderr), errors.New(), log.Fatal(), log.Fatalf(), log.Fatalln(), panic/recover...

- Using && and || for logical operators in this day and age is just ridiculous. Why do people keep inventing programming languages as if Python doesn't exist?

- Don't think that just because the Unicode guys invented Go that Unicode is going to be easy. Their solution is not to create an airtight abstraction layer between chars (or "runes" WTF?) and integers. Their solution is to provide almost no abstraction and force you to deal with the inherent integer-ness of all characters. Example:

In Python:

    len("нєℓℓσ")  # 5, because there are 5 chars
In Go:

    len("нєℓℓσ") // 12, because there are 12 bytes
    utf8.RuneCountInString("нєℓℓσ") // 5, plz kill me i am an abomination
tl;dr If you're inventing a programming language for human beings (not UNIX gods), try it out on a group of smart high school students first. It will be a humbling experience.

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

#47

Post by ambrice »

cmccabe wrote: post #41
beering wrote: post #23

Some of the things they listed are dubious... Writing to a file, there’s File.Write([]byte) and File.WriteString(string) – a bit of a departure for Python developers who are used to the Python zen of having one way to do something Simply because it's not currently feasible to write a function that can have multiple type signatures (via overloading, generics, etc.). Going between []byte and string. regexp uses []byte…

you can't monkey-patch functions into external libraries like you can with Python modules You can add functions to existing types in Golang. no preemptive multitasking, so one goroutine can wedge the entire program That's pretty misleading. If all you write is go code, you can't "wedge the entire program" in Golang just from one thread. You could wedge a native thread if you were using C methods. Assuming you don't w…

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

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

#48

Post by wonderzombie »

ambrice wrote: post #47
cmccabe wrote: post #41

Earlier quoted context omitted.

you can't monkey-patch functions into external libraries like you can with Python modules You can add functions to existing types in Golang. no preemptive multitasking, so one goroutine can wedge the entire program That's pretty misleading. If all you write is go code, you can't "wedge the entire program" in Golang just from one thread. You could wedge a native thread if you were using C methods. Assuming you don't w…

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.

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

#49

Post by dbaupp »

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

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

#50

Post by count »

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

'+' is damn near universal. '&&' && '||' !universal.
Post reply on HN