I am getting interested in Go, and this is a very silly complaint, but I think the name of the language is very bad for easier google searches. I don't know about most others, but google can sometimes be my first point of contact to lookup a function or class in a launguage.
For example: try searching for "ruby map" vs "go map". Google just doesn't parse the keyword 'go' too well. "go lang map" works far better but who wants to refer to a language as "go lang"
This DOES have an effect on adoption and the feeling the documentation is bad as the author comments on.
I don't think you deserved to be downvoted for your comment, but I think it's to be expected with new languages.
When C# first appeared, I searched a few job boards out of curiosity. The "#" symbol wasn't recognized, so I tried "c-sharp". The only listing that came up was for a custodial position that required the employee to maintain a "sharp appearance". If early search results were indicative of a languages chance for success, the only C# jobs available now would be for well-dressed janitors.
Also, the golang-nuts google group is a great place to ask questions.
Another good thing I've found if you just want to see other people's code to learn from- searching through gists for "func main" or a google search for site:play.golang.org on google.
Super pro tip: Gists searches don't have next/previous buttons by default, but you can still add &page=2 etc. to get the other pages.
I found you don't end up searching for go or golang that much...instead you search the package docs on golang.org or command-f through "effective go" or the language spec both of which are well written and readable.
Sadly golang isn't typically used in common-speak, so stackoverflow/google groups postings rarely turn up in search results when you search for "golang + keyword". I've had to use a combination of "go" and "struct" (and other go keywords) to find what I needed. It would save programmer headache if a more distinct name were chosen.
We (the Go users in the know) use "golang", as in: "golang map".
>"go lang map" works far better but who wants to refer to a language as "go lang"
You don't have to refer to it as "go lang", just use the term in searches.
Plus, it's not just the name. Ruby has like 20 years of history and tons of pages interlined, while Go has maybe 1/1000 of that as of now. When we get enough content, Google can deduce from context and popularity what "go maps" mean in a search.
Great to see Go getting more attention. I think it has some real potential to take off. There's a big hole between Java and Python that it could fill with the right kind of community support.
I don't know about JVM, but the concurrency features of Go are amazing, far better than multi-threading in .NET IMO. If an app can benefit from concurrency (and major apps usually can), Go may be a better choice than .NET.
YMMV. With a relatively small bit of concurrency code, for example, I can poll 100 RSS feeds virtually simultaneously; e.g. if the maximum return time of the remote sites is 5 seconds the whole thing finishes in < 6 seconds. If I wanted to bump that up to 1K or 10K feeds I could do that by changing only a constant, because the goroutine for each feed takes only 4K of memory (versus 1MB per thread in C# by default). There may be a way to achieve the same functionality in .NET but having done some multi-threading C# code I doubt it would be as straightforward.
I really like Go, but it just doesn't quite reach the point where I want to use it for everything I do - mainly because it lacks generics.
The philosophy of Go is to keep things simple I know, and generics would inevitably add some degree of complexity to the language, but I feel that addition of complexity would be worth it.
Without generics it just feels like you're writing in Java <= 1.4 again
Go has some selected generic data types: array, slice (think of ArrayList<T>), map, channel, func. I found these to be sufficient for 90% of my problems. In 9% of the cases I craft non-generic data structures based on interfaces, which are specific to my problem domain. For the rest I can live with interface{}.
I really dislike languages which decide to bless some special data-structures, but then won't let me add my own generic data structures.
Of course, I really love data structures, so I can understand other people who just want to get on with things, and are happy to slightly abuse some built-in data structures to get most of the way there.
Go doesn't stop you from building datastructures, actually is really nice for building datastructures.
It simply doesn't provide a simple way to build some kinds of generic datastructures, but when the ones provided by the language are not enough it usually means your problem is specialized enough that a custom datastructure is best anyway, and Go makes that pleasant and easy.
And then there are interfaces, which are a kind of "generics" of their own.
I don't like the special treatment for builtin data structures either. But if the alternatives are ending up in a mental institution (C++ templates) or in a Potemkin village (Java), I'd rather live with this inconsistency for a while.
Maybe (hopefully!) these are not the only alternatives.
I'm currently going through an algorithms textbook and find that algorithms and generics go hand in hand in writing generic, type safe reusable algorithms in your code.
Having to rewrite the same code over and over again to support one algorithm is a real pain in the butt.
...and the interface{} thing is just a workaround that defers type errors until runtime. Which in turn defeats the point of enjoying a type safe language
Indeed, Go goes much further than Java before 1.5, since it does allow you to specify types for maps, lists, and channels.
Still, it would be nice if you wrote, say a matrix package, that you could simply specialize data structures for double or single precision. You see such shortcomings in the standard library as well, for instance for the ParseFloat string conversion functions in strconv, you have to specify the number of bits of the data type. It would be much better if the return type was some generic type for fractional numbers. Now, if you want to have a single precision double, you have to specify that you want to have a 32-bit float and then cast it to a float32.
That said, I believe that Go needs generics, but I'd rather see them implement them properly than to rush.
Different ways to write the same thing don't warrant a language change.
I have Go experience, didn't not find any of the features you referred that different than similar features in other more established languages.
Go is amazing for people with limited language experience, which have not tried the wide spectrum of languages and abstractions that are already available.
Interesting to note the organizational and social aspects of the language being discussed over the "feature set" - does the philosophy of a language (such as encouraging clarity and simplicity) matter more for creating good software?
"if you give clever people clever tools they will use them in clever ways"
>For example, I really would like to have some sort of standard widget library in order to develop GUI applications
So, what's the best candidate for GUI applications? I think we also need an IDE or at least a form builder akin to Visual Studio and WinForms, it's so easy to work on GUI applications and write prototypes it's ridiculous how other projects aren't copying this.
From a pythoner point of view, many if not most parts of the OP's praise of golang would apply equally well to Python. I guess it is because the author seem to have a C/C++ point of view.
I would like to have a pythoner's point of view on golang, so the differences with Python would be highlighted.
I've done primarily python for a while and just started a project in Go. Still very new to Go, so take this all with a grain of salt, but my initial reactions are that:
- it is expressive. I find myself cursing and pull my hair out far less than when I'm writing, say, Java.
- That said it does still feel less expressive than python, but between me just knowing python much better and stack overflow being much more full of python answers, I can't evaluate this objectively.
- Writing (more accurately, updating and maintaining) large applications in python is at times very unpleasant. Pyflakes is pretty good, but bugs like a method name from a different class being spelled incorrectly or having the wrong number and/or types of arguments will inevitably slip into production. I've also found that people use _private naming far too sparingly in python (maybe just because it looks ugly?) which leads to modules that expose dozens or even hundreds of methods to the rest of your app, a huge number of which are unnecessary and end up being used redundantly. The fact that go is a statically typed language built by people who have spent decades working on huge codebases was probably the biggest draw to me.
- Haven't used goroutines or concurrency much yet, but I sleep better at night knowing they're at my fingertips :)
- I feel like I've just scratched the surface of them, but Interfaces in Go are amazing. From what I've seen so far, they seem almost as cool as the Haskell Typeclass system.
- One downside is it has no built-in REPL. But since it compiles so fast I'm sure the third-party ones will get pretty good in a matter of time.
Does anyone know a good tutorial for go ? I tried a couple (including the official one) and I always stopped midway because the way the concepts were introduced seemed unnatural.
For example: try searching for "ruby map" vs "go map". Google just doesn't parse the keyword 'go' too well. "go lang map" works far better but who wants to refer to a language as "go lang"
This DOES have an effect on adoption and the feeling the documentation is bad as the author comments on.
/rant