Hacker Newsnew | past | comments | ask | show | jobs | submit | codewright's commentslogin

There's a VC funded Indian burrito joint in Palo Alto. I've eaten lunch there three times, once with a potential investor.

Food's terrible to boot.


Tava Indian? They're in SF as well now, I share your experiences.

http://www.tavaindian.com


Yep. Awful food. Not, "awful Indian food". Awful by any standard.

I don't think the founders had any experience with food before doing Tava.


Haven't eaten here, but if this is true, it's a tragedy. There are so many ways to do an Indian burrito right.


Would be great if not for the CPS. I end up doing something similar except with Clojure instead of Node.js for my projects lately.


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?


Clojurescript clientside. Noir serverside. http://www.chris-granger.com/projects/noir/ https://github.com/clojure/clojurescript

you could also use clojurescript serverside using node.js. this is what LightTable does iirc http://www.chris-granger.com/lighttable/



Noir is deprecated, use vanilla ring + libnoir or Luminus.


http://github.com/bitemyapp/neubite/

There's a CMS, for starters.


Take a look at Luminus.


Recently left Heroku, too many failures. The last week I had my app on Heroku availability was in the realm of ~60-80%.

Between that and the obscenely slow and overpriced Postgres...nope.

(Clojure user, I don't think Heroku's platform plays nice with things that take a bit to fire up. Or the JVM in general.)


Carthago delenda est: when are you re-releasing the software you yanked from your Github?


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?


Are you going to re-release the stuff you yanked off your github?


Just use http://serverbear.com/ and be liberated from blog spam like this.


I use DigitalOcean but this is silly.

1. SoftLayer is well known for being over-priced.

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.


The server benchmarked on SoftLayer is not dedicated, it is on their CloudLayer platform (virtual machines).


Then this is even sillier, SoftLayer non-dedi is pointless, they're notorious for being overpriced as a brand.


Pricing aside, we were stunned at the performance difference. Never expected 3.2X improved performance from DigitalOcean.


They're not saturated yet.

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.

http://serverbear.com/


The beauty of concurrency in Clojure:

; Rough sketch: def defines a var (pretend it's a reference)

; @ is used to dereference the future and block to wait for the result.

  (def f 
    (future 
      (Thread/sleep 10000) (println "done") 100))

  user=> @f
  done
  100

  ;; Dereferencing again will return the already calculated value.
  => @f
  100
http://clojuredocs.org/clojure_core/clojure.core/future

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.

http://stackoverflow.com/questions/9132346/clojure-differenc...

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.

If I can avoid those unnecessary battles, I will.

So - Clojure.


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.


Static typing and availability of AOT compilation?


Futures in C++11 are similar:

    int x = std::async([]()->int{
            return 100;
        });
    std::cout << x.wait() << std::endl:
Which isn't as nice as closure. Go could probably benfit from having a standard futures tool. I guess something along the lines of:

    type Future {
        Wait() interface{}
    }

    func newFuture(func interface{}, 
                args ...interface{}) Future


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.


You could save the future in the Future implementation

    type future struct {
        completed   bool
        result      interface{}
        ch        <-chan interface{}
    }
Edit: Or just check if the channel is closed

    func (f *future) Wait() interface{} {
        v, ok := <- ch
        if ok { f.result = v; return v }
        else  { return f.result }
    }


I got this wrong. std::async should not return an int. It's should be std::future


Clojure, I used to do Python with Django or Flask.

HTML/CSS aren't optional so I don't know why you included that in the list.

I've tried Node.js, hated it.


could you describe your experience switching from python to clojure in web dev?


More powerful language (primitives, concision, macros), more performance (JVM fun-ness).

Some aspects of the JVM (slow-start) are icky but the tooling works around it (in-runtime auto-reload without restarting the JVM).

I'm a grumpy old CL'er so I was waiting for something like Clojure to come along anyway.


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.


CL is Common Lisp.

The go-to for Clojure is Luminus, which is less of a framework and more of a "web best practices" project template.


oops, I meant CLojure :D not very fluent in the Lisp department. tx for the tips.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: