I feel uncomfortable when reading your post. Passive aggressive, attacking the OP's architectural decisions, assuming that he didn't have any clue building a proper Ruby system. I am not a fan of Go, not at all, but I know that Ruby has significant issues which the OP also outlined quite well and you seem to just ignore them.
But Paul Graham knows exactly why you are sticking to the past (just replace 'Blub' by 'Ruby'):
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.
I certainly didn't intend to be passive aggressive or attack, apologies if it came over like that.
The point remains though; it's not that the poster doesn't know how to build a 'proper' system in Ruby, but that the frequent articles we see with the theme "we rewrote our system from language X to language Y and it's much better!" are rarely helpful, because (I can't stress this enough) architectural design is vastly more important than what language you are using to implement your system.
This leads to a dangerous bandwagon-jumping faddism where developers start jumping on to the next big thing, because they assume it will solve their problems. We saw exactly that with Ruby, for example; developers assumed that they could escape from the verbosity and enterpriseness of Java just by changing language, ignoring the pitfalls that could be experienced.
PG's 'blub' example is a very useful allegory, but it doesn't apply here. I'm not at all suggesting that Ruby is the perfect solution to all problems, or that using Go is wrong – I use both of them! Just that saying 'Go is better than Ruby for writing web apps because we reimplemented everything and it was faster' is not helpful.
We saw exactly that with Ruby, for example; developers assumed that they could escape from the verbosity and enterpriseness of Java just by changing language, ignoring the pitfalls that could be experienced.
this worked for a lot of people until they got to the architectural stuff. but going from Java to Ruby (infinitely nicer) is distinct from going to J2EE to Rails (easier to get started, harder to keep going).
So here we've got a Ruby/Blub programmer looking down the power continuum at Go and sees language deficiencies. He looks up the power continuum and sees maybe Haskell and Clojure etc. Since Go was created[`1] to be down the power continuum and contains nothing weird, new, or even particularly different, I don't think the adage holds.
[1] citation needed
Seriously, why do you think Go was created up the power continuum? It may be, but what features or idioms (barring channels) put it "up there?"
> You really don't need a package manager for Go. Honestly, the main reason [...] is because you're deploying source code to your production environment
Not sure if I would agree with that. A full-fledged package manager automates the process of installing, upgrading, configuring and removing software packages in a consistent manner. Dependency management and semantic versioning is an important part to provide this consistency.
Wether you deploy source code or binaries does not make any difference why a package manager is always good to have.
The Go tool does do installation and upgrading. There's not really any configuring, and it'd be hard to do removal in any reasonable manner given how GOPATH works. What the Go tool does not do is isolate you from breaking changes upstream. For that you need someone you trust (which could be the package author or a copy of the code in gopkg.in), or be willing to fix breaking changes (which I do quite often).
We really don't need any more binary package managers - that should be the responsibility of the platform you're deploying on. dpkg/rpm/etc on Linux systems, MSI on Windows, APK on Android, etc.
One reason I love package managers, is that as developer I don't want to produce a dpkg/rpm/tgz/apk/msi/ipa/p5i/depot multiplied by the different locations of include files, libraries, documentation across the said OS.
A huge photo collection is the best lock-in for an OS. So to have a top-notch app here is a smart move from Apple.
I have like 70GB of photos in iPhoto and somehow this stops me from fully migrating to another OS. Just the thought of moving this 70GB to another file system, OS and photo program let me stick to OSX forever. And photos especially the family ones are maybe the most important 'personal' data of a user.
Besides, iPhoto is not bad but the many format changes in the past were a bit tiring.
In general I prefer Dropbox as a cloud file storage--they have the best clients of all OSes and security features like no other (remote wipe), now I just need a cross platform photo database which is separated from my cloud storage provider.
I don't see how this is lock-in, unless they have somehow crippled the exporting feature. It seems like the only thing preventing you from moving that 70GB of photos is a lack of motivation.
Lock-in, as in a lock I can't unlock? As in I can't get my photos out if I want? It's only lock-in if you want to leave and you can't.
I'll be as locked into this as I'm locked into my favorite scotch. I can switch, but why?
I really don't get the lock-in argument. I like Apple's stuff, all of it. It works really well for me. I'm the happiest I've ever been with my computer environment. If Apple starts to suck I'll find something else, as will many other people and some enterprising fellow will see that and create something great. Better yet maybe Dropbox will up their game to compete with Apple on photo storage. Rising tide etc etc.
With iPhoto, you can easily move your photos elsewhere, but moving the metadata with it (what photo is in what album, recognized faces, etc) is another thing.
A huge photo collection is the best lock-in for an OS. So to have a top-notch app here is a smart move from Apple.
On the other hand, pretty much anyone who once used Aperture has moved to Lightroom after feeling the effects of Apple's enthusiasm followed by Apple's indifference. Presumably whoever is making an iPhoto (or whatever) equivalent on Windows will write an import feature that imports whatever format or formats Apple uses.
I want to be enthusiastic, but I've seen one too many Apple initiatives dropped to get real excited. I've also seen iPhoto libraries corrupted and heard the screams when it happens.
My initial reaction was "oh is that all". I mean don't get me wrong, the way the site works is nice, but I was really expecting it to move the code around such that the whitespace formed a picture, or have all the lines of code in random text sizes, or allow you to prioritise different sections so that some were highlighted or something like that.
As it stands it's not really something I want on my wall.
This reminds me of Litographs, a company that puts full text of books in poster form. While the concept works fine for prose it doesn't translate well for code.
Same. I was expecting something more like Perl's good old "Acme::EyeDrops", which obfuscates your code, then pours it into an arbitrary ASCII art shape. That's a lot more work than just removing whitespace and using characters as pixels, but this guy is charging money after all.
Really like the idea and just had this thought: why not just present the code in color, normally indented (so not like minified) and in your favorite theme (such as Solarized Dark) in a long portrait format poster, then put some glossy finish on it and I'd buy instantly.
2600 Pacman sure does suck, but to be fair, that video was recorded on a potato at 14hz, making the flickering ghosts inscrutable instead of just annoying.
Here's one that seems to have been recorded at 60hz then downsampled to 30hz with frame interpolation for Youtube. Still shit, but at least you can tell what's going on. Kinda.
Think of it this way: you paid for a Kickstarter project to be delivered in 40 years time, got an early proof of concept showing game play and a nice display box, and the real thing was finished before those 40 years were up.
Probably I am alone here but I think that Snapchat is the biggest innovation in the social space since Facebook and not just because of it's ephemeral nature. Let me elaborate and give my view why I think Snapchat is great and one of my most used apps.
- To start, Snapchat changed my communication behavior heavily. Before Snapchat people used any kind of messengers when they had a clear intent to start an interaction with another person. With Snapchat you just send something. You do not want to start a conversation, often you just share what you do right now, how you feel and very often it's so close to what you are and not some polished something you would like to be. You share emotions in forms of pics also on Instagram and Facebook but this is different since the emotions you present there are highly curated, see below for more.
- There are no 'likes' and this is wonderful. The existence of likes sets us under pressure. If we post something on Facebook and do not get a single like it's embarrassing and leads to postings which are only of outstanding nature painting a distorted picture of our life. Facebook is anything but not reflecting reality.
- Sending and selecting a few contacts is so fast and I do not know one single app which has a slicker process. This again leads to so much more honest and personal messaging. Since I target on other platform many more people I have to take care about my postings. On Snapchat I can quickly select a bunch of people and leave those out who might be bored by a single snap.
- The process of taking a picture is different than with the stock camera of a phone. You take a pic which is NOT saved—usually it's immediately saved and if you do not like it you have to go the the gallery, delete it and confirm again that you want to delete it. This is very annoying if you take selfies. Snapchat turned this around and once you find the right shot you can send and/or save it. Small thing but so convenient.
- Features like slide-in filters, painting on the pic, amazing video calling are just nice amenities but again show that Snapchat's interface is just great and miles beyond other cluttered UIs.
- One feature which I want to mention is putting text on pictures, no rocket science but again sometimes so funny and shows similarities to those meme generators.
- Finally, the ephemeral thing is not the key feature but it's the brand and the DNA of Snapchat, everybody knows that there's no privacy, people can screenshot the snaps and share it, period. But it's about being oneself and understanding that the pictures are just 'throw-away products', no shiny thing kept forever. This again leads to a very honest snaps. Snapchat is not about looking good.
I encourage everyone who doesn't 'understand' Snapchat's success to try it, it strengthens the relationship to close contacts and friends much more than other 'social app'.
this is really AWESOME and finally shows what is possible with the power of nowadays browser rendering engines paired with a good JS lib (React is my favorite js lib).
I like very much the butter smooth transitions on any phone and it's nice that you spent so much attention in getting this thing so responsive, well done man.
When will this thing be live, having more documentation and can I play already around with the stuff on Github?
Thanks! We're stoked with the great feedback this is getting.
We will have more docs + examples up in the coming weeks, aside from that we're currently using it in three commercial apps at Thinkmill so what's there is pretty solid.
The projects we're building with it include a Bitcoin wallet (built on BitcoinJS), a cinema voucher scanning app and another I unfortunately can't talk about yet. It's holding up really well across the different use cases and UI designs.
But Paul Graham knows exactly why you are sticking to the past (just replace 'Blub' by 'Ruby'):
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.
Source: http://www.paulgraham.com/avg.html