Some of the things they listed are dubious...<p><i></i>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<i></i><p>Simply because it's not currently feasible to write a function that can have multiple type signatures (via overloading, generics, etc.).<p><i></i>Going between []byte and string. regexp uses []byte (they’re mutable). It makes sense, but it’s annoying all the same having to cast & re-cast some variables.<i></i><p>There are actually two different versions of each regexp function: one for strings, one for []byte. Maybe they're using a different version?<p><i></i>No tuples, have to write your own structs or use slices (arrays)<i></i><p>Actually, you can declare a fixed-length array as a type. So if you need to return a triple of ints, you can declare the return type to be [3]int and have the type system check that you're actually returning an array of ints of length 3.<p>Similarly, a lot of the other bullet points are natural results of having a static type system.<p>I was expecting more points like:<p>* you can't monkey-patch functions into external libraries like you can with Python modules
* no generics, so you can't write a generic "map" function, for example
* no preemptive multitasking, so one goroutine can wedge the entire program
* passing around arrays and structs is by value, leading to unexpected allocation and memory usage
* pointers
Some thoughts after spending ~100 hours with Go.<p>- 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 <i>all the time</i>. 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 (<a href="http://golang.org/doc/faq#overloading" rel="nofollow">http://golang.org/doc/faq#overloading</a>) explains that leaving out overloading is "simpler", meaning <i>simpler for them</i>.<p>- 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.<p>- No named arguments, because fuck readability.<p>- 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...<p>- 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?<p>- 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:<p>In Python:<p><pre><code> len("нєℓℓσ") # 5, because there are 5 chars</code></pre>
In Go:<p><pre><code> len("нєℓℓσ") // 12, because there are 12 bytes
utf8.RuneCountInString("нєℓℓσ") // 5, plz kill me i am an abomination
</code></pre>
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.
>> No built-in type for sets (have to use maps and test for existence)<p>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"?<p>I do not get this for other languages as well. Data structures that are present in nearly all computer science books are often not built into the language or standard libraries, like trees, graphs. Reasoning given is that some other data structure could serve as a replacement (never mind that the programmer's intentions are not directly reflected in the code anymore), or because it is considered too removed from practical usage, or because some third-party library includes it. I do not buy any of these arguments.
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.
Many of the things he says he misses from Python, I would rather not have in production code. Heterogenous dictionaries are often objects that should have been, with no encapsulation and a high degree of implicitness that makes them hard to refactor later.
"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."<p>Could just load it into a map[string]interface{} and then just make sure he does type assertion on the value before using it.
This is purely anecdotal on my part, but I've been working on a project for a few months and I've been developing it in Go and it has just been a pleasure to use. It's like C with the edges smoothed out using Python sandpaper.
Is there a decent numpy/scipy equivalent for Go yet? By which I mean an easy way to manipulate matrices, complex numbers perform discrete Fourier transforms and the like.
<i>"No built-in type for sets (have to use maps and test for existence)... In absence of sets, have to write your own intersection, union etc. methods"</i><p>In my mind, a map is a set. They are both Associative containers. It's just that the key and value can be different things in a map while in a set, the key and value are the same thing.<p>Edit: I speak from a strong C++ viewpoint, but maybe Go is not like that (I'm not sure why it would not be): <a href="https://en.wikipedia.org/wiki/Associative_containers_%28C%2B%2B%29" rel="nofollow">https://en.wikipedia.org/wiki/Associative_containers_%28C%2B...</a>
Has anyone tried to integrate Go with Python?<p>Right now, optimizing Python code by replacing critical sections with C works really well and isn't too hard to write or distribute.<p>How well would tooling around doing the same thing with Go work?
Any HN readers of this post have any similar experience?<p>I know the bright team over at bit.ly made a successful switch from python to go-- anyone else?<p>The more I hear about go, the more I like it.
Some of the items mentioned in that list are the reason why:<p>"The code you write with Go just seems to be correct."<p>e.g.<p>- 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 <i>sigh</i> PHP project so every error now has an explanation and suggestion.<p>-Can’t have variables/packages that aren’t used so to test simple things requires sometimes commenting out lines<p>-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.
Here's a previous discussion of this post as well: <a href="https://news.ycombinator.com/item?id=5600883" rel="nofollow">https://news.ycombinator.com/item?id=5600883</a>
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.