I'm currently a developer on the MEAN stack. Do you know of an example project where Node.js, or maybe even the client side js is replaced with Clojure?
We're working on it! We removed the software because it needed extensive cross-project reorganization, consolidation, and cleanup which just wasn't possible to do with a clean upgrade path using available resources (3 backend engineers). Plans are to re-release all of this and more, and we've already started with Plumbing and Graph: https://github.com/prismatic/plumbing. Which librar(ies) in particular are you most interested in?
2. They have a startup program you can use to get like $10k in credits.
3. DigitalOcean isn't anywhere near saturated. Remember the golden days of EC2? It'll quickly deteriorate.
4. You don't use dedis exclusively for the "bang per buck", you use them for the peace of mind and knowing your I/O isn't going to plummet by 3/4s because a new subscriber landed on your node, thereby fucking your database to hell.
5. I want dedis from DigitalOcean.
6. Don't use multi-cast ElasticSearch clusters on DigitalOcean.
@6. It is perfectly fine to use multicast ElasticSearch clusters on DigitalOcean - just make sure to use an ACL to protect the environment in a public cloud environment.
DO's CPU performance has generally been worse than Linode's in benchmarks and that was before the recent Linode upgrade so they're probably even further behind now.
It's not that DO is good, it's that SoftLayer is terrible. Don't use SoftLayer as a benchmark for anything but wasting your money.
Also these kinds of blog posts are a waste of time.
Edit: And more importantly, there are wrappers for the standard data structures designed around different concurrency use-cases (sync, async, coordinated, uncoordinated)
Refs are for Coordinated Synchronous access to Many Identities".
Atoms are for Uncoordinated synchronous access to a single Identity.
Agents are for Uncoordinated asynchronous access to a single Identity.
Vars are for thread local isolated identities with a shared default value.
And you can use all (all!) of the Java concurrency tooling as desired, including raw threads (for which Clojure has a wrapper as well).
Part of the reason I use Clojure rather than Go is because it doesn't try to force you into a one-size-fits-all method for handling concurrency. I have no problem with CSP but it doesn't fit everything I do. Sometimes I just want to defer work or wrap it in a future. Or I want to use an intelligent coordinated data structure rather than trying to meld flesh and bone to steel in order to make a concurrency-naive data structure behave how I want in a concurrent environ.
Go doesn't "force" you to use one method of concurrency.
It has more than one (you can do erlang-style share-nothing style or Java/C++ style of using mutexes to protect shared state from concurrent access).
I know nothing about Closure so it's possible it has more features but it's not necessarily a good thing. Is the complexity of 4 different solutions worth it? (by "it" I mean: a programmer has to learn all of them and when to use what; the implementor has to implement them; write wrappers for all standard data structures (what about third party libraries?) etc.).
Feature bloat has a cost.
Go gives you all you need to easily write concurrent programs and it does it with refreshingly simple design (both for people to learn and to implement).
So why use Go instead of node.js? You can probably take that reasoning and substitute "Go" for "Clojure", and "node.js" for "Go".
Go people would probably object that the things that Go adds, and that node.js lacks, aren't just window dressing -- sure, there are situations where a node.js-style fast event loop that avoids blocking operations is all you need, but there are also situations where you want something more like real threads, because the problem demands it.
I'm a lisper but not a Clojure expert - but I'd assume that Clojure people don't consider the existence of e.g. Actors to be "feature bloat". My impression is more that the difficult/special concurrency-enabling feature of the language is STM, and language-level support for different concurrency paradigms, implemented on top of STM, are probably low-hanging fruit once you've got it.
Yep, futures can be done easily in Go with a goroutine that sends a single value on a channel, but: 1) you can't dereference the value multiple times in Go, so you have to manage saving it yourself, and 2) there's no syntactic sugar. Pity.
tx, but I meant the toolset and ecosystem, not the language features. popular frameworks, libs, out of the box solutions, opensource community, etc. - is clojure rich in this matter?
It's not as good as Python yet but rapidly getting better.
There's an excellent SQL abstraction library (Korma), Ring makes for a nice WSGI equivalent, Compojure and Clabango combined give you a Flask'ish experience, and there are a goodly number of Forms and validation libraries.
Some like to use CLJS on the frontend. There are libraries out there for making that nice.
I usually use vanilla jQuery or Angular on the frontend, no CLJS.
You need get more specific with your queries, I'm not going to write a novel at the merest hint.
tx. I was curious how it'd look like to replicate an example full stack of a Python project and you basically covered it. I remeber looking around some time ago and then Noir looked like the go to framework for Clojure, but now it seems discontinued. gotta try CL some day.
Food's terrible to boot.