As much as I dislike that most of the "language shootout" benchmarks are mostly numeric wanking, the binary tree benchmark actually makes, uses and disposes of quite a few data structures, and seems more like a real application program to me.<p>Go isn't yet faster than Java, but it is closing the gap, at least on multi-core: <a href="http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=all&data=u32q" rel="nofollow">http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...</a><p>Single core doesn't fare so well (Go vs Java), though: <a href="http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=all&data=u32" rel="nofollow">http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...</a><p>Perhaps the authors should have used Rust, or Ada, rather than Go? Hell, on a single CPU machine, FreePascal seems to do better than Go :-)<p>Actually, from a "performance, w/out turning off all the safeties" standpoint, it really looks like Rust is owning that space.<p>Now I gotta learn Rust... :-)
Just trying go for some real project, and frankly i wouldn't use it for anything else but network-related middleware ( or low level services), which is what i'm using it for, and almost every tutorial i've read about this language mentions.<p>As long as you're building something very technical, everything's fine. But once you go out of this path, you can see the walls getting dangerously closer.
For example, i was surprised to see how many runtime errors i got while coding, for a statically typed language.
Surprised as well to see that error checking made me wish for a goto statement again ( what's the pattern for handlings all errors in a block with the same code ? Please tell me..)
Then i started to code against a sql db, and boy did it bring me old memories back. Manual transaction scope handling ( annotation where are thou ?), manually counting bound variables in a statement, finding mismatched types between nullable ones and regular ones....
What a mess...<p>Now it <i>may</i> only be a matter of waiting for advanced librairies to mature, but somehow i doubt it.
> I'm pretty darned sure that Rob Pike (creator of Go) and Chris Lattner (creator of Swift) know a few things about computer languages that the rest of us haven't sussed out yet. If these guys think the world needs a new language, it's worth finding out why. (And if you do know more about programming languages than these two? Well, it's honor to have you reading my article, Mr. Wall!)<p>Larry Wall is the <i>ne plus ultra</i> of programming language design. This is satire, right? Please tell me this is satire.
><i>By now, you may be asking yourself why we would choose to use such nascent languages in a production environment.</i><p>No, we realy are not. If anything, both are quite safe bets.<p>Swift had been in secret development for years and came out almost fully formed (as far as languages go), with a full API, tooling, documentation, etc. Besides it's the Apple blessed way to do things on iOS going forward.<p>As for Go, everybody and its dog are using it for production, left and right. Including very big names. It's pretty much a given that the language is already production-proven, and will do well in the future.
Yes! Two modern languages that are 1) statically typed and 2) statically compiled. At least some people still get it that "modern" and "nice to use" does not implies scripting-like dynamically-fancy typed language "à la" PHP/Python/Javascript/...
And the author did not mention Playground for Swift which is just incredibly useful to start experimenting with the language!
(Edit: of course Rust is another one as well, but I was in the context of the article)
I have been playing a lot with QML lately and I am loving what I see there. Their approach of animations or graphics seems simple and very approachable - <a href="http://qmlbook.org/ch05/index.html" rel="nofollow">http://qmlbook.org/ch05/index.html</a> .<p>The reason I bring this up is, while I like swift (and own more than one macbook pro), I can't bring myself to code for a platform which ties myself further with Apple eco system.<p>If you are looking to build a cross platform 2D game for Android/iOS/OSX/Linux - QML seems like a very good choice.
Hi @rohamg, I was wondering if you could please share the libraries and frameworks you are using? I'm also building a mobile app in Swift with a web backend in Go. I've done a bit of research, and I think I'm going to use the following:<p>iOS:<p>* MagicalRecord - CoreData abstraction (<a href="https://github.com/magicalpanda/MagicalRecord" rel="nofollow">https://github.com/magicalpanda/MagicalRecord</a>)
* mogenerator - better CoreData class management (<a href="https://github.com/rentzsch/mogenerator" rel="nofollow">https://github.com/rentzsch/mogenerator</a>)
* RestKit - with REST API endpoint (<a href="http://restkit.org/" rel="nofollow">http://restkit.org/</a>)<p>Go:<p>* Gin - Web framework. I really like the focus on performance, and that it seems to include all the features you need for an API (authorization, route grouping, etc.) (<a href="https://gin-gonic.github.io/gin/" rel="nofollow">https://gin-gonic.github.io/gin/</a>)
* gorm - for most CRUD operations / queries (<a href="https://github.com/jinzhu/gorm" rel="nofollow">https://github.com/jinzhu/gorm</a>)
* sqlx - for more complex queries (<a href="https://github.com/jmoiron/sqlx" rel="nofollow">https://github.com/jmoiron/sqlx</a>)
* apns - push notifications (<a href="https://github.com/anachronistic/apns" rel="nofollow">https://github.com/anachronistic/apns</a>)
* gingorelic - New Relic integration (<a href="https://github.com/q1t/gingorelic" rel="nofollow">https://github.com/q1t/gingorelic</a>)
* APIBlueprint - API documentation (<a href="http://apiblueprint.org/" rel="nofollow">http://apiblueprint.org/</a>)
How does a language without generics claim to "do more with less code"? Don't get me wrong, I like Go, but it's hard to get behind any language with that low of an abstraction ceiling. Then again, I work in a web shop, building CRUD apps for a living, so maybe it doesn't matter for people who only have to build one version of something.
> Go compiles very quickly, but that actually didn't impact us very much since we have largely been using interpreted languages on the backend. I'll betcha those poor Java programmers get pretty excited about this, though!<p>Oh?