Live data from Hacker News

Clojure-powered Startups

infoq.com

31–40 of 62 posts

Re: Clojure-powered Startups

#31
post #23

I'm curious about how startups using Clojure are generating their HTML. Are you guys doing it in Clojure code (e.g. Noir) or are you using some sort of HTML templating support (e.g. JSP)? While I really like the idea of writing HTML in Clojure, I like even more the idea of being able to have a HTML/CSS/etc expert, who doesn't necessarily know Clojure, be able to maintain the HTML instead of me. Has anyone found what…

At Circle [1] are doing practically all of our HTML on the client side. Our server exposes an API using Noir, and we had to build a lot of our own stuff on top of that, like authentication. I added coffeescript and hamlcoffee support to dieter [2]. HTML emails are templated in mustache.

[1] https://circleci.com [2] https://github.com/edgecase/dieter

Re: Clojure-powered Startups

#32
post #30

There are two ways (and of course, the paths in between) you can run your startup 1 - You can go for the most popular languages: VB.NET, PHP, etc. Very easy to find people, lots of plugins, lots of support. This may be the way to go if you want something simple done in a small budget 2 - You can go for the niche languages: Haskell, Clojure, Go. that's more or less the "hipster hacker" way of doing things. Very diffic…

[deleted]

Your reply seems out of place with the context: as far as I can read, the goal of that phrase was "if you have serious performance issues du to your scale you will be excited by these languages, of which Clojure is in the set".

Re: Clojure-powered Startups

#33

Does it make sense to try using both Clojure and Rails in web app, Rails for UI and Clojure for more sophisticated business logic?

It should interact pretty well with JRuby on Rails, but I'm not sure you would get any benefit from using rails over a Clojure web framework like Noir.

I honestly think you should avoid this. We did this, and it's a nightmare, and we had to get rid of it.

Rails works very well if you stick to defaults. Each time you veer a little bit further from the defaults, things start to break (or at least require a lot more advanced knowledge to keep working).

We had a front-end in in JRuby-on-Rails, backend in clojure, in the same app/process. We had a "middle-end" which translated clojure->ruby and ruby->clojure, allowing us principally to use futures for parallelism and queuing. It worked really well at the start, but had tons of bugs. A nasty example was that we did email in SimpleMailer in Rails, but it was triggered from some backend functions, which in turn were triggered from the front-end. That meant that Ruby objects were being used in two different Ruby runtimes! Bugalicious.

Here's the library we extracted, if you really want to use this: https://github.com/circleci/cljr. My cofounder Allen talked about the experience at ClojureConj/west: https://github.com/arohner/clojurewest2012-slides/blob/maste...

Re: Clojure-powered Startups

#34
post #11

Does it make sense to try using both Clojure and Rails in web app, Rails for UI and Clojure for more sophisticated business logic?

I would say yes if you build the Clojure component as a separate service that the Rails app makes calls to. Or I guess you could simply build it as a Java class and use Rails to execute it.

Definitely. See my comment above about why not to do it in a single process.

Re: Clojure-powered Startups

#35

Does it make sense to try using both Clojure and Rails in web app, Rails for UI and Clojure for more sophisticated business logic?

It should interact pretty well with JRuby on Rails, but I'm not sure you would get any benefit from using rails over a Clojure web framework like Noir.

There is actually another talk from Clojure/West on this topic that will be posted later on...

Re: Clojure-powered Startups

#36
post #5

Hotelicopter also runs on Clojure. And I would recommend Colin Steele's description of his decisions as CTO, as he took the codebase away from PHP, first to Ruby and then to Clojure. The bit about the failures of Ruby are (in my opinion) the most interesting. Basically, it was too much work to get Ruby to go fast enough, and their problems were solved by using Agents in Clojure. This I think is the key bit of the sto…

From this description it seems that Erlang/OTP would be even better choice than Clojure: we literally pack million of concurrect users into 1 high memory AWS instance. Though Erlang not as modern or elegant as Clojure, but there is also LFE and Joxa.

I don't know much about Erlang, can you expand on why you think it'd be a better fit? Is it just memory usage?

Re: Clojure-powered Startups

#37

Hope I'm not hijacking this post, but does is the CLR version of Clojure any good? We have a lot of code in C#/F#/IronPython and am interested in trying some new components in Clojure just for kicks. Is the CLR version have parity with the JVM version? Is it worth using at all?

I don't think it has parity, for all of the reasons halgari noted, but I really don't feel that it offers much over F#, either. F# is a very solid answer to Clojure in all ways except macros: it solves similar problems in the same problem space, doing some things better and some things worse. I happen to have a slight preference for F#, but at any rate, I don't think you're missing anything by being on one or the other.

Re: Clojure-powered Startups

#38
Frankly, the selling point that clojure minimizes risk is not a compelling one. It sounds sexy, but its nonsensical.

Risk encompasses many aspects of technical decisions and there's a complicated set of interactions between these aspects. Saying a single language minimizes risk makes little sense.

For instance, if you're building a straight-up CRUD web app Ruby on Rails minimizes risk best. If you're building a realtime chat service node.js minimizes risk best (and I say this as a longtime detractor of node, its not the best thing engineering wise, but it's an 80% solution).

While I'm glad the speaker enjoyed success using Clojure, I don't think we need a slogan to promote Clojure, we need more killer platforms. We need problem-spaces where when someone asks "What's the highest quality implementation of X?" people say, well, clojure has XYZ, it's way ahead of the pack.

To my mind where clojure hits the sweet spot is in mixing performance with elegance. It's got a fantastic balance there for web apps. I would love for clojure to be the answer to the question of "our app servers are too slow". However, the ecosystem is just not there yet.

Between noir, immutant, aleph, and vert.x I think we have a bright future there, but whether clojure will hit critical mass to become a dominant platform anywhere is nigh impossible to predict.

Re: Clojure-powered Startups

#39
post #16

There are two ways (and of course, the paths in between) you can run your startup 1 - You can go for the most popular languages: VB.NET, PHP, etc. Very easy to find people, lots of plugins, lots of support. This may be the way to go if you want something simple done in a small budget 2 - You can go for the niche languages: Haskell, Clojure, Go. that's more or less the "hipster hacker" way of doing things. Very diffic…

Yup Facebook and Yahoo are PHP. Google/Amazon/eBay/Walmart.com are all primarily a combination of Java and C++.

Facebook uses a combination of primarily PHP(1) (mostly front-end, rendering, some async jobs and scripts) and C++ (mostly back-end services, other bits of high-performance infrastructure, HipHop for PHP), with some Java (especially in the Hadoop, Hive, and similar areas), Python (mostly automation, scripts, infrastructure), and so forth.

From what I understand, Yahoo! has a similar mix of technologies.

In both cases, you really can't say "are PHP".

(1) Modulo some in-house and open source extensions (like XHP) running on HipHop for PHP.

Re: Clojure-powered Startups

#40

Frankly, the selling point that clojure minimizes risk is not a compelling one. It sounds sexy, but its nonsensical. Risk encompasses many aspects of technical decisions and there's a complicated set of interactions between these aspects. Saying a single language minimizes risk makes little sense. For instance, if you're building a straight-up CRUD web app Ruby on Rails minimizes risk best. If you're building a realt…

      if you're building a straight-up CRUD web app Ruby
      on Rails minimizes risk best. If you're building a 
      realtime chat service node.js minimizes risk best
I do not agree with you on this one. I'm not into Node.js precisely because (for now) I consider it to increase the risk of any project.

Yes, your realtime chat will be easy to do with Node.js, but most web applications also need to talk to a database, and also need to do some background processing, and also need to communicate with third-party services through many protocols, sometimes hip, sometimes obscure and long-forgotten. And your app will also probably need at some point a freakishly boring admin filled with freakishly boring reports.

And building a multi-platform, multi-lingual project does lead to resource drainage and duplicate effort. This is one reason why Node.js is popular in the first place, because presumably people can share logic between the client and the server ; but in the larger context of things with Node.js I feel like I'm digging myself into a corner, just like I did with PHP several years ago.

Personally I'm starting to like the JVM more and more. Want to do a really scalable chat app in several lines of code? There's a solution for that [+]. Want to talk with the most obscure database in existence? The JVM can do it. Want to have your binaries work in 10 years from now? The JVM can do it. Want to use your hardware to the maximum? The JVM is the second best choice after C/C++. Want to make your sysops happy? The monitoring/profiling/deployment tools available for the JVM have absolutely no match.

[+] https://github.com/Atmosphere/atmosphere

Post reply on HN