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

31–40 of 117 posts

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

#31

Post by 16s »

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…

A map is a set. In a map, the key and value can be different things. In a set, they are the same. That's the only difference. They are both associative containers.

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

#33

Post by alok-g »

gamegoblin wrote: post #15
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…

In Java, sets are merely wrappers around a map that maps to a dummy. I guess Go just left off the wrapper.

A wrapper is totally fine really, actually better in some cases (see later). It still allows the programmer to map his intentions directly to the code, and make that intention directly visible to the reader. This adds to the "user experience" for the programmers.

Agreed that such wrappers are then easily built by the programmer himself. But then comes the added pain of including those definitions in everywhere within a project and in-between projects. They become one more dependency to handle.

Then come these wrappers or even whole data structures from third-party libraries. Nearly in every case I see, there is some impedance matching issue with some other libraries, requiring glue-logic to convert from one format to another. [Edit: Plus the added licensing/cost issues for those libraries.]

If a set is just a wrapper around some more generic data structure, it is OK to implement it like that in the library to avoid duplication of code in that library. However, by not making that wrapper, the system is resulting in much more amount of duplicated code in the user space and now with the mentioned impedance mismatch or with weak mapping of programmer's intentions to the code.

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

#34

Post by alok-g »

16s wrote: post #31
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…

A map is a set. In a map, the key and value can be different things. In a set, they are the same. That's the only difference. They are both associative containers.

So what? Got to start isolating interface from the implementation. That implementation inside has overlaps does not mean the interface should be compromised. The latter needs to be designed according to the common needs of the user (here, programmers) rather than the implementation alone. Think "user experience" people!

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

#35

Post by arnehormann »

Zergy wrote: post #16
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…

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…

But if you do use a map as a wrapper, use map[keytype]struct{} . That way the values don't need any memory at all, struct{} is for free.

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

#36

Post by 16s »

alok-g wrote: post #34
16s wrote: post #31

Earlier quoted context omitted.

A map is a set. In a map, the key and value can be different things. In a set, they are the same. That's the only difference. They are both associative containers.

So what? Got to start isolating interface from the implementation. That implementation inside has overlaps does not mean the interface should be compromised. The latter needs to be designed according to the common needs of the user (here, programmers) rather than the implementation alone. Think "user experience" people!

You asked why they would do this. I answered your question. Maps are sets. And by implementing map, you can use it as a map or a set. Perhaps you're not looking for an answer to your question?

Say I implement log, but not log2. If you understand what log is and how to use it, you have log2. If you don't understand this, you ask why log2 is not provided.

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

#37

Post by Arnor »

Some of the items mentioned in that list are the reason why:

"The code you write with Go just seems to be correct."

e.g.

- Having to always check errors (or at least explicitly ignore them) * By the way, do this anyway. It's really nice when every error in your app is handled. Since I've started with Go for a personal project, I've used a similar approach in my sigh PHP project so every error now has an explanation and suggestion.

-Can’t have variables/packages that aren’t used so to test simple things requires sometimes commenting out lines

-Python is more forgiving. You can take slices of strings using indexes that are out of range and it won’t complain. You can take negative slices – not Go.

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

#38

Post by Arnor »

TylerE wrote: post #12
phren0logy wrote: post #11

I can't help but feel like criticisms along the lines of "you have to be more precise with what you want, because unlike python it won't let you get away with blah" and praise like "it seems to run correctly as soon as it compiles" are two sides of the same coin.

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

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

#39

Post by alok-g »

16s wrote: post #36
alok-g wrote: post #34

Earlier quoted context omitted.

So what? Got to start isolating interface from the implementation. That implementation inside has overlaps does not mean the interface should be compromised. The latter needs to be designed according to the common needs of the user (here, programmers) rather than the implementation alone. Think "user experience" people!

You asked why they would do this. I answered your question. Maps are sets. And by implementing map, you can use it as a map or a set. Perhaps you're not looking for an answer to your question? Say I implement log, but not log2. If you understand what log is and how to use it, you have log2. If you don't understand this, you ask why log2 is not provided.

I think I do understand what you are saying. But then, by the same token, so many things are not needed in a programming language. C++ for example has often being criticized for not having a power operator (a^b). Why not just work with a Turing machine (simulated on a computer), then you have everything.

It is not just about having it or not having it. It is also about user experience. Why should I write log(x)/log(2) assuming that is a commonly used operation such that the library could have provided me with simply log2(x)?

Just yesterday there was an user experience related article on confirmation vs. undo. The message was that if most of the users are likely to take the action, then undo is better than confirmation, and if most of the users are unlikely to take the action, then a confirmation is better.

While it is bad to provide every option to the user, it is also just as bad to miss the options that the users commonly use.

The real question then is if a set is commonly required or not. I believe it is used often enough.

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

#40

Post by alok-g »

Zergy wrote: post #16
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…

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?
Post reply on HN