61–70 of 124 posts
Earlier quoted context omitted.
Type abstractions are fundamentally hierarchical In C++ or Java they certainly are, but Haskell's type classes, for instance, are much more similar to Go's interfaces.
I don't think anyone is going to say that Haskell's type classes in any way fit the traditional notion of a type. It's more the exception that proves the rule in this case.
Go has some really great features, I've written a few thousand lines in it and enjoyed it, but there are some strange hangups that the go designers have that in the end make me think its going to go nowhere. 1. Rob Pike is immensely proud that the language has no generics, but this means that in the last 2 years, there isnt a proper implementation of a linked list that can hold an arbitrary type, or a min-heap, an or…
1. Your characterization of Rob's position on generics is not at all accurate. The Go team's view, in a nutshell, is that generics would offer some exciting possibilities for Go (particularly when combined with its concurrency model) but that it is also extremely hard to do generics well. We have put a huge amount of work into defining and refining Go, and we don't want to break it with a bad generics implementation.
There are plenty of "proper implementations" of these collection classes. Your only criticism of them seems to be that they are not type safe. But it is trivial to implement a type safe wrapper around such containers, if you desire it. So the situation is perhaps a little cumbersome, but no worse than C. I don't think this is enough to doom the language.
2. This appears to be a matter of taste. You find Go's tests hard to read. I find them easy to read, as they're not written in some domain-specific testing language. They're just Go code.
If you need asserts in your Go tests, they're trivial to add with an auxiliary package, and thanks to "go get" it is trivial to install and use external packages.
3. I have carefully reviewed the code of hundreds of new Go programmers (I'm a Go readability reviewer at Google and work on the open source project) and I haven't observed the issues you describe here. I sometimes see an initial confusion about addressability, but it is usually just this: http://golang.org/doc/go_faq.html#methods_on_values_or_point...
4. I think you're wrong. Think of any time you've written an event loop or had to rally multiple threads. I'm confident that in most of those cases you could have done it more cleanly with goroutines and channels.
Finally, look at the state of programming today. Most of the languages and libraries that people use are riddled with idiosyncrasies. The Go language and libraries, by contrast, are amazingly regular. This is not just my opinion, but the feedback that I receive consistently from Go programmers around the world.
I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features): On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing…
1) The 'zen' axis of language syntactic joy.
2) The 'practicality' axis which is a kind of mix of size of the standard library, availability of 3rd party libraries that do Really Cool Useful Stuff and the speed of the resulting binary.
Your toolkit isn't really about the zen axis. It's about the practicality axis, and that's where java with its epic standard library, and c++ with its insanely huge number of 3rd party libraries are the workshop, and go is the empty room with a desk.
I mean, the go standard library is amazing (http://golang.org/pkg/) but its missing some of the features you might want if you're say, trying to build a desktop application on windows...and there just isn't (yet) the 3rd party support for it.
Professional work is, as you say, strongly tied to the practicality axis.
Yet, its worth noting that there are certainly domains that even now go is a better and more practical target for applications than C++ or java, with a comparable runtime speed. Specifically, I'd suggest, cross platform system level tools and web applications.
It doesn't really surprise me that most C++ programmers haven't jumped to go; I'd wager most C++ programmers work on applications that don't cross into these domains.
I find that being able to define your own numeric types and use them as stack-allocated things that use the standard operations is a pretty big deal in C++. I guess it depends on what you're interested in programming.
Also, having a high enough level that you can actually try writing a general-purpose algorithm library without losing noticeable performance to custom-written versions is something C++ at least tries to make possible. The template system is hairy enough to make it a bit questionable just how well you can pull this off in practice though.
Go doesn't attempt either. The arithmetic is what you get in C, implementor-blessed select types and only regular function syntax for the rest of the stuff. If you want to work with interesting mathematical constructs and write in a system-level language, off to C++ you go. The generic algorithms approach is also pretty much what you get in C with void pointers, with some run-time type information added in. You can get more of both expressivity and efficiency if you write your algorithm to handle a specific type, even when the algorithm doesn't have much that depends on that specific type.
I guess C++ is a different subset of the language for different people. Operating system programming doesn't involve mucking around with tensors or quaternions, and it might also involve more hand-tuned choice structures than an armory of genericizable general-purpose algorithms and data structures. My take on Go was that it's a really nice-feeling higher-level replacement for C, and does most everything except the very nitty-gritty hacky raw-memory juggling better than C, but I run instantly into very obvious stuff I can't do which I'd want to be doing with C++.
One thing I also found very tricky to do neatly in Go was a programming style similar to Unix pipes, where you can deploy single or combined general purpose tools to operate on streams of data. Go does have support for first class functions, which handles the tool bit and can even do the combining part (actual pipe characters would need operator overloading though), but the lack of genericity and a stream idiom kill it. There was the exp/iterable package that provided something like this using goroutines, but that got deprecated as non-idiomatic. I don't know if any replacements have shown up.
I do wonder if I'd like my C++ more if it used the duck typing interface thing from Go though. OO in C++ tends to feel a bit of an awkward fit to me.
> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. What I find odd is that he makes this statement, but then doesn't explain which of the following he prefers: 1. Rewriting algorithms again and again for each minor variation of a data type 2. Downcasts everywhere 3. Contorting code to work…
The really odd thing about the original statement is that this guy "can't imagine" working without generics. That is a remark that could only be made by someone who is fixated on modeling all problems in terms of type systems.
Earlier quoted context omitted.
One school of thoughts is that exception is a non-local goto that might span many levels of calls, and that can be non-trivial to understand. Languages without exception has clear paths of return in a function.
True, but so what. The code I like the best is the code I don't even have to write. Having to write all the intermediary code between where an exception happens and where I'd like to handle it is annoying. And the "understanding" argument applies to other things, such as using a compiled language instead of assembly or GC instead of manual memory allocation.
I'm curious how one can file garbage collection under doing less, especially for a language intended for systems programming.
You might be less curious if you had read and understood the talk. Relevant text: "That way of thinking just isn't the way Go operates. Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration." In a language with closures and Go-style goroutines and channels, the amount of programmer effort required to manage memory would be absolutely imme…
That isn't the whole story though. Microsoft Singularity achieved this with the exchange heap: closures and Go-style goroutines and channels can exist without concurrent GC, or even without GC at all on a per-goroutine basis.
It would be interesting to know if Rob and company would be using the language if they weren't also the compiler developers. It's one thing to trust a language with "less" features when you own the compiler and runtime, but another entirely when you do not. Rob and company have the backdoor that any time the compiler is not generating code that is as good as they expect, they can fix it _quickly_! Speaking as a compi…
There seems to be plenty of people that trust Go even if they are not the main compiler and runtime developers, Canonical, Heroku, the BBC, not to mention many startups that have completely bet their business on Go: http://go-lang.cat-v.org/organizations-using-go
Earlier quoted context omitted.
There seems to be plenty of people that trust Go even if they are not the main compiler and runtime developers, Canonical, Heroku, the BBC, not to mention many startups that have completely bet their business on Go: http://go-lang.cat-v.org/organizations-using-go
Certainly. But turn that around --- if all of the major Go developers were at Canonical, even if it were precisely the same language today, would Rob and Google use it?
> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. What I find odd is that he makes this statement, but then doesn't explain which of the following he prefers: 1. Rewriting algorithms again and again for each minor variation of a data type 2. Downcasts everywhere 3. Contorting code to work…
You don't need to pick one of those three. Maps and arrays cover most cases. The rest of the time you can implement capabilities on your types (touched on in the article) and do some type assertions. The really odd thing about the original statement is that this guy "can't imagine" working without generics. That is a remark that could only be made by someone who is fixated on modeling all problems in terms of type sy…
"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
-ESR, paraphrasing Fred Brooks