8 ms·

Clojure-powered Startups

139 points by puredanger 14y ago

statictype 14y ago
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?
- edwinnathaniel 14y ago
  Does it worth to write new components using Clojure if you already invested in C#, F#, IronPython?
  - statictype 14y ago
    Probably not. It's more of an exercise in learning Clojure - a language I've heard lots of good things about. I find that I really get a feel for a language only if I'm building something in it that's actually useful (as opposed to just following along with Hello World and Factorial primers).
- halgari 14y ago
  The problem with ClojureCLR is not the platform (that's 100% the same as Clojure on JVM) it's the tooling and lack of libs. So instead of using DataOutputStream, you have to use BinaryOutputStream. Clojure doesn't wrap much, so that means very little code written for one VM runs on the other. Plus you don't have lein, which is a bit problem tooling-wise
- gecko 14y ago
  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.
  - reddit_clone 14y ago
    You are selling an ML variant for someone looking for a lisp variant. Good luck with that!
    - groovy2shoes 14y ago
      "Any sufficiently well-documented Lisp program contains an ML program in its comments." (My Google-Fu is failing me; I can't find an attribution.)
lkrubner 14y ago
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 story: "At this point, we were still focused on using Ruby/Eventmachine as a cornerstone of our technology stack. But here we hit a snag. Yep. I’m gonna beat up Ruby, because it was a mistake. ...it doesn’t scale. ::ducks:: OK, that’s not completely fair. Ruby does scale. But it doesn’t scale well, or easily, and in benchmarking and stress testing, I was seeing that we were going to have a use a small truck load of resources at AWS, or spend a bunch of preciousssss developer time making it scale. It was too expensive. I wanted high user::machine density, and I didn’t want to have my developers do handstands to get it. Yeah, I could’ve done lots of things. I didn’t have time to do that shit. Not with a four person team. Not with cash running out, and promises to keep, and no time to work for Ruby. I needed something that would work for me. This thing had to be FAST. It had to drive hardware to the limit without driving us crazy. The bottom line is that it was too much work to make Ruby go fast enough. ...A little background on our application might help. Our job is to give prospective hotel bookers a view into what their options are. At the time we were making the decision to migrate from Ruby to Clojure, the system was using so-called “realtime” rates and availability checks with hotel suppliers to get that information. That meant that when a visitor conducted a search, we would spin up dozens of individual HTTP requests to hotel supplier sites to get rates and availability data at that very moment. We’d parse the responses, collate them, and present them back to the UI in just a few seconds. You might ask why we didn’t cache that information, but suffice it to say there were significant business drivers for that decision. Managing this concurrent (and long-running) IO was a major theme for us, and Ruby did so reasonably well using EventMachine. However, we had to normalize the returned data into a single unified data model, and none of our partners had simple (or compact) XML representations of the data, so not only did we have IO issues, but CPU-bound processing issues as well. The combination of the two made the EventMachine implementation suffer from less-then-stellar throughput, and because of Ruby’s green threads implementation and global interpreter lock, we had to run oodles of Ruby processes on each box to achieve reasonable throughput. Perhaps just as importantly, the reactor pattern’s upside-down flow of control style of programming was (and is) a pain in the ass. It was hard to read, hard to maintain, and generally obstreperous. ..I can already year you Ruby folks protesting “Fibers!” and so on. Heh. Have fun storming that castle. Clojure was a whole different story, and addressed these issues admirably, for all the reasons you’ll discover when you look into it further. " http://www.colinsteele.org/post/23103789647/against-the-grain-aws-clojure-startup http://www.colinsteele.org/post/23103789647/against-the-grai...
mcav 14y ago
I've hijacked a couple of components at Game Closure in Clojure, much to the chagrin of our CTO. (Just kidding, kinda.) For the places we've used it, Clojure has worked wonderfully. The only disadvantage is that few engineers know it, and few are willing to pick it up because they're afraid of it. But if I were starting a new startup, I'd pick Clojure over anything else, hands-down.
- dbul 14y ago
  The only disadvantage is that few engineers know it, and few are willing to pick it up because they're afraid of it. That's the advantage.
mgl 14y ago
Large junk of Polish startup Fablo (fablo.pl, e-commerce instant search engine based on natural language processing) is written in Clojure [1]. [1] http://jan.rychter.com/blog/2010/7/5/clojure-w-fablo.html http://jan.rychter.com/blog/2010/7/5/clojure-w-fablo.html
- mgl 14y ago
  (nasty) typo: junk = chunk Fablo is actually one of the most interesting startups on the Polish scene regarding technological challenges involved.
playing_colours 14y ago
Does it make sense to try using both Clojure and Rails in web app, Rails for UI and Clojure for more sophisticated business logic?
- Estragon 14y ago
  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.
  - playing_colours 14y ago
    I had a look at it but it's pretty young. I would prefer more mature framework.
    - klaruz 14y ago
      Look at torquebox.org and immutant.org. You can run ruby and clojure on the same JVM and they can interop in a few ways.
    - michaelsbradley 14y ago
      It's possible to get quit a lot accomplished by loosely coupling Ring+Compojure, Enlive/Hiccup, and datastore modules like Clutch, Korma, clj-orient, etc. I began my journey into Clojure about a month ago (after poking at it since last Sept) by diving into the "Clojure Programming" book recently published by O'Reilly. After finishing the book, I reached for Noir to fill my web-dev needs, as the idea of a "batteries included" framework appealed to me. But I ended up dropping Noir and adopting the approach explained in the book, i.e. loosely coupling the modules mentioned above. Noir itself is built from some of those same modules, and it seems like a fine open source project, but I've found that I'm better off connecting the "lego blocks" together manually -- it's not a complex exercise and gives you a lot of freedom to experiment, learn and fine tune.
  - astine 14y ago
    I've used Rails and Noir and they're not really comparable. Noir is much more minimalist and doesn't cover nearly the same ground as Rails. Noir is more like Sinatra as I understand it. The Clojure mentality so far has eschewed all encompassing frameworks like Rails in favor of smaller interfitting libraries anyway.
raverbashing 14y ago
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 difficult to find someone that can do even a Hello World, but once you find, they can write a scalable website in about 3 lines and connect to the newest nosql db in 2 lines more. This is good if you're the next twitter, fb, etc and your servers begin to melt even if serving login (but then again, fb is in PHP and they added 'magic' in HipHop and infrastructure)
- scylla 14y ago
  Yup Facebook and Yahoo are PHP. Google/Amazon/eBay/Walmart.com are all primarily a combination of Java and C++.
  - Xcelerate 14y ago
    Although Facebook uses Erlang for chat.
    - simonb 14y ago
      ... and Haskell for programmatically manipulating said PHP code base. [http://www.haskell.org/haskellwiki/Haskell_in_industry http://www.haskell.org/haskellwiki/Haskell_in_industry]
  - nbm 14y ago
    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.
samrat 14y ago
Am I the only one who finds the InfoQ website too cluttered. I'd much rather watch this on Youtube.
pivo 14y ago
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 they think is a good solution?
- spacemanaki 14y ago
  > 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. Check out Enlive, it solves exactly this problem. HTML/CSS is separate from Clojure code and you fill out templates and stuff via CSS style selectors. It's sweet. https://github.com/swannodette/enlive-tutorial https://github.com/swannodette/enlive-tutorial https://github.com/cgrand/enlive https://github.com/cgrand/enlive Btw I think you can use Enlive with Noir, even though some of the examples from Noir use Hiccup, it's not a requirement.
  - nmcfarl 14y ago
    That tutorial is truly excellent - I’ve been looking for something to replace Hiccup, and this looks to be it!
- tensor 14y ago
  I prefer Enlive: https://github.com/cgrand/enlive https://github.com/cgrand/enlive
- pbiggar 14y ago
  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 https://circleci.com [2] https://github.com/edgecase/dieter https://github.com/edgecase/dieter
- 14y ago
andrewvc 14y ago
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.
- bad_user 14y ago
  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 https://github.com/Atmosphere/atmosphere
fmw 14y ago
Here is a shameless plug: http://www.vixu.com http://www.vixu.com (my startup) is based on open source Clojure/ClojureScript CMS (and soon webshop) software. See https://github.com/fmw/vix https://github.com/fmw/vix for the code (planning some refactoring over the summer before the first official release). Also doing search related stuff in Clojure (see https://github.com/fmw/alida https://github.com/fmw/alida for demo code I wrote for my EuroClojure presentation). Clojure brought the fun back to software development for me and made me a better developer in general. It is also a very pragmatic choice, with the expressiveness of Lisp and plenty of reusable Java code being available.
Estragon 14y ago
That was embarassing, and 20 minutes of my life I regret losing. Even the speaker appeared to be embarassed at times. It's interesting that this thread has stayed on the front page of HN all day. I wonder how many people upvoted/participated in it without watching it? (I must admit, I participated without watching the whole thing.)
- batista 14y ago
  Noticed how your comment doesn't mention any actual complaints with the presentation?
  - Estragon 14y ago
    It was vacuous, basically an extended resume for the presenter, mixed with empty platitudes about principles for clojure evangelism. And worst of all in terms of wasting my time, it was misrepresented. It comes across in the blurb as a talk about the contexts in which Clojure has been useful to startups, and the presenter represents it this way in the introduction, when instead it's "here are these vague descriptions of how I effectively evangelised Clojure in each of these startup companies."
Ygg2 14y ago
I believe the data is deceptive. Growth is fine and dandy but if you look at this graph http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&l=(Absolute) http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&#... Tells a wholly different story than this one: http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&l=&relative=1(Relative http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&#... Also didn't reddit switch from clojure/lisp-like language to python?
- runevault 14y ago
  They switched from common lisp to python, which is an entirely different beast. CLisp is an awesome language, and obviously has the same roots in McCarthy's work, but they have different advantages/disadvantages (the library situation is better on the JVM, for example).

139 points by puredanger 14y ago

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?

edwinnathaniel 14y ago
Does it worth to write new components using Clojure if you already invested in C#, F#, IronPython?
- statictype 14y ago
  Probably not. It's more of an exercise in learning Clojure - a language I've heard lots of good things about. I find that I really get a feel for a language only if I'm building something in it that's actually useful (as opposed to just following along with Hello World and Factorial primers).
halgari 14y ago
The problem with ClojureCLR is not the platform (that's 100% the same as Clojure on JVM) it's the tooling and lack of libs. So instead of using DataOutputStream, you have to use BinaryOutputStream. Clojure doesn't wrap much, so that means very little code written for one VM runs on the other. Plus you don't have lein, which is a bit problem tooling-wise
gecko 14y ago
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.
- reddit_clone 14y ago
  You are selling an ML variant for someone looking for a lisp variant. Good luck with that!
  - groovy2shoes 14y ago
    "Any sufficiently well-documented Lisp program contains an ML program in its comments." (My Google-Fu is failing me; I can't find an attribution.)

lkrubner 14y ago

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 story: "At this point, we were still focused on using Ruby/Eventmachine as a cornerstone of our technology stack. But here we hit a snag. Yep. I’m gonna beat up Ruby, because it was a mistake. ...it doesn’t scale. ::ducks:: OK, that’s not completely fair. Ruby does scale. But it doesn’t scale well, or easily, and in benchmarking and stress testing, I was seeing that we were going to have a use a small truck load of resources at AWS, or spend a bunch of preciousssss developer time making it scale. It was too expensive. I wanted high user::machine density, and I didn’t want to have my developers do handstands to get it. Yeah, I could’ve done lots of things. I didn’t have time to do that shit. Not with a four person team. Not with cash running out, and promises to keep, and no time to work for Ruby. I needed something that would work for me. This thing had to be FAST. It had to drive hardware to the limit without driving us crazy. The bottom line is that it was too much work to make Ruby go fast enough. ...A little background on our application might help. Our job is to give prospective hotel bookers a view into what their options are. At the time we were making the decision to migrate from Ruby to Clojure, the system was using so-called “realtime” rates and availability checks with hotel suppliers to get that information. That meant that when a visitor conducted a search, we would spin up dozens of individual HTTP requests to hotel supplier sites to get rates and availability data at that very moment. We’d parse the responses, collate them, and present them back to the UI in just a few seconds. You might ask why we didn’t cache that information, but suffice it to say there were significant business drivers for that decision. Managing this concurrent (and long-running) IO was a major theme for us, and Ruby did so reasonably well using EventMachine. However, we had to normalize the returned data into a single unified data model, and none of our partners had simple (or compact) XML representations of the data, so not only did we have IO issues, but CPU-bound processing issues as well. The combination of the two made the EventMachine implementation suffer from less-then-stellar throughput, and because of Ruby’s green threads implementation and global interpreter lock, we had to run oodles of Ruby processes on each box to achieve reasonable throughput. Perhaps just as importantly, the reactor pattern’s upside-down flow of control style of programming was (and is) a pain in the ass. It was hard to read, hard to maintain, and generally obstreperous. ..I can already year you Ruby folks protesting “Fibers!” and so on. Heh. Have fun storming that castle. Clojure was a whole different story, and addressed these issues admirably, for all the reasons you’ll discover when you look into it further. " http://www.colinsteele.org/post/23103789647/against-the-grain-aws-clojure-startup http://www.colinsteele.org/post/23103789647/against-the-grai...

mcav 14y ago

I've hijacked a couple of components at Game Closure in Clojure, much to the chagrin of our CTO. (Just kidding, kinda.) For the places we've used it, Clojure has worked wonderfully. The only disadvantage is that few engineers know it, and few are willing to pick it up because they're afraid of it. But if I were starting a new startup, I'd pick Clojure over anything else, hands-down.

dbul 14y ago
The only disadvantage is that few engineers know it, and few are willing to pick it up because they're afraid of it. That's the advantage.

mgl 14y ago

Large junk of Polish startup Fablo (fablo.pl, e-commerce instant search engine based on natural language processing) is written in Clojure [1]. [1] http://jan.rychter.com/blog/2010/7/5/clojure-w-fablo.html http://jan.rychter.com/blog/2010/7/5/clojure-w-fablo.html

mgl 14y ago
(nasty) typo: junk = chunk Fablo is actually one of the most interesting startups on the Polish scene regarding technological challenges involved.

playing_colours 14y ago

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

Estragon 14y ago
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.
- playing_colours 14y ago
  I had a look at it but it's pretty young. I would prefer more mature framework.
  - klaruz 14y ago
    Look at torquebox.org and immutant.org. You can run ruby and clojure on the same JVM and they can interop in a few ways.
  - michaelsbradley 14y ago
    It's possible to get quit a lot accomplished by loosely coupling Ring+Compojure, Enlive/Hiccup, and datastore modules like Clutch, Korma, clj-orient, etc. I began my journey into Clojure about a month ago (after poking at it since last Sept) by diving into the "Clojure Programming" book recently published by O'Reilly. After finishing the book, I reached for Noir to fill my web-dev needs, as the idea of a "batteries included" framework appealed to me. But I ended up dropping Noir and adopting the approach explained in the book, i.e. loosely coupling the modules mentioned above. Noir itself is built from some of those same modules, and it seems like a fine open source project, but I've found that I'm better off connecting the "lego blocks" together manually -- it's not a complex exercise and gives you a lot of freedom to experiment, learn and fine tune.
- astine 14y ago
  I've used Rails and Noir and they're not really comparable. Noir is much more minimalist and doesn't cover nearly the same ground as Rails. Noir is more like Sinatra as I understand it. The Clojure mentality so far has eschewed all encompassing frameworks like Rails in favor of smaller interfitting libraries anyway.

raverbashing 14y ago

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 difficult to find someone that can do even a Hello World, but once you find, they can write a scalable website in about 3 lines and connect to the newest nosql db in 2 lines more. This is good if you're the next twitter, fb, etc and your servers begin to melt even if serving login (but then again, fb is in PHP and they added 'magic' in HipHop and infrastructure)

scylla 14y ago
Yup Facebook and Yahoo are PHP. Google/Amazon/eBay/Walmart.com are all primarily a combination of Java and C++.
- Xcelerate 14y ago
  Although Facebook uses Erlang for chat.
  - simonb 14y ago
    ... and Haskell for programmatically manipulating said PHP code base. [http://www.haskell.org/haskellwiki/Haskell_in_industry http://www.haskell.org/haskellwiki/Haskell_in_industry]
- nbm 14y ago
  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.

samrat 14y ago

Am I the only one who finds the InfoQ website too cluttered. I'd much rather watch this on Youtube.

pivo 14y ago

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 they think is a good solution?

spacemanaki 14y ago
> 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. Check out Enlive, it solves exactly this problem. HTML/CSS is separate from Clojure code and you fill out templates and stuff via CSS style selectors. It's sweet. https://github.com/swannodette/enlive-tutorial https://github.com/swannodette/enlive-tutorial https://github.com/cgrand/enlive https://github.com/cgrand/enlive Btw I think you can use Enlive with Noir, even though some of the examples from Noir use Hiccup, it's not a requirement.
- nmcfarl 14y ago
  That tutorial is truly excellent - I’ve been looking for something to replace Hiccup, and this looks to be it!
tensor 14y ago
I prefer Enlive: https://github.com/cgrand/enlive https://github.com/cgrand/enlive
pbiggar 14y ago
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 https://circleci.com [2] https://github.com/edgecase/dieter https://github.com/edgecase/dieter
14y ago

andrewvc 14y ago

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.

bad_user 14y ago
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 https://github.com/Atmosphere/atmosphere

fmw 14y ago

Here is a shameless plug: http://www.vixu.com http://www.vixu.com (my startup) is based on open source Clojure/ClojureScript CMS (and soon webshop) software. See https://github.com/fmw/vix https://github.com/fmw/vix for the code (planning some refactoring over the summer before the first official release). Also doing search related stuff in Clojure (see https://github.com/fmw/alida https://github.com/fmw/alida for demo code I wrote for my EuroClojure presentation). Clojure brought the fun back to software development for me and made me a better developer in general. It is also a very pragmatic choice, with the expressiveness of Lisp and plenty of reusable Java code being available.

Estragon 14y ago

That was embarassing, and 20 minutes of my life I regret losing. Even the speaker appeared to be embarassed at times. It's interesting that this thread has stayed on the front page of HN all day. I wonder how many people upvoted/participated in it without watching it? (I must admit, I participated without watching the whole thing.)

batista 14y ago
Noticed how your comment doesn't mention any actual complaints with the presentation?
- Estragon 14y ago
  It was vacuous, basically an extended resume for the presenter, mixed with empty platitudes about principles for clojure evangelism. And worst of all in terms of wasting my time, it was misrepresented. It comes across in the blurb as a talk about the contexts in which Clojure has been useful to startups, and the presenter represents it this way in the introduction, when instead it's "here are these vague descriptions of how I effectively evangelised Clojure in each of these startup companies."

Ygg2 14y ago

I believe the data is deceptive. Growth is fine and dandy but if you look at this graph http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&l=(Absolute) http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&#... Tells a wholly different story than this one: http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&l=&relative=1(Relative http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&#... Also didn't reddit switch from clojure/lisp-like language to python?

runevault 14y ago
They switched from common lisp to python, which is an entirely different beast. CLisp is an awesome language, and obviously has the same roots in McCarthy's work, but they have different advantages/disadvantages (the library situation is better on the JVM, for example).