Creator of SASS and Haml now using Go for whole production system.
When asked about surprising things about Go, its creators have said that they expected to recruit people from c++ communities, instead it seems to be more ruby/python people.
When asked about surprising things about Go, its creators have said that they expected to recruit people from c++ communities, instead it seems to be more ruby/python people.
And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started to see some of its warts. The transition from version 2 -> 3 wasn't exactly a smooth one, either. Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in.
In my case, although I have recently moved from Perl to Racket for larger and/or more complex work, I still use Perl a lot for small, simple scripts (which constitute most of my programming). A couple of the Java guys I know switched from Python to Clojure for scripting tasks (I could never convince them to like Perl..), and have started to take an interest in languages like Scala and now Go for more substantial projects.
For many years now, Python has been the fresh, fun challenger going up against older (and perhaps clunkier) languages, whereas now things seem to be shifting and Python may soon find its role has reversed and it has become the old, crufty language.
I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally, I'm completely fine with that; different language designs are appropriate for different roles. The huge amount of work that we've done to make non-allocating and manually-memory-managed code easy, predictable, and type-safe is totally overkill for Go's niche, for example, while for games and web browsers this sort of thing is essential.
I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis.
For the love of god make Rust more accessible. I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the frickin' documentation. Digging through the core libs to figure out how to dp fairly common case stuff is obscene.
Part of the reason I like to tinker with Go in my spare time is that it's extremely hygienic, clean, cheap, and cheerful.
Look at the way the "go" binary works, it does everything. It does builds, automatic formatting of code, the works. And it just "works".
On top of that, I'd consider getting somebody more knowledgeable about Rust and get them to team up / pair-document with somebody who is a goddamn dumbass like me and start building tutorials/documentation together.
I can't imagine the language's syntax and features are so nascent that tutorials and docs for core functionality/libs would be out of the question, you're already prototyping that web browser engine.
Documentation is a UX problem, like syntax. Syntax alone crippled Erlang, please don't let obscurity harm a language I am very excited about.
If there's any way I can help (maybe a trail of bread crumbs/notes from me as I try to learn it?), let me know in this thread or via email.
And Patrick(reminding), People are asking for a good beginer's tutorial...
I agree, Rust's documentation is really awful at the moment. I mean, there's a reason for it: the syntax and semantics are evolving so fast that any tutorial written right now will be hopelessly out of date in two weeks (note that the official tutorial has been updated regularly, but you can't even tell!), and much of the current stdlib is comprised of quick hacks based on obsolete language features and may very well get near-entirely rewritten before 1.0. Of course, that's no consolation for people who don't consistently lurk in the dev channels.
There's some hope, though. The next release (0.4, due in perhaps a month) has been tentatively designated as the "syntax freeze" release, so at the very least things should cool down after that point (fingers crossed). But until then, I wouldn't advise newcomers to get anywhere near Rust, for fear of the constant breaking changes that are leading up to the syntax freeze.
Edit: Fuck it, I'll make a website.
A "go"-like binary is on the roadmap; it's mostly a question of refactoring. We have a pretty printer, a doc generator, a package manager, and a compiler (all in various stages of completeness); the trick is to just bundle them into one nice package.
A trail of notes would definitely be helpful, to see what the initial hurdles are for beginners.
From what I've seen the biggest problem is that 0.3's syntax is totally different from the unreleased 0.4 (due to be released next week). Most people, understandably, build from the packaged 0.3 and none of the examples in the documentation work. 0.4 contains the syntax we're committing to; most of the changes from then on should be backwards-compatible with it (unless you use the deprecated stuff, which we're adding warnings for).
I will be eagerly looking forward to that!! Is the 0.4 version a step ahead of the past alphas? Is it finally becomming a beta?
With C++11 it now has a foot in the concurrency niche. The question is, whether C++ can keep its niches or if lots of different languages will chew away its market share on various levels.
Well, it does excel in scientific computing. Biologists, astronomers and such use it a lot, and it has lots of advanced math/stats/physics etc libs, with fast C implementations underneath.
links: http://en.wikipedia.org/wiki/BioPerl | http://pdl.perl.org/
Other languages evolved through a different path. Chemistry, for example, tends to be more Python related. (I develop software for that field.) I think it's because the chemical graph data structure is harder to write naturally in Perl. Gene expression analysis uses a lot of R.
I'm a geneticist whose (work) code is centered around data processing. I previously used Perl for just about everything (although I've used Python & Ruby also), but started to broaden my programming horizons recently, and after a grand tour of what was on offer I settled on Racket as my language of choice for the more complex end of the scripts I was writing. I'm finding it easier to maintain (and especially refactor) complex scripts in Racket than I did in Perl (or Python or Ruby), and the increase in performance is substantial when processing huge data-sets. One current weakness of Racket here is the relative lack of specific libraries for bioinformatics, but most of my code doesn't need any anyway and when it does I revert to Perl.
I'm also excited about investigating other areas of the language, especially Typed Racket, as static typing is something I haven't really utilized so far.
In general, the more I learn about Racket the more I admire the quality of design that has gone into it; everything seems to be extremely well thought out, not just from a theoretical perspective, but from a practical one too.
And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that were willing to take a risk on Python or Ruby are now into Go. It offers a lot of the expressiveness of either of the former with much better performance, concurrency as a fundamental, and the extra safety of static type checking.
Python and Ruby programmers come to Go because they don't
have to surrender much expressiveness, but gain
performance and get to play with concurrency.
C++ programmers don't come to Go because they have fought
hard to gain exquisite control of their programming
domain, and don't want to surrender any of it. To them,
software isn't just about getting the job done, it's
about doing it a certain way.
The issue, then, is that Go's success would contradict
their world view.
And we should have realized that from the beginning.
People who are excited about C++11's new features are not
going to care about a language that has so much less.
Even if, in the end, it offers so much more.I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.
Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
Casting every list element to "interface{}" is not generic.
Really, maybe we should remove container/* completely, so we don't have to answer this stuff over and over again.
If you need a typesafe, generic sorted set with strict efficiency needs (or things like precise control over memory layout and such) then by all means go for C++, it's been designed for that kind of constraints.
When people ask for things like this, I can't help to think that what they want is not generic at all, they want something very specific to the problem they are solving, in those cases just writing custom data structures is the way to go in any language anyway.
It is the way it has been done in C for decades too.
What's your definition of generic programming BTW? I'm looking at several definition right now and cannot find out if, for example, a generic list container in C using void pointers to data would be considered generic programming.
Wikipedia states generic programming is "a computer programming paradigm based on method/functions or classes defined irrespective of the concrete data types used upon instantiation". That reads like "templates" to me.
Templates are generic, but so is, e.g. the type inference used in functional languages.
From all accounts it will never ever get generics.
> and C++ is better for performance.
As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++.
But the big question is, is it really that much slower?
And the fact that it is a GC language means it is a much simpler language than C++.
Actually C malloc, free, C++ new, etc. are really slow functions. Garbage collected languages can typically 'allocate' memory with little more than top of heap pointer increment.
You can implement similar memory pools with C/C++, but it's hard to get right when large allocations are made, compacting is very hard, etc. It does work for limited applications, for example ones that have a lot of short-lived small objects.
Multi-threaded garbage collected languages also don't need locking for freeing objects. With manual memory management you might need to lock the parent object before freeing the child to prevent some other thread from loading a pointer to the free'd child object. Locks are slow, even atomic primitives require slow inter-CPU communication. Garbage collection can avoid that completely. Performance win for gc can be hundreds of percents with 16+ CPUs.
So, there's a pretty good shibboleth/knowledge smell you can use to detect whether somebody's done systems programming and knows what they're talking about or not.
Whether they think relying completely on the heap is a "small" cost or not.
Try writing some code in a real-time constrained environment where non-determinism is unacceptable. See how far malloc and Boehm gets you.
There are certainly lots of abstractions you can express in Golang.
And you can't use go outside of the "PC" (that is, embedded systems).
Why not? It runs on Arm.
But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)
Sure, there are some places that can't use Go. But there are also places that cant use dynamically allocated memory or recursion. Not all embedded systems are safety critical or need to be absolutely deterministic.
Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance.
And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't.
Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.
Wouldn't learning a new language expand your toolset? Not replace it.
And I think most here agree that Go and C++ are solving different problem spaces. So knowing both would be a win.
I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like functionality. I am sure if I really wanted green threads I could find an implementation that was similar to goroutines. Basically when I get excited about new programming languages it is about languages different enough from C++ that they actually have a shot at being better, Clojure, Scala, and Haskell come to mind.
A language that doesn't affect the way you think about programming, is not worth knowing.
Edit: I am fully aware that I may be blind. I do plan on exploring Go at some point, but exploring other more exotic languages take priority for me.
The Go team's idea was, look at languages like C++ and replace groups of individual features with orthogonal components that can be composed to similar effect.
Pike is a little dismissive of C++, as am I, but ultimately he acknowledges the truth of the matter: if you're dead set on writing programs using template generics and inheritance hierarchies, you're going to stick with C++. And that's OK. We don't need to argue about it.
I am very new to Go, have a background in C/C++, am Ruby today, and was Python from '02-'05. My take is that there are definitely still things I would write in C, and I would still write web frontend code in Ruby. But I see a place for Go (backend network code, network clients, things like that) and I personally see no place at all for C++ (but then, the C++ people might not see any place at all for C). Go doesn't have to be all things to all people.
Application programming in the scale of Photoshop, Word, etc. Video games. All kinds of multimedia apps and video/music editing apps.
C is too low level for those kinds of things, and Go too high level.
Plus it's not just the language, that's a mistake: it's the whole ecosystem that matters.
E.g you're gonna find more experienced C++ programmers to make you the next, say, Call of Duty or Logic Pro 9, than you're gonna find Go programmers. And far more code and libs to leverage.
And, I'll restate: from the 1000-or-so lines of Go I've written so far, I'm pretty clear that I wouldn't want to use it for frontend web stuff (anything with serverside templates). But I'd probably use it before I would use Node.js for a backend web service, or maybe even for a single-page app.
Outside of the lack of bindings to proper UI frameworks, I couldn't say why you shouldn't write e.g. Word in a higher level language than C++. You might have to be careful with memory usage in some components, maybe even write those in native code, but for the vast majority of interactions something higher level should work, shouldn't it?
After all you can implement something akin to Word in JS + HTML (Google Docs).
Fast compilation (merely being-interpreted) is surely a very cool feature which makes Go more appealing, but that is not the only productivity feature of Python.
I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could.
Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the reasons for choosing C/C++ are often the same that makes Go a really bad fit.
My dreams of a C-like language where the dangerous parts have been removed (and in this context I don't consider having control of your memory dangerous) took a hit with the introduction of Go :(
Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS.
I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level.
It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.
Due to my engineering background, I would always sacrifice performance for less risk and more reliability.
I've also spent 20 years writing C and C++ so I know how horrible it is.
The anything-but-the-OS-niche? I thought we had plenty of languages for that.
It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.
You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?
Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that?
When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)
Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.
We have plenty of languages, but most of them are low performance interpreted languages, have major compromises or are not architecturally sound. Go addresses a lot of those issues - more than any other language so far.
You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?
I don't ignore performance. There are many ways to achieve performance. I've worked on embedded systems (military, medical sector) and occasionally need direct hardware access which is where I use C/C++ and that is primarily to manipulate a device and hand off a suitable abstraction to a higher level language (with a garbage collector).
When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)
That is all down to determinism. Determinism can be achieved in various simple ways. If you understand the language, you can write code that pre-allocates and reuses memory in critical sections therefore invoking no garbage collection penalty. Isolating critical sections from each other is still a problem in C/C++ if you consider the threading model that they use.
Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.
I'm not a fan of all "those 20 JVM-based languages" - I find them tedious and ugly. I'm the most critical person on the planet when it comes to this sort of thing. Go pretty much hits the mark.
I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism i.e:
func CriticalFunc() {
defer runtime.ResumeGC()
runtime.PauseGC()
// critical section
}I don't think that scales to multiple threads. Remember, the GC is global. With a lot of goroutines, you're going to end up delaying GC far too long if any of them can block the GC.
These sorts of things are the reason why it's considered a bad idea to muck around with the GC settings in e.g. the JVM unless you really know what you're doing. The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.
I know Go's GC isn't there yet, but it's easier to centralize a performance improvement under this model i.e. GC improvements will lead to global improvements rather than case by case.
There's more than one way to skin a cat on this one.
And Go makes it much easier to avoid generating garbage than pretty much every other GC language around, already "by default" Go code tends to generate dramatically less garbage than for example Java, and when you care, you can further fine tune it to produce even less garbage.
for (Object o: collection) {
}
If you are interested, android team at had several talks at Google I/O (not just 2012) about optimizing memory usage.
AdaCore provides high quality compilers and tools (GPLed) under http://libre.adacore.com/
Interested fellas might start with reading this article: http://www.adacore.com/adaanswers/gems/gem-30/
EDIT: oops, that should be an answer to eckyptang... anyway, check out Ada. :)
Java believed the same thing. Many did switch. The difference today is that most of the people liable to switch already switched to Java.
If I could guess, I'd guess that Go is doing a better job at picking up Java programmers than C++ ones.
In Go, you'll be doing the C thing : you'll be reimplementing every datastructure from scratch (or use void, also known as interface{}), and have the same memory allocation problems as java. The problem with that is obvious : only experienced C library authors stand any chance of getting complicated trees right the first time (and I still only seen one person get red-black trees insert right first time once*, 3 other university professors and several assistants failed).
And the fact that you need to write those things from scratch everytime means you've got to debug that extremely finicky and difficult code every single time ... and then a junior programmer comes in and says "hey I can get to the internal fields easy, why don't I just" and you're in for an 8 hour debugging session because that causes a crash in the normal insert code, not the actually wrong code.
One thing I did in go that really, really bugged me was sorting a list (sorting a list of strings). I was making it as short as I possibly could without violating style rules ... 70 lines of code. That's ... well that's just not reasonable.
ArrayList<String> x = Lists.newArrayList("b", "c", "d", "a"); Collections.sort(x); System.out.println(x);
Give me the Go equivalent, in less than 50 lines of code. Please. That just has got to have a short solution, right ?
As it stands, I believe Go is good at being a fast conduit for nearly-ready data. A way to write asynchronous servers. If you need complicated algorithms or quick ways to change data operations ... maybe I'm wrong but it just looks like Go is really not going to be your friend.
If you're writing realtime code, you can avoid triggering the garbage collector simply by not allocating memory on the heap. It is harder to get anything done this way, but writing realtime code in any language is difficult.
But there's a huge uphill battle ahead for Go here. For instance, I write C++ code because I'm doing music software and all the APIs and existing code libraries and samples are in C++. It's just so much easier in this environment to put up with C++'s warts than it would be to try to shoehorn Go in there. As John Carmack says, externalities can quickly overwhelm the advantages of any particular language.
But if you're implementing web services from scratch you don't have any of that baggage to carry around so it's much easier to choose Go.
This is true only for very limited meanings of "anything"; if your point was that you had direct control of memory layout and you can use CGO for those things that C offers but go does not. For instance, the volatile keyword..
Most things don't seem surprising in hindsight. That's why you don't judge surprises by it.
If C++ programmers did flock to Go, would you then say that that was surprising? If not, you've just fallen victim to hindsight bias (because a model that predicts everything is useless).
Surprising was GP's original term, not mine.
I don't expect Go or any other language to displace C++ any time soon. But I do think the "scripting" languages are very vulnerable to challenges from languages with static typing systems less primitive than Java's.
Hindsight makes things obvious.
As someone who has been clamoring for a statically-checked Python-esque language, Go looks awesome.
I'm aware of gohaml; but last I checked it hasn't been updated to work with Go1 and friends. Namely it's using `gomake` and the packages aren't organized for use with `go build`; those issues alone have stopped me from considering it.
I went for a version of mustache.go instead, and then bolted Lambda support onto it.