91–100 of 124 posts
* Easier to learn
* Faster to compile
* Better performance
* Better abstraction
* Mature tools
Earlier quoted context omitted.
Your metaphor certainly resonates with me, but there are two mixed concepts here: 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…
IMHO, its not fair to compare Go libraries (at this stage) with the more mature implementation of libraries in C++ and Java. That will come with adoption, but even at this early stage, the set of libraries that come with go offer a lot of power. Agreed Java came out of the gates with a good (??) desktop programming library. Google Go's library on the other hand is very web oriented with the building blocks of http, t…
It's not about being 'fair', it's about being practical. If a project has a need for X, a programmer cannot wait until X feature of lib is added to a language to start his work.
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
It's AFTER the startup phase that you rewrite your messy infrastructure (see Twitter, Facebook, etc), and that's when you need mature and capable tools.
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…
Allow me to respond to your points. 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…
Wouldn't it have been a good idea to take generics into account from the very start?
Earlier quoted context omitted.
Some people don't trust black boxes because they have been burned too many times in the past. I don't want to make this an age thing, but in my observation the people who are chomping at the bit to jump on the next big thing are generally those who haven't yet really suffered because of someone else's mistake. Cryptography's got the right attitude. Don't use things that are proven to be broken, but at the same time d…
I'm 34. I started teaching myself software development when I was seven. I have done PC assembly, C, C++, OpenGL, Win32, MFC, OCaml, .NET, PHP, Python, Twisted, AS3, JavaScript, WordPress, CoffeeScript and other types of programming. I have suffered because of mistakes in the underlying platform implementation in some cases, but in my experience more often I am suffering because of fundamental design limitations of t…
All of those assumptions are broken, some more heavily than others...
Earlier quoted context omitted.
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.
That's funny. I don't mind writing code. The code I like the best is the code I don't have to debug .
The code you don't have to write, you also don't have to debug.
So you SHOULD mind writing code.
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…
Allow me to respond to your points. 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…
Actually, this is not totally true. C has pre-processor and void * which allows for simple generic data structures with no performance impact. go ties your hands here since you have to use type-assertions which are not free, unlike C casts.
> 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.
Goroutines are great, but synchronous channels are not at all easy to use beyond simple producer/consumer models.
I'll also note that for both complaints 1 and 2, you think its trivial for programmers to just do the work, but I though go was all about saving programmer time?
The claim that wanting to be able to abstract over types is the same as thinking that programming is about constructing taxonomies is one of the sillier claims I've seen recently.
His claim as I understood it is that the fundamental building blocks should not be types (what something is ), but functional capabilities (what something can do ). Type abstractions are fundamentally hierarchical (from an abstraction to multiple concrete versions), whereas capabilities are fundamentally about composition (I can do A, B and C).
He essentially argues that types are constraining on other languages based on types, where it is actually in Go that types CONSTRAIN your use of things.
Because obviously different things CAN be held in a container, and a container can hold different things -- but Go doesn't let you do that (except for the officially "blessed" containers).
It is Go that's concerned more about "what something is", in letting you work with it, than, say, Haskell.
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…
Your metaphor certainly resonates with me, but there are two mixed concepts here: 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…
Actually there are several, here is one:
It was not made to replace C++, rather, it seems that it grew out of frustration of using C++ for some specific project inside of Google. That program needed 45 minutes to compile on a computer cluster!
However, Rob seems to wonder why more C++ users didn't pick up Go, but Python users did. But I believe it's more than obvious: I'm sure that he still can't use Go even as the part of the mentioned 45-minutes-on-cluster compiling C++ project. Go is a system, not something that can be linked to the existing C++ or C or Fortran project. To compare, note that C was made to be able to be linked with Fortran or assembly.
Moreover, I believe that even if he had all the time of the world for rewriting the mentioned 45-minute-on-cluster compiling C++ project in Go, his resulting program would certainly compile faster and most probably "look" nicer on the line lieve but would execute bad enough that nobody would like to switch to his variant, just for the speed and memory usage aspects.
And that's all that it's to be said about Go. Good wishes are one thing, but the execution matters. One the pure performance level, it pays out immensely to replace some project written in Python with Go, on the "what compiler does for you" level too. Python is awfully slow whenever the built-in C code inside of Python and libraries like numpy is not executed, and the errors which you can catch with compiler are much more convenient than the run-time errors. But when replacing C or C++, you simply don't get the execution-level control or memory footprint benefits with Go. "But it's easier to write, especially concurrent programs" argues Rob. Yes, you can read it for every language in existence: for people who are used to the language they talk about, when they write exactly that what they are used to write, it's the easiest language to write in. Erlang people would tell him that Erlang is easiest to write for concurrent programs. It's easy to find the scenario where any language is an optimal one.
But being better or as good as C is not an easy task. The only language which was often quoted to produce even faster code was Fortran. Not that Pascal didn't have the possibility to avoid aliasing problems inherent in C, for the given tasks, numerical computing, Fortran was for enough historical reasons more convenient than Pascal.
"The determined Real Programmer can write Fortran programs in any language." http://www.pbm.com/~lindahl/real.programmers.html For those who don't get it, it's a joke: I quote it in order to finish with: For decades, languages are marketed as the "silver bullets." Go ain't, just like most of them before. I'm old enough to know, some of the most successful aspects of Go: fast compilation, clean declarations and reduced syntax were present in the works of Niklaus Wirth: http://en.wikipedia.org/wiki/Modula-2
Wirth was obviously quite right from the start. And Object Pascal programmers know they had a lot of good sides of Go even twenty years ago. Including not being forced to have constructors.