timanglade

Just to be clear on the topic, since this is an easily misunderstood aspect of Realm: we are not an ORM. We’re not built on SQLite, we’re not mapping to a relational layer, nor are we serializing objects from a third-party data representation: your objects in the language are exactly the same data that’s stored on disk.

We heard a lot of dissatisfaction from the community as far as Core Data is concerned (including from Apple engineers themselves). I’m also not entirely sure you could ever get Core Data performance to the levels we enjoy, since Core Data cannot be any faster than the SQLite underneath, after all. I do want to say that your feedback on how we present ourselves and the work ahead of us is spot on and much appreciated. Many thanks for speaking up, we will work hard to heed your comments & improve.

Sorry about that. We’ve been seeing some issues with our CloudFront caches all morning, but if you give it a hard reload or two in your browser, you should eventually see our Swift samples — we’ll keep working to fix the issue.

You can do the same thing with Realm. We actually have a couple of key benefits over SQLite there, which are that our file size is much smaller (usually about 50%), and we don’t require deserialization to get objects out of the file (Realm data can be streamed directly into memory as native objects in your language).

On the minus side, We don’t work from everywhere yet, but we have internal bindings for Python, Ruby, C#, Java, PHP and a few other languages. We focused on the iOS launch so far, but we do plan to wrap up those additional implementations and share them on GitHub.

The big thing is really ease of use. Our blog post has a few more details on that point [0] but basically what we heard over and over and saw ourselves, is that Core Data quickly gets in your way if your app grows [1][2][3]. In essence, we tried with this initial release to offer a rich feature set with a simple API, less side-effects (especially for multi-threaded apps), and a performance that’s even better than using raw SQLite.

In early testing we got a lot of higher-level questions about what Realm was exactly, so we decided to go for a descriptive tagline instead, but you’re right that we should add more details about how we compare to Core Data!

  [0]http://realm.io/news/introducing-realm/
  [1]http://wbyoung.tumblr.com/post/27851725562/core-data-growing-pains
  [2]http://alastairs-place.net/blog/2013/04/17/why-core-data-is-a-bad-idea/
  [3]http://inessential.com/2014/06/11/core_data_thoughts_june_2014

(EDITS: formatting)

Hi, co-organizer here. I definitely hear you on this. I actually ran something called the “NOSQL Summer” a few years back and we ran into a similar question, so we created a bunch of “NOSQL Winter” aliases to cover people in the Southern hemisphere. We may do something like that for the SoS as well.

It’s hard to resist names with Summer in them, because it’s a handy trope with lots of positive connotations. Summer (no matter which months of the year it happens in) is a good time for passion projects and the like. Plus there is the trend established by the “Google Summer of Code”, “Rails Girls Summer of Code”, “Infinite Summer”, etc.

Yes, first point, and datatypes as well. And to be fair, the author does state clearly that some of the features & benefits he lists can come from a mix of language/standard libraries, OS, runtime or third-party. At the end of the day, you just have to be able to be productive with the language.

If you’re coming up with a brand new language, you have to do a damn good job of compensating for it by piggybacking on existing VM/Libraries/third-party tools (which Swift largely does), building it in your language and standard lib (e.g. Ruby), or doing a good job at attracting a new community to build that for you.

His “If…” observations could easily be condensed into a Bechdel-style test. Easy to game, not entirely accurate but starts painting a picture of the maturity & productivity of the language.

It’s funny to consider how poorly Swift does against this “Bone Test” (mostly due to all the Objective-C/Foundation heritage):

- Hello World in < 5 lines: pass

- Sending email in 1 line: fail

- GET/POST to web page in 1 line: fail

- Number of days between 2 dates: pass

- JSON: fail

- Modern datatypes: mostly passes but no REGEX in Swift is a big fail. The matching Foundation class NSRegularExpression doesn’t count because Jeff is clearly asking for native, in-language support.

- Package distribution: fail (although now you can finally build Frameworks for iOS, not just Mac OS, and if we’re counting third-party, it’s likely that CocoaPods will support Swift soon)

So final score 2/7 on the Bone Test, although I’m sure by the time Swift goes GA a lot of them should be fixed.

They generate new Swift headers for Objective-C classes, and have translation rules in their toolset to remap/rename some arguments (all the init methods for example). The tool can even do that on your own Objective-C projects. I used this on a side project this weekend and it’s pretty rad.

Depends on the position, your location and your profile but yes, it’s a strong possibility! Some teams are entirely remote.

CouchOne abandoned any sort of marketing effort around CouchDB long before they got acquired by Membase. Since then, they have focused their attention solely on marketing the Couchbase brand, with close to zero time spent evangelizing Apache CouchDB. The other CouchDB “vendor”, Cloudant (who I work for) never had much of a marketing budget, so we spent no time marketing CouchDB either (we focused on building and marketing our own products, open-source BigCouch and hosted Cloudant).

This situation did not catch us by surprise; I flagged this as a potential issue at Cloudant and had conversations about it with the CouchOne guys back in January 2011.

What you see here is just what happens to open-source technologies when nobody spends time evangelizing them — and when maybe, just maybe, they’re not hip enough to get self-sustaining traction. I love CouchDB to pieces and believe it's an immensely useful tool with great things in its future — but it has long stopped being cool, compared to the MongoDBs and Nodes of this world. (Which is not necessarily a bad thing… Strong communities are not built on shallow attraction.)

So yes, both vendors decided to focus their limited resources on advertising their own products (successfully & deservedly so, I would argue) but I think the success & money that phase brings in will undoubtedly be funneled back into even more evangelizing & involvement in Apache CouchDB. (I'm speaking for Cloudant at least, don’t know what Couchbase’s open-source plans are for Apache CouchDB.)

I have to wonder why so many comments have ‘X sucks, please say Y which rocks’, as an attitude. Negativity doesn't really sell me on much.

Seriously though. The poor design (& egregious misuse) of those libraries became a major concern for us at Cloudant. I wanted people to become aware of what they were doing wrong & why. I thought it would be best done with a bang. Fixing the situation beyond the patches I submitted would have required that I go on a campaign to have those libraries removed from the face of the earth (which seems more extreme than very strongly recommending people stay away from them).

The Couch server goes from binary Erlang terms (our default internal representation) to MessagePack right away, skipping all textual JSON generation. All the REST methods are still there, the body is just sent in MessagePack format with an application/x-msgpack header https://github.com/timanglade/couchdb/commit/b601286dae04bdc...

The replication is borked, we know. The replicator database introduced in 1.1 only solves part of the issues at hand. Everybody at Cloudant & Couchbase is pretty confident that the 1.2 replicator will be much more stable & efficient, which is why there isn't a lot of activity right now on plugging holes in the old replicator.

To be clear, I'm only working on integrating a binary data format, which is different from a binary protocol.

HTTP is baked pretty deep into CouchDB, which makes it hard to remove (but who knows, Couchbase seems to be having some success ripping it out). BigCouch (Cloudant’s distributed version of CouchDB) has the HTTP layer neatly separated through the Fabric library (https://github.com/cloudant/fabric), so it'd probably be easier to add a binary protocol there.

Seriously, look at the design of the invite. Calendar says Tuesday (October) 4th. Clock says 10am. Map app says this will take place at 1 Infinite Loop. And the Phone icon makes it clear this will be an iPhone event (rather than an iPod Touch / iOS event), with one unread notification alerting you that there is something you must pay attention to. They say everything in 4 icons. So awesome.

I already responded to this partly in http://news.ycombinator.com/item?id=2764736 — We think the integration into a single deployment is in itself a big gain. Maintaining several of those infrastructures can be very painful, especially as your clusters grow large. Also, as mentioned, we’ve also already added several features on top of Lucene, and we’ll be adding more in the future.

Not entirely. The big difference here is that you only have one, integrated architecture to maintain. So that means less operational complexity, smoother “scalability” of your infrastructure, tighter integration between DB & Search. Also, we added stuff like queries across several indices, typed queries, etc.

1. I believe I was referring to Marko Rodriguez’ attempt, documented here: http://markorodriguez.com/2011/02/18/mysql-vs-neo4j-on-a-lar... I love Marko to bits and he often publishes work of great insight; but I'm not sure what he was trying to demonstrate with this one.

2. I'm not going to try to get into Ben’s head — I'll let him answer that.

3. Downtown Seattle. I have no idea what emergency was going on but there sure was something :)

antirez and I tried but the schedule didn't work out. He’s on my list for 2011, if he’s still up for it :)

I've been using Unfuddle for all of my projects for a few years. We have a few projects and around 10 users. Works wonders.

In case you read French and want to see how it's been done on the other side of the pond, check out Agoranov: http://www.agoranov.com/

It's designed to incubate faculty or student projects from the Paris metro area. They're 100% seeded with public funds (from the Regional, National & European levels). They incubate software, web but also electronics, green tech and life sciences projects. They're not run by faculty or students but by a dedicated team with professional and entrepreneurial experience.

Now, to be honest, I'd probably say they have had mild success so far. I know it's far from being a true indicator of “success” in this field but for example, they haven't incubated a company anyone would know about outside of the local start-up scene. But they've been at it for 9 years and they're still growing. They offer real workspaces in a handful of offices they operate around the Paris area.

If you have any questions about them, I can try to answer or put you in touch with the team.

I do get the added-value of having it as a webapp for some but as a developer, I'd rather use Tarantula in my test suite. Hunts down 404s, 500s but can also do HTML validation, check against common attacks (CSRF, XSS, etc.)

http://github.com/relevance/tarantula