Go is a bit more difficult to pin down, demographic-wise, but I'd say it's a mix between C minimalists and Pythonistas and other scripters who want something faster but don't want to go with a JVM-language or go all the way down to bare metal.
This target group as well as Google's pedigree is why you're reading a lot about it at web programmer's forums (like, well, this one), consisting mostly of people who wouldn't (and couldn't) touch C++ with a ten foot pole.
Perhaps more sophisticated type systems like those found in Haskell are worth the extra effort but my money is on Go for its simplicity and pragmatism.
With a bit of mathematical notation--which may be a little foreign but is not that complicated--you can fit all of Haskell's type inference rules on a single page. These rules specify how the type system behaves and how to infer types! (The type inference, which may seem magical, is just a constraint satisfaction problem and so is easy to specify.)
I would not be surprised if Go's typing rules are more complex than Haskell's. All while giving you less static guarantees and less thorough type inference.
Haskell's type system may in fact have fewer moving parts, but it has a LOT more emergent complexity than Go's does.
I think it also appeals to those who first started out programming in Basic but quickly proceeded to Pascal and loved it. At least, that's it in my case. Pascal is the one I'd describe Go as being closest to -- but then I've never been a C programmer.
As for Pythonists and scripters, not sure they'd ever be that happy in Go. A lot of their conveniences are "gone" in their experience. Such as custom yield iterators.
And before someone answers me with the lack of manual memory management, Native Oberon and Blue Bottle are done in fully GC enabled languages with a little assembly for the boot loader and interrupt controller bindings.
If it were a good C replacement, it would have dynamically linkable libraries so that I could write an extensible server that could be extended with external modules (a la Apache).
If it were a good C replacement I'd have direct access to memory so that I could write device drivers.
C ABI is the operating system ABI. If the OS is written in Go, the C ABI becomes irrelevant.
> If it were a good C replacement, it would have dynamically linkable libraries so that I could write an extensible server that could be extended with external modules (a la Apache).
You can do this with gccgo to some extent already. Eventually this support might come to the standard compiler.
This is not a language issue, rather an implementation issue. As anyone with compiler development knowledge can easily explain to you.
> If it were a good C replacement I'd have direct access to memory so that I could write device drivers.
The Oberon guys did not had any issue with this. Their System package API is quite similar to what Go's unsafe package offers.
http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd...
http://e-collection.library.ethz.ch/eserv/eth:26082/eth-2608...
In my experience the domains in which C is the most appropriate choice does not work well with GC's, and even overhead like that coming from automatic boundary checking is an unwelcome performance impact.
What exactly are the areas of C use in which you expect Go to replace it?
Because we should move away from languages that are designed for security exploits.
> In my experience the domains in which C is the most appropriate choice does not work well with GC's, and even overhead like that coming from automatic boundary checking is an unwelcome performance impact.
I hear the complaint about automatic boundary checking since the early Pascal days. Yet most compilers, even Go, provide a compiler switch to disable bound checking.
Lets not forget how many security exploits we have to thank C for exactly this mis-feature.
Modula-3, Oberon, Active Oberon are three examples of GC enabled languages with given proofs that is possible to write operating systems in GC enabled languages with zero C code.
The Native Oberon and Blue Bottle operating systems were even used for several years as desktop systems at ETHZ.
> What exactly are the areas of C use in which you expect Go to replace it?
Well, actually it does not have to be Go. Rust and D are also good candidates.
The only area where I concede it is hard to replace C is in embedded space, specially if we consider many developers are still using Assembly.
As for the areas where human life is at risk we are better off with Ada, Spark or ATS. In these cases I surely wouldn't want a GC issue to cause deaths.
Are you seriously claiming that C was designed for security exploits?
>Lets not forget how many security exploits we have to thank C for exactly this mis-feature.
No actually we have to thank sloppy and/or naive programmers. The C language is clear in that it doesn't hold your hand.
>The Native Oberon and Blue Bottle operating systems were even used for several years as desktop systems at ETHZ.
You can write an operating system in lots of languages besides C (and it has been done aswell), yet all the operating systems/kernels in wide use these days are all mainly written in C or a combination of C/C++.
That you can write an operating system in language X is nothing new, the performance you get with language X however is. We've seem numerous 'safe language' operating system attempts which have died due to inactivity or as in Singularity's case been passed off to academia because MIcrosoft realised it had no commercial relevance.
>The only area where I concede it is hard to replace C is in embedded space, specially if we consider many developers are still using Assembly.
I disagree, in everything where performance and/or footprint is paramount there will be a need for languages such as C, as always there is room for competition but Go certainly isn't a candidate in my opinion. I haven't really looked into Rust yet, D on the other hand seems to have gained zero traction and is from what I gather primarily positioning itself against C++.
> No actually we have to thank sloppy and/or naive programmers. The C language is clear in that it doesn't hold your hand.
While it is true that security exploits come from sloppy, naive, hasty developers, we should also remember that even the programmers of projects such as OpenBSD are not immune to C's pitfalls. This is why I think that it's so interesting when languages try to achieve what C does, while also making it more likely that a programmer who's tired or distracted can't actually get incorrect code to compile. Besides the usual D, Go and Rust that are mentioned, I should say that the language Clay is another very interesting project and it's a shame that it does not get the amount of publicity these other alternatives get.
> You can write an operating system in lots of languages besides C (and it has been done aswell), yet all the operating systems/kernels in wide use these days are all mainly written in C or a combination of C/C++.
I don't know that it's really because of some functionality proper to C; I feel it's more of a familiarity issue. People have been implementing operating systems in C since the early 70's, there is a lot of documentation on the subject and C is widely known.
Performance which translates to low latency is of great importance in a operating system/kernel.
This extremely low latency is the result of optimizing at a very minute level, C allows this to be done while retaining a high level of portability and maintainability as opposed to assembly.
The extent to which this optimization is done is further highlighted by how the Linux kernel (and I assume other aswell) uses compiler extensions to further control the final generated code in order to maximize performance and minimize footprint. As such these compiler extensions allow for even further low level control which are outside that which the standard C language provides.
Kernel's and similar operating system components operate in a very low level problem domain, and C is a high level language which has shown itself particularly suitable in this context.
So I think that the wide use of C in low level and/or performance critical code such as that of kernels is based upon 'practicality' rather than 'familiarity'.
Even so, expert C programmers successfully writes all sorts of code.
Git for example doesn't strike me as a project with a larger amount of exploits or bugs than other similar software. And while lots of people have different views on it's 'ease-of-use', everyone seems to agree that Git is 'damn fast'.
As proven by Ken Thompson himself, with his compiler trick.
Joking aside, C requires expert programmers, which sadly seldom exist in the real world.
The only way to minimize the security exploits made possible by lack of bounds checking, arrays decaying into pointers, null terminated string without null characters, use after free(), sizeof operator incorrectly applied, ... Is to use languages that disalow these operations by default, only allowing them via a system/unsafe mechanism explicitly enabled by the developer.
C can be a good tool in the hands of experts that never do mistakes and are the Jedi masters of perfect coding. Sadly most companies tend to have average developers, not Jedi masters.
As such, C with its motto 'speed before security', makes almost impossible to write bug free code in the hands of such developers.
So there is no exploit-free C code out there? It is just impossible to write C code without buffer overflow bugs?
>Tools that fail in human hands, shouldn't be. If so why don't we throw out all programming languages? You can create buggy code with far-reaching implications in any sufficiently complex programming language, buffer overruns are but one type of bug.
And relating back to 'tools', we have lots of great tools at our disposal these days which can be automated to help identify possible vulnerabilities in our code. There really isn't a 'either you use a safe language or your code will by definition contain exploits' situation which some people try to paint.
C helps selling memory leaks tools, pointer misuse tracking tools and lint.
One was to thank the language deficiencies for the market opportunities they create.
The point of Go isn't that it replace existing C programs, it is that Go appeals to C programmers who want to extend their rrach, it is that is reshapes C to fit in areas it didn't fit before (and, yes, to not fit in areas it fit before), without being as radically different as Java or Python or Haskell.
Vitess, for YouTube, was announced on Feb 28th.
I also disagree with the idea that this is "marketing". Google have made (and are continuing to make) Go as a replacement for the languages they currently use. They're scratching their own itch.
Finally, I disagree that this is a major differentiator between Go and D. Neither of them push marketing, relying on the enthusiasm of their community to spread the language. They are completely different designs and have very different goals (as noted by others). I do not think that Go will win because of Google's ability to market it.
Neither did I said that this was a 'major' differentiator between Go and D. Just 'a' differentiator and not a major one at that.
I have become slightly myopic with regard to the little announcements. I'm confusing it with announcements like Bitly's: http://word.bitly.com/post/29550171827/go-go-gadget or Cloudflare's: http://blog.cloudflare.com/cacheing-the-uncacheable-cloudfla.... But the point still stands, I see more of these posts related to Go than posts related to D (or Clojure/Scala/Rust/...).
But yes, it's kinda marketing because I love Go (which is why I joined the Go team), and I wanted to spread my happiness and want to see other people use Go.
But the Official Google Marketing Department was not involved. We don't have any fancy videos like Chrome. Just me emailing.
> We don't have any fancy videos like Chrome. Just me emailing.
Yes, it's more the opposite: they were constantly requested for proof of their dogfooding and they always replied that they can't due to "confidentiality reasons".
Still I wish all the best to Go team, as we really need to go away from VM languages and some day replace C and C++, be it in the form of Rust, D or Go.
The creator just started a Kickstarter campaign for a D conference: http://www.kickstarter.com/projects/2083649206/the-d-program...
It's doing well.
Or maybe gasp Go is just really good ;)
I'll try again with something I don't intend to turn into a business. Writing various daemons, tools and helpers in Go has been great, though.
Well, it covers:
Serving (great built-in server for net/http)
Routing
Sessions
Context
--
It's missing:
Authorisation
Authentication
Parameter Validation/Checking
Asset management
Migrations
Cleaner templating (I prefer mustache to the built-in go templates)
HTML Helpers/View Helpers
Form Helpers
ORM or other persistence helpers (controversial I know)
Possibly scaffolding would be nice too and a suggested project structure to encourage sharing
--
So there are a few things which you'd generally expect in a web framework which aren't there yet. Of course some of the above list is subject to debate, some is available in revel, some it not everyone would agree is even necessary, but most other platforms in other languages have a bit more to help you, even if they are minimalist. Even just having an agreed-upon set of conventions and structure for web projects (a la rails), speeds up comprehension when looking at any large code-base.
I'm quite confident Go will get there, and having tried it out am really impressed with the language and the culture, but it would be disingenuous to suggest it has everything you'd need to produce large web apps currently - at present you have to write your own code for quite a lot of the above.
By the time you get to crud admin and plugins, you're at the point where the benefits of the framework start to come with significant additional costs (in maintenance, flexibility, comprehension etc). A pre-built app or plugin gets you up and running quickly but when you start to modify it you really need to understand the entire app/plugin before you can do so efficiently. Often people feel this is as significant a roadblock as simply writing it from scratch in the first place.
Any complex webapp is probably going to outgrow standard admin/scaffolding, and any complex usage is going to require modifications of things like plugins and gems, so while they're nice to have in an ecosystem I don't see them as essential. This is an area where django has more built-in that say rails though, and it'd be interesting to see a Golang framework trying to take the best ideas from all these other popular frameworks.
I would agree if the components were tightly coupled, but Django is very well structured to let you substitute any component. At any rate, it's much better than writing everything yourself outright, and I'm speaking as someone who has launched more than 10 Django-based products.
That said, I really want to try out Go...
Out of curiosity, why do you prefer Mustache to Go templates? They seem extremely similar, with Go templates being slightly more powerful due to easy-to-add template funcs. Both are essentially data-driven though.
Re Mustache versus go templates, I preferred the restrictions and clarity of mustache, because it forces you not to put any code in the view, all you can have are the basic constructs it provides, but it doesn't miss anything major IMHO. Here are the things I needed, which it provides:
* loops
* partials (with the neat {{> partial}} syntax
* nested contexts
* escaping by default
* clear named keys, no '.' prefix, though I guess . would be OK between keys for subkeys (not possible in mustache as yet)
* limited contexts (so that it's obvious what is being called)
The differences are not major, and frankly either is a fine choice, but I actually preferred the limited syntax of mustache, and found the go template setup needlessly complex, in particular when including partials, I didn't spend too long on the decision though so perhaps I just misunderstood...
So add me to the list of people who'd like to see something comparable on Go.