Eager to get some community feedback on this app launch. I'll spare this audience the marketing speak and go right into what is different:
- OpenGL instead of UIKit. The message stream and individual messages are all 3D meshes with shader materials on them. Making them easy to animate/interact with each other in novel ways.
- Handwriting instead of Helvetica. We're using a patented system from our other product (handwriting.io) to generate 3D meshes of handwriting. This adds a surprising amount of personality to a chat session.
- Effect system marketplace. Because the effects (on text and replies) are JS+WebGL they can be deployed without shipping app updates. Hopefully with a decent SDK visual devs would enjoy making chat effects on this platform.
Very cool idea. Would be nice if there was some way to see a summary. Maybe it gets like a little mini-dashboard somewhere on the screen, and then I can click it to hide/show all notes, edit existing ones, or maybe even see all notes across pages on the domain.
Nice write-up. I find this sort of thing fascinating. When are you guys thinking of tackling more languages? Maybe something that lends itself to static analysis a bit more?
Also how long did that regex take to run on 5.0e8 lines of ruby?
About 2 hours. The regex is IO bound, on a text column with 87GB + 68GB postgres toast. It's on a new 1TB 3k iops EC2/EBS ssd volume, which seems to be able to sustain about 20MB/s.
20MB/sec is pretty dreadful, and 2 hours is not timely for that quantity of data.
I'm guessing you're paying a high price for the convenience of using a database? The kind of query you did, I'd run using grep on the command line source, possibly combined with a summarizing program written in Ruby.
I love the power of the unix shell. find | cat | grep would get the job done just as well if you had all the source in an accessible file tree, but I don't think you'd see any performance increase as the bottleneck is still random reads from EBS.
The single 3k iops EBS volume being used delivers a max theoretical speed of 24MB/s with 8k pages. I'm fine living with 20MB/s in practice.
In fact, postgres does inline (de)compression and optimizes for sequential reads, so it's likely the shell would be slower for this workload given the apples to oranges characteristics. I'd love to see any performance tests making this sort of comparison, they're always educational.
Even with a database it's dreadful. At 20MB/sec they need to value the time they have to wait very low before it'd be cheaper/faster to buy a small server outright and put a couple of ssd's in it if they do this kind of analysis more than a couple of times.
Or even load it up with enough memory to keep everything in RAM during normal operations. I can't remember the last time I worked on a system that did less than a couple of hundred MB/sec... And we generally buy servers in the $3k-$6k range, so nothing ridiculous.
A lot of python shops I've come across don't use the system installed python or ruby. In python land at least it's exceedingly common to deploy a virtualenv with a separate python runtime and isolated 3rd party libs. This makes pinning your version deps easier and doesn't matter if the underlying server is ubuntu or centos or whatever.
That is true, what if in future ubuntu/centos include Go by default (which might not the version you use)? I believe then will have some GVM or similar tool to solve the problem.
Edit: As others pointed out, Go is compiled binary and does not required runtime (like JVM) so versionning is not issue. Thanks for clearing up.
There won't be a need for a GVM as Go is not a stand-alone runtime. Once compiled for a specific platform it will just run. You don't even need it installed on the server. You can cross-compile on your DEV machine and move the binary LIVE. Then it just runs. It doesn't need any libraries on the server.
Does Go not have the concept of linking? If you are deploying several Go applications on the same server that each use libraries, does it include duplication of libraries in every binary?
There is no linking. Each Go binary has all of the libraries it needs baked into it.
So if you have multiple different Go applications on one server, and they use some of the same libraries, then each application's binary will contain a copy of that library.
It makes things a little redundant, but also simplifies the deployment process.
edit: The only exception is if you are using cgo and liking to existing C libraries. In pure Go there is no linking.
Go applications require no installed runtime, they compile to native code. You can have no Go installed or any Go installed on the system, and the executable will neither know nor care.
Not being a Go developer I don't understand why this would be the case. Doesn't Go compile code to a binary? Why should Go even be required on the server?
Yeah, many of the ruby applications I've seen recommend RVM so that you can isolate yourself from the system-installed version of ruby. That's the nice thing about go - each application carries around everything it needs to run in total isolation from the rest of the machine.
I should just stop making assumptions about python and assume that if there's anything you ever would like to do with python, that someone has already built it :)
I've always liked what Mercurial's docs were trying to do (http://hgbook.red-bean.com/read/customizing-the-output-of-me...) by having comments at every paragraph of their docs. It's done about 10% as well as it could be though. You almost want stackoverflow style questions to link to direct paragraphs or maybe even sentences.
Maybe overlaying something like rap genius' tools on existing docs is enough?
Looks really nice so far, but I don't use ruby so can't vouch for accuracy of search etc...
Eager to get some community feedback on this app launch. I'll spare this audience the marketing speak and go right into what is different:
- OpenGL instead of UIKit. The message stream and individual messages are all 3D meshes with shader materials on them. Making them easy to animate/interact with each other in novel ways.
- Handwriting instead of Helvetica. We're using a patented system from our other product (handwriting.io) to generate 3D meshes of handwriting. This adds a surprising amount of personality to a chat session.
- Effect system marketplace. Because the effects (on text and replies) are JS+WebGL they can be deployed without shipping app updates. Hopefully with a decent SDK visual devs would enjoy making chat effects on this platform.
Thank you for checking it out!