IMHO the best thing about vim are movements and modal editing. Once you have the muscle memory for that it's really hard to go back. However, almost every major editor / IDE has a vim mode these days which for me is the best of both worlds. I don't need to mess with configurations for days but I still get (almost) all the power of the vim editing model.
I've been playing around with OCaml a fair bit in my spare time too. I've been using Go at work full time for about 4 years so that's my main comparison.
I love OCaml as a language but the ecosystem is really pretty bad. There is just too much fragmentation and lack of libraries. I would have expected more from a language that is over 20 years old.
Don't get me wrong, I want it to succeed since I agree it has a really nice mix of features.. I just have my doubts given its track record so far.
> Don't get me wrong, I want it to succeed since I agree it has a really nice mix of features.. I just have my doubts given its track record so far.
While I agree... Javascript is also just as old and arguably more fragmented (with the exception of jQuery).
That being said perhaps unlikely but OCaml may make a massive comeback just like Javascript did (particularly if for some reason Rust fails which I doubt).
Javascript has web giants' backing who made it work and well enough to write sophisticated frontends like webmails etc. OCaml has Jane street and may be a couple more using it as secondary language for some applications. I don't think it is going to catch up big time.
I'd be interested to know this as well. I can understand time constraints in compiling these kind of comparisons, but as I'm about to embark on a web project in Go, I'd be interested to know if there was any technical constraints that prevented benchmarking Go.
We recognize that deficiency and we do aim to add database tests for Go. If you could quickly draft that up and submit a pull request, we'd love to add it.
Sorry, but as much as I'd love to contribute I'm still learning how to write database apps in Go myself (that's actually part of the reason I wanted to see your tests). So I'd be the wrong person to to write code for that particular test.
It implies an e-mail address and the expectation would probably be for the provider to receive an e-mail sent to that address. Not unlike @facebook.com addresses, so it may work.
Email is a federated system just like status.net, rstat.us etc. We can all have our own clients, servers, and still interact, communicate, and play well with every other email server.
Using the same means of locating a person seems very very reasonable from both a technical aspect (it works for them just fine) and from the viewpoint that people already understand that an email address represents somebody's online presence and this is how you can communicate with them. Concept familiarity is extremely important for adoption, so that should be considered.
