> Why rewrite in Go? It all started back in April of this year, when I was running "apt-get update" at home and noticed that downloads from dl.google.com were stalling for no apparent reason. I asked about this on our internal Google+ and was put in touch with the right people. It turned out that the existing C++ dl.google.com service was no longer actively maintained (short of being kept alive) and that it relied on some assumptions about Google's internal architecture which were no longer true.
This doesn't instill confidence in Go. That it is a success story with abandoned projects is not what we need to hear; we need to hear that Google+ runs on Go. Or at least something the size of Google Reader. When a startup is evaluating what language to build their stack on, dl.google.com is not what they're aiming for.
Apparently an unmaintained C++ app using deprecated libraries and making false assumptions about Google's internal architecture was able to handle it too, albeit with poor performance. So I disagree that this move says anything about Go's capabilities, positive or negative.
I'm inclined to agree that by itself, this doesn't say much about Go at all.
That said, I'm not sure how much a non-open-source program can really do in terms of marketing Go or any other language. This isn't so much politics as logistics: you need to be able to see the difference in code to get a sense of the advantages or disadvantages of one language over another, and if the program isn't open-source you can't do that. The author can say it's "more readable" (and does, in fact), but that's not something that can be quantified, and so there's really nothing but one guy's opinion to go on.
Yeah, but the top-layer app is where the author's statements would bear out: that's the code directly comparable to the old C++ code that it replaced. It's not really practical to give examples of that when you can't open-source the app; you could maybe do a few trivial snippets or put it all behind a big thick NDA, but neither method works very well.
At least it says that Go works for replacing legacy apps that are using deprecated libraries and making false assumptions. There are tons upon tons of such programs in the world.
It doesn't necessarily hold. You can write a system which handles huge volumes of traffic simply by scaling horizontally with N servers. For some languages N is just a lot larger. Unless your startup has unlimited hardware resources like Google you can't make that assumption.
Wait, so your opposition to Go was that it was cost effective and powerful enough to merit investing engineering time to replace a broken legacy system that couldn't justify the expense of C++ maintenance?
My "opposition" (not the right word) to Go is that the company which created it doesn't use it on anything that is serious enough to cause a "shit hits the fan" moment were it to fail. Other than it works badly on Windows, I don't have any reason to think Go is inadequate, but if Google hasn't bought in yet, why should I.
Not quite.. it seems the Go app is just a webapp run on the origin server(s) that their CDN pulls from. Chrome installs/upgrades would only fail once whatever caches expire.
Yes but the CDN itself is not Go, correct? That's kinda the point here, that nothing all that critical or core to the processes themselves are implemented in Go, even if the service as a whole functioning entity are important.
They want to know Go can be trusted to do the heavy-lifting most people would use C++ or Java for. So far, nothing that Google has publicized about how they use Go has indicated that their concerns are invalid.
How are you distinguishing between what's "critical or core to the processes themselves" and what's not? What makes taking bytes from a disk or memory cache and pushing them over a socket somehow more "critical" than getting the client to the right server in the first place? Neither one is useful without the other: it's a cohesive whole that now works much better since dl.google.com was rewritten in Go.
I'm genuinely interested in this particular objection. I've written several components of a multi-component system (itself just one major piece of what makes our CDN work), and it never once occurred to me to say that one component was more or less "critical" than another. In this system I've written 12kloc servers with intricately managed resources where cachlines matter, and I've written 1kloc servers that just repeatedly make internal RPCs and occasionally tweak the behavior of the system. I've seen the system's behavior when each of these components fail, and both sorts of failures cause major problems. Is one more critical than the other? I'm going to get paged and users are going to suffer whichever one fails.
You don't understand the objection precisely because you work at Google. :)
The reason that people are objecting is because serving up files is not exciting or innovative and doesn't show any particular 'win' for a language -- I could write the same thing in Haskell, for example. The details about how it's serving up the files from your Googley FS are irrelevant to the non-Google employee. :)
I.e. I can run nginx on any machine with a decent CPU and saturate a 10Gbps link serving static objects.
If you were to say that the gigantic global network of awesomeness that is Google CDN runs on Go, the average non-Google employee starts to care because that's something that you can't just do with some off the shelf OSS software. Then we can start taking Go seriously for mission critical use.
That's the though process, anyway. If you don't agree with it, that's perfectly fine. :)
Burden of proof is on Google to show that they are using it seriously which, to me, means an external user-facing application that has importance to Google the company's bottom line. If they aren't taking the same risks that a startup that decides to build with Go is going to be taking, it says a lot about Google the organization.
Internal projects are not something that I can judge the importance of, so pointing out that they use Go in internal projects is asking me to take their word that they are taking Go seriously, but all I'm saying is "show me". Show me on a project I've heard of. We know they have faith in C++, Java, and to a lesser extent, Python.
> Internal projects are not something that I can judge the importance of, so pointing out that they use Go in internal projects is asking me to take their word that they are taking Go seriously, but all I'm saying is "show me". Show me on a project I've heard of.
I assume you have heard of YouTube. From the first paragraph in the email:
> YouTube’s open source vitess project (http://code.google.com/p/vitess/) is one high-profile success story...
I've been following Go rather closely lately and I noticed that these little announcements come regularly.
This is clever marketing (mind share!) and one of the reasons why Go is going to win out over D et al. When was the last time you read something about D? (Perhaps I frequent the wrong watering holes.)
I'd say we've got two different upgrade paths here. D is aimed squarely at the C++ crowd, so the biggest enemy it has right now is that C++11 is actually half-way decent.
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.
My interest in Go has a lot to do with static typing. Dynamic languages are great for brewing things up quickly but static typing is just far too useful for catching dumb bugs early and for enabling powerful tooling.
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.
Haskell's type system may be sophisticated, but it's also very simple. There's no sub-typing of any sort, for example.
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 has algebraic datatypes and typeclasses. Both of those are more complex than Go's type system, which is more or less just primitives, structs, and interfaces.
Haskell's type system may in fact have fewer moving parts, but it has a LOT more emergent complexity than Go's does.
I do it mostly for networking programs using Jane st a sync. Raw performance is great, on the language shootout it is on par with Go and getting better. For me it has replaced almost every language I would use except for the situations I need C.
> 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.
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.
I keep arguing against the missing support for generics in Go, but on the other hand I see it as a nice C replacement.
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 I'd be able to expose an ABI for other language bindings, so that I could write libraries that could be used in many different languages. There is no way to do this in Go.
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.
> If it were a good C replacement I'd be able to expose an ABI for other language bindings, so that I could write libraries that could be used in many different languages. There is no way to do this in Go.
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.
I don't understand why you continously want to pitch Go as a C replacement.
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?
> I don't understand why you continously want to pitch Go as a C replacement.
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.
>Because we should move away from languages that are designed for security exploits.
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++.
>> 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.
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.
>I don't know that it's really because of some functionality proper to C
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'.
> Are you seriously claiming that C was designed for security exploits?
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.
C requires a level of unassisted perfection that we spent forty years demonstrating nobody can attain. Every programmer is sloppy and naive in comparison. Tools that fail in human hands, shouldn't be.
>C requires a level of unassisted perfection that we spent forty years demonstrating nobody can attain.
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.
It is genuinely difficult to find C code of any real complexity that hasn't had some kind of security flaw that would have been unlikely in a higher-level language. Even qmail managed to cough up an LP64 integer overflow. It took a long time for it to turn up. Generally, C code without at least one documented flaw makes me more worried than code with a known, fixed flaw.
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.
That's a pretty broad brush and in my case, completely untrue. Go has a lot more than static typing, particularly nice concurrency support and solid libraries even for things like image handling (no need to build PIL).
I haven't noticed these "little announcements" coming "regularly". Which have you noticed?
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.
I do believe marketing has something to do with it. I don't believe a random Google employee is allowed to disclose stuff about their infra permission is granted. This is not a bad thing mind you. Google is merely trying to win minds in the most friendly way possible.
Neither did I said that this was a 'major' differentiator between Go and D. Just 'a' differentiator and not a major one at that.
There's less bureaucracy than you imagine. I asked a couple coworkers from the Go and Downloads team, "hey, should I post about this?" and they were like, "yeah, go for it."
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.
> I also disagree with the idea that this is "marketing".
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".
I personally prefer Go over D, because it seems that D has almost the same complexity as C++ (and I'm in the simplicity camp). It's not a coincidence, since C++ people like Alexandescu are on board of D and C people like Thompson and Pike on board of Go. It's a philosophical / world view thing.
This is why I moved from Go to D, as I am more the C++ type of developer.
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.
I had a chance to hear one of the contributors to Golang give a talk about the state of the language at Google. It sounds like the team has actively shifted (for the time being) from developing the language to building things with the language. They want to get as much real-world experience as possible, to better direct the future of the language. Most of those projects are internal to Google and can't be disclosed, but the occasional project can. I don't see it as marketing, it's more of a natural byproduct of having the Go team building things with Go (right now) rather than building Go. It's an interesting strategy.
It certainly indicates that Go is the language you should probably be using on AppEngine, given that you pay for resource (CPU, memory, etc) usage, and Google themselves are optimising Go to minimise that same usage for their own systems.
I tried that just today, but the most (only?) decent web framework for Go, Revel, doesn't work on GAE yet. Also, as I was looking, it became painfully obvious that I would be missing the entire Django ecosystem if I went with Go.
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.
Maybe in some time more people who want a large web framework will be using Go, but right now the reason you don't see traction in that area is because there isn't a desire. I think if you squint your eyes while using the standard library's http templating and http libraries along with some popular libs like Gorilla's sessions and cookies, you'll swear you're using a framework. Of course, this isn't going to give you the same re-usability you get from a framework that's as compartmental as Django.
That's the impression I got from the IRC channel too. The equivalent of a microframework is definitely in the standard library, but big frameworks like Django just save you so much time...
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.
I do think this is both a strength and a weakness. Admin interfaces and plugins/apps are great to get you up and running fast (this is similar to the scaffolding point above), but they are also the part of any ecosystem which introduces subtle bugs and dependencies.
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 disagree with that, they made the Django admin interface really easy to extend, and entirely pluggable. If you don't like any part of Django, you can roll your own, while using the Django-provided functionality until yours is ready.
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.
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.
Would love to contribute but unfortunately have just been tinkering with Go; not using it for paid work, and therefore don't have much time for it. I like the look of revel though, and will be spending more time looking at it.
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...
Django's admin is brilliant if it fits your use case. I've solved so many customer problems just using the admin, it's silly. It's what's kept me on Django and off all the microframeworks du jour.
So add me to the list of people who'd like to see something comparable on Go.
I think it's more a question of Go fitting a need. It has a decent speed, not too much boilerplate, and built-in support for concurrency. Makes it a good fit for Python folks.
Languages such as Go would interest me more if they were not controlled by one company. I've had bad experiences with corporate languages in the past. This is one reason I'll stick with C++. It has an ISO standard and many different compilers from different companies. I feel more in control and less likely to be shafted by Google, Oracle, Microsoft or whoever owns the language de jour.
From replies to the parent:
> a) Go is open source
> By your argument, C++ is controlled by Bell Labs.
> The C# specification has an ECMA and ISO standard
Oh come on, you know 16s was talking about implementations and tendencies of the parent company to engage in malevolent lawsuits trying to shut down alternatives.
Wherein an open source language, mostly developed by Company X, dies out because they stop developing it and the contributors remaining are not as good / interested. Let's not kid ourselves, open source is not magical fairy dust that does work for you. It works based on a set of personal incentives in alignment with the public good, and so sometimes it doesn't.
Same with ISO standards. They don't specify goodness. The Mono replacement for C# is finally getting there, but a few years ago, if the MS C# implementation had died off, would I replace it with Mono? God no.
Why does everyone pretend GCCGO doesn't exist in these conversations? An alternative implementation already exists, and has existed since very early on. If nothing else, it demonstrates that re-implementation is a feasible option, should that ever become necessary. (I don't see why it should, since the official is BSD licensed.)
What does that have to do with anything? Who cares what google does or doesn't do? That is rather the point of this particular thread of discussion, in case you missed.
> We've understood from the initial launch that Go needed to be more than just Google's language. The front page of golang.org has never mentioned Google and carries none of the Google logo or branding, and that is not accidental.
Go and the go std lib are licensed under a bsd license, which is a more liberal license than java and the jdk and would avoid things like the oracle lawsuit against android.
So yes, just because it's open source doesn't mean much, but it's open source with a very liberal license, which does mean something.
Originally, the Oracle lawsuit had some patent claims in it, IIRC. They were thrown out though. I can't recall if they were thrown out by the judge or if Google spent the time/money/lawyers to get them invalidated.
IANAL, I don't think that's true for the Apache license, because it includes a clause that explicitly reassigns patents (or at least licenses any relevant patents).
Java is open source by the completely literal meaning of this word, but it is not in the spirit of open source, i.e. it is not free software (as was recently demonstrated by Oracle's lawsuit).
In case you're forgetting history, Java only went open source very recently (2007, only really usable in 2008)[0]. For much of its life, it has been a closed source language / runtime.
Nothing against Java, now, but it's not a fair comparison to Go. (Disclosure: I was an early Go contributor but no longer use it for day to day work. I have no affiliation with Google.)
Another example (it's ignored far too often) is F#.
From Microsoft, open source under the Apache License for all I know. And it's one of the 3 big, supported, here to stay .Net languages, comes with full VS support etc..
Knowing the languages only by reputation, you could try D which is more community oriented. I kind of wish it had a backer like Google, because I like it's name better and I heard of it before Go :-) I also hate implicit semi-colons. If you don't want them, then don't have them at all, like python.
I dont know where you come from, language-wise, but do you think one can make a nice transition if they are used to Ruby and JS? I want to experiment building a simple web server and thought maybe I should use Go.
Specifically, what was it that convinced you that Go is "fun to write in"? Thats mostly what I care about too.
If you're coming from Ruby, you'll feel right at home, perhaps less so if you're coming from JS. What I found surprising and fun about Go is just how similar it is to scripting languages in style, and how much baggage it drops from C (header files, explicit types, pointer arithmetic etc).
The lack of header files, clear and simple syntax, minimal language core, and predictable standard library all combine to make it feel very like a compiled Ruby, though obviously there are differences. The main differences coming from a dynamic background are the type system, interfaces, imports and packages (no circular imports), and the lack of dynamic loading - everything is loaded at compile time. Interfaces feel a little like duck typing with checks on whether a type really does quack like a duck at compile time!
If you mean writing a web app, it's not really as mature as other ecosystems in terms of support for this, but would be great for a smaller, minimal web-app, if you mean writing a web server from scratch, go is a great place to start, and even has a good example for you to look at in the built-in server:
Yes, I come from Ruby & JS world and before that I use to work with VB.net. I had not problems picking up Go. The hardest part of Go to understand was the implementation of interfaces.
Best thing I like about Go is the error handling, its great for defensive programming (which help as I write a lot of service applications).
As a sidenote is there any way of viewing google group posts without logging into google? I'm at work at the moment and my google account keeps on getting logged out as cookies are deleted frequently.
This comes up every time someone links to Google. If you have any Google cookies it will make you log in. Open it up in an incognito window or something if you don't want to.
Out of the blue 1-2 days ago, a DTD hosted on dl.google.com (http://dl.google.com/gwt/DTD/xhtml.ent) started semi-randomly timing out and hanging Eclipse.
(This was due to the Eclipse UI asking "Is this your XML file?" for every XML file in the project, for every plugin, and one of the plugins, IvyDE, ended up not having fetch-eternal-dtds turned off. What a silly default.)
as another example of stuff in go, there is a window-manager called "wingo" that is still pretty alpha, but kinda-sorta-works https://github.com/BurntSushi/wingo
Hey man, I've been running it for at least week for day-to-day work and it hasn't crashed yet. :-)
I'm quite pleased that most of the bugs reported so far are related to state transition bugs, which is the part of Wingo I'm least happy with.
And this includes using completely untested libraries that implement the entire X client stack (from the wire to the screen) in pure Go. Which amounts to roughly 31,000 lines of code.
N.B. I blame Go (mostly) for this state of affairs.
I would think so. It has many of the properties you would like in implementing a database system. First, the language is statically typed and executes surprisingly quickly. Second, it can handle high concurrency which is needed in a database since you will have many clients connection. Third, the libraries letting you interface with protobufs and HTTP provides two pretty simple ways to connect your Database interface to the rest of the world.
The perhaps most glaring problem, compared to the world of Erlang where I come from, is the lack of built-in seamless distribution. Many NoSQL databases trades consistency for availability and more machines. You are on your own implementing this.
Also, the lack of a ZooKeeper-like library may be something you will end up implementing. That, or perhaps the basis of the Dynamo paper.
> I would think so. It has many of the properties you would like in implementing a database system. First, the language is statically typed and executes surprisingly quickly. Second, it can handle high concurrency which is needed in a database since you will have many clients connection. Third, the libraries letting you interface with protobufs and HTTP provides two pretty simple ways to connect your Database interface to the rest of the world.
But that is not unique to Go, it may as well apply to Java, Scala, etc...
<rant>
this is weird, i had posted the same story approx 7 hours ago, which received 2 votes, now the same story, 5 hours later is on the front-page http://news.ycombinator.com/item?id=4700943
"Uh oh, another story about success in Go, better post some FUD!" Nobody's yet come in to say how using Go on a 10-year-obsolete computer (32-bit PC) may have problems with garbage collection, pretty unusual for a Go post.
This doesn't instill confidence in Go. That it is a success story with abandoned projects is not what we need to hear; we need to hear that Google+ runs on Go. Or at least something the size of Google Reader. When a startup is evaluating what language to build their stack on, dl.google.com is not what they're aiming for.