HN Theater @HNTheaterMonth

Somehow I get the feeling that the Clojure community is in the "marketing" phase of the language. I'm starting to see many Clojure threads popping up HN lately.

InfoQ.com also increasingly added Clojure presentations/articles lately.

It's all good, a little bit of competition between languages is healthy. Having said that, I believe it is hard for Clojure community to convert/invite people with what you guys have done so far because there has been no killer apps/tools so far.

Is this largely because of the LISP is such a weird language that it is a lot harder to convince people to use it? Like it's almost "you need to use it for a few years to know the power of it" (otherwise it'll be like a weird version of Rails or some MVC framework).

Here's a few examples that, in my mind, are not strong enough to convince people to use Clojure:

http://www.infoq.com/presentations/Clojure-in-the-Clouds

http://www.infoq.com/presentations/Clojure-powered-Startups

When people look at Rails demos, they immediately have a feeling of how easy it is to develop web-application supported by _good practices_ (test automation, migration, MVC, etc).

When people look at VB.NET/C# WinForms demo, they know it's super easy to write GUI apps.

When people look at Python... well they knew Python was one of the best languages to write scripts/tools in UNIX/Linux environment, and to some degree, GUI apps in *NIX.

Clojure? only people who dreamed of using LISP (and know LISP already).

No offense to Clojure people, but it's just not convincing enough...

⬐ cemerick

Some of us have been "marketing" Clojure for a number of years now. :-)

The results from the last two years of the survey (e.g. 2011's are here: http://cemerick.com/2011/07/11/results-of-the-2011-state-of-...) might be illuminating for you.

Clojure has a ton of compelling use cases, but it's stubbornly not going to fit into the shoebox of a single domain. Thus, it's going to be hard to say, "Clojure is great because it allows me to address narrow problem X". It's a general-purpose language, and increasingly, a multiplatform/multienvironment one as well.

Also, only ~7% of the respondents to last year's survey came from a Lisp. Most come from Java, Ruby, or Python. Make of that what you will re: Clojure's "weirdness".

⬐ katox

Really nice summary, Chas ;). I hope I haven't spoiled the statistics by filling in "just started" - the same response as the last year.

I guess some of us are start over all the time. But at least this time I've read through a half of Clojure in Action and going through 4clojure exercises to "finally get started".

This time using instarepl by Chris instead of LaClojure or Emacs/Slime (where just a tiny subset works for me).

And it's fun! If only errors were not such a drag. I guess complains from 2011 will repeat on those...

⬐ BadassFractal

On a sidenote, really enjoying your book so far, Chas. I'm really liking the chapter breakdown and sections like the practicums.

⬐ edwinnathaniel

Yes Chas, you're definitely no stranger in the Clojure community :) (I watched your O'reilly webcast btw).

I'm not saying that Clojure should address a narrow problem but if we look back at the history of Java, it offers a few "real" improvement over C++ such as garbage collection, nice standard library, and the promise of WORA (albeit lots of hiccups here and there). By real I mean something that people can see and immediately take advantage of.

I'm sure there are always going to be alpha-nerds who love to try new programming languages out there (especially the hip ones) but when these people are to write Clojure code or to build Clojure tools, they tend to bring their old habit from the previous language, which in turns make their code look like the previous language as opposed to something totally new, probably refreshing, or even have the potential to blow people's mind.

⬐ cemerick

(If you watched the O'Reilly live webcast, then give this a try: http://cemerick.com/2012/05/02/starting-clojure/)

Riffing on what technomancy said nearby, a lot of the issues that Clojure addresses are so taken for granted in most of the broader software development world, that it can be challenging to wrap up its benefits into a tasty, easily digestable nugget comparable to "Java gets rid of malloc and pointers" (sorta). Some have taken some whacks at doing just this, including Paul DeGrandis' talk you linked to already, as well as "Neal Ford's master plan for Clojure enterprise mindshare domination": http://blip.tv/clojure/neal-ford-neal-s-master-plan-for-cloj...

That said, the benefits of immutability and pure functions are generally obvious to any reasonably-capable programmer (my personal bias shone forth) given 10 minutes in front of a whiteboard. Can we get the, say, 10 million Java developers to sit still long enough for that? No, probably not. Maybe a tenth of them eventually, maybe. And, if a bunch of them head over to Scala because they like the look of {{{}}} instead of ((())), so be it.

A more interesting question to me lately is, what is the objective of language evangelism? Let's set aside any notion that Clojure will be "the next Java", or even achieve the same penetration as Python or Ruby. For those of us that use the language, none of those goals are particularly important. "How many developers use language X" used to be a critical question when the language you used largely delimited the reach of your eventual application/system/whatever; that is hardly the case anymore. I can write my server side in literally anything, and transpiling to JavaScript or C for client side as necessary is either within reach, or a solved problem depending on your preferred language.

So, what should be the objective? Having a large enough pool of talent to meet business objectives is the only thing I can think of that is an actual potential blocker. I know lots of people that know Clojure that would like to work in Clojure, and there are more people like that every day. Seems like the vector is trending positive; we only need to make sure it stays that way.

(This leaves out the enterprise guys to a certain degree, but that's largely due only to their [and their managers'] self-inflicted risk profile.)

Finally, I leave you with this:

http://www.indeed.com/jobanalytics/jobtrends?q=clojure%2Chas...

Note that those are absolute trendlines, not growth. You can very reasonably say that Clojure is the most in-demand functional programming language. (…for some definition of 'functional programming language' ;-)

⬐ plinkplonk

"if a bunch of them head over to Scala because they like the look of {{{}}} instead of ((())), so be it"

Unnecessary (if slight) nastiness directed towards (developers choosing) Scala. Unworthy of you (imo). There are significant differences between Scala and Clojure (other than {} vs ()) and trivializing a valid choice of one over another by ascribing it to fear of parantheses (or whatever) isn't a particularly compelling argument.

I've never really noticed Scala devs (leave alone book authors!) throwing darts at Clojure, but have seen the reverse (and at Haskell, on the Clojure mailing list but Rich Hickey shut that down hard and fast, good for him). Sad, and unnecessary (imo).

Scala and Clojure are both awesome and (totally imo) evangelizers of both languages should realize we are all on the same side (again totally imo, feel free to ignore).

Yes there are trolls in all language communities, but I think the expectations about the top developers in each community are (and should be) much higher.

Otherwise, solid comment. And hey, your book is awesome.

⬐ tom_b

I can't help but respond:

http://www.indeed.com/jobtrends?q=java%2Cclojure%2Chaskell%2...

Having any "most in-demand functional programming language" seems to be a bit silly. In the larger view, there simply isn't any demand.

I REALLY want this to change. I think if Clojure can make some inroads to the enterprise, there will be trickle-down effect that will help increase opportunities to work in Clojure. I think increasing working opportunities is what language evangelism is for.

As a hacker who loves the repl, functional programming, weird languages, and was at the first Clojure/conj, it is not clear to me at all that immutability and pure functions are wins in general - lots of excellent working systems are out there that don't bother using this stuff at all (no silver bullet is kind of what I am driving at). I might instead argue that in the hands of good-to-great hackers, that immutability and pure functions offer some benefits that are hard to quantify when you normalize across raw hacker abilities.

PS - Thanks so much for the book. A large part of Clojure's success is directly attributable to the high quality and number of books that have popped up so soon in its life as a programming language.

⬐ cemerick

In truth, I hate these Indeed charts…but then, I started it, eh? Live by the sword and all that.

Some additional perspective: http://www.indeed.com/jobtrends?q=java%2Cruby%2Cpython%2C%22...

The Java market is massive. Nearly everything else is essentially background noise compared to it. I'm skeptical that any single language will ever have the same reach as it.

Runtimes, on the other hand, are a different story. The JVM, standardized JavaScript engines, even the CLR/Mono to some extent: polyglot sandboxes where you have the leverage to use whatever language will get the job done. That's a huge win for, as you put it, good-to-great hackers, trying to find the edge of what's next.

'course, that's a wash to a loss (i.e. increased risk) for those with the enterprise mindset. Thus, Java 8 with its closures may very well consolidate its position in such environments.

Glad you enjoyed the book, BTW. :-)

⬐ tom_b

TPS reports rule (I know it's really below the belt) . . .

http://www.indeed.com/jobtrends?q=sql%2Cjava&l=

I had not thought deeply about runtimes in relation to this question. It's certainly true that one reason I can hack around in Clojure and count on that code running on our production servers is that the JVM is ubiquitous there. Quite a different story than when I was doing some stuff in SBCL and had to compile it in my user space.

⬐ technomancy

> if we look back at the history of Java, it offers a few "real" improvement over C++ such as garbage collection

Perhaps the problem is that it's hard to explain referential transparency, or that the problems caused by the lack of referential transparency are less obvious than those caused by the lack of GC. I mean, I've never heard of someone reading through "Out of the Tarpit" and then saying, "why bother with something like Clojure?"

⬐ espeed

Clojure's killer app is managing complexity. This allows you to keep your mental stack clean.

With OO, you have to keep track of the state of each object and how each method affects that state. With Clojure, you don't need to be concerned with the guts of a function, just the inputs and outputs. This keeps your mental stack from building up and makes programs easier to understand and debug.

⬐ edwinnathaniel

Perhaps I have not pushed OO to the limit but for the most day-to-day tasks I've ever done, OO state is hardly the issue unless you have to write a paper or explain something via state-machine or whatnot.

Request -> App Server -> Processing -> Response -> End, no state lingering around...

I do understand what you're saying but I believe the era of complex OO with states is declining, at least at web-development level...

⬐ stcredzero

> Clojure's killer app is managing complexity. This allows you to keep your mental stack clean.

There's a big PR problem with environments that have this as a core strength: it's very hard to demonstrate this without a lot of involvement. It's very hard to demonstrate this with a "hello world." sized experience.

⬐ andrewvc

I strongly disagree with that slogan re: complexity.

Complexity covers so much, its definition so sprawling, that the phrase has no meaning.

I'd rather focus on the language's real strength, fast, concurrenty, portable computation in very well tooled managed environment with a large number of quality libraries.

I don't want to get into a situation where people think that clojure is the universally 'best' language, which is were certain people in the community are.

That POV horribly damaged ruby's popularity after Rails' rise, and I'd hate to see it happen again to another language.

⬐ espeed

Rich Hickey has gone to great lengths to define simplicity and complexity (http://www.infoq.com/presentations/Simple-Made-Easy), and the paper "Out of the Tar Pit" (http://shaffner.us/cs/papers/tarpit.pdf) goes further.

Software projects are becoming increasingly complex, and multicore concurrency is becoming increasingly important. Immutability and referential transparency are key ingredients in Clojure concurrency so I think the slogan is apt.

⬐ chc

It damaged Ruby's popularity? You feel Ruby hasn't been popular enough the past few years?

⬐ andrewvc

While Rails has been a massive success the ruby language hasn't been particularly popular much beyond that.

I'd say python has a more even distribution in terms of use in varied fields for instance.

⬐ gringomorcego

Dude: FUCK YOU

If the Lisp people were smart enough to pander their shit properly, things wouldn't be so damn bad.

Honestly, I'm up for people claiming it cures cancer or whatever. We need competition in languages. We need people to ask questions. But most of all, we need people to be happy with change. If you aren't willing to change your tools, you are going to live a limited and boring life.

⬐ lukev

I disagree; it's very important to talk about complexity. Otherwise, we can't minimize it, and however you define it, it is a problem in software.

You're right, though, the definition is sprawling, so I think it makes sense to use smaller more precise words. The good news is we have some of these: Referential transparency, pure functions, immutability, and neologisms such as "complection". These are very useful, meaningful terms.

⬐ lukev

It's true that Clojure is "weird" because it's a different paradigm. It's not just a different language like Ruby was, it's a different family of languages. It's going to be strange if you aren't already familiar with Lisps and/or functional programming.

To some extent, I don't think any "killer app" is going to change that, although it certainly wouldn't hurt. The concurrency features are pretty compelling in that space already.

Clojure's primary appeal is not, and cannot be, that it's easy for most programmers out there right now. The appeal is that once you learn it, it's a better general purpose programming language that runs on the JVM.

⬐ edwinnathaniel

Yes, that seems to be the case: "you need to learn it to believe it". And I hope people take their time to learn it because there seems to be a few articles out there with the message of "I picked up Clojure in a few weeks and re-wrote critical piece of my software in 2 days and it works super-scale".

Maybe that's the power of Clojure?

I really think that it will take a few years before a select few (persistent users, not alpha-geeks) from the Clojure community can come up with some sort of breakthrough that replaces today's best practices, whether it is the replacement of the whole OOP/*DD-movement or the way testing is done, or something else, I don't know. But I do believe that this is what needed.

⬐ lukev

It's mostly a mental barrier. Clojure isn't inherently hard, at all, it's just different. Once you get the hang of it, you can start reaping the benefits fairly quickly.

Unfortunately, most people judge difficulty in terms of familiarity, so the strangeness is off-putting even if it wouldn't be that hard for them to learn.

⬐ mark_l_watson

Hello Edwin, Clojure appeals to people: who enjoy a Lisp dev style with bottom up repl coding, who need to be on the JVM, and who like some of the neat features of the language (universal seq APIs for collections, mostly immutable data, etc.) BTW, there are some amazing projects built on Clojure - choose an application domain you are interested in and try searching for that domain + clojure

⬐ edwinnathaniel

Hi Mark, I'm interested to see Clojure in the LoB type of application. Yes, LoB is boring, but I'd like to see some comparison between the model-heavy/oop-heavy vs Clojure.

Would be nice if the apps show internationalization and some way to handle Time and Money.

⬐ rabidsnail

Time and Money are handled exactly the same as in Java.

⬐ edwinnathaniel

As in using Joda-Time, Joda-Money (or JDK Money)?

Would there be any other way to represent them in Clojure? (i.e.: the more Clojure-way as opposed to use JDK classes?)

⬐ technomancy

Joda Time is actually a great example of a library letting you work in terms of values instead of the mutable object disaster that is java.util.Date; it just happens to be implemented in Java itself.

If you can imagine the same benefits of working with stable values applied across the board to all your built-in data structures, that might help.

⬐ edwinnathaniel

Is mixing Java classes in Clojure okay? or to some degree it is acceptable but there are gotchas or the do's and don'ts?

Hey, I checked your website just for fun and it says there you can speak Indonesian, awesome :).

⬐ technomancy

Operating directly on Java classes is pretty standard. Of course you have to be very careful when working with classes which allow mutability, (true in all languages, really) but with Joda that's not an issue.

The only thing you miss out on is that Java methods can't be used as higher-order functions.

My Indonesian is pretty rusty; I should probably update it to say that I understand it rather than speak it. =)

⬐ dusklight

I personally think how clojure has been presented so far is its greatest strength and it is the reason why it is so strong so far and why it continues to get stronger. You have to be a better than average programmer, one who has worked with multiple languages from multiple paradigms, who has worked with real production code before, to recognize why it is so much superior to any other programming language currently available right now.

I'm GLAD that there is currently no killer app for Clojure, like how Rails became the killer app for Ruby. IMO Rails killed Ruby. Ruby started out in the right direction but once Rails became popular there was an influx of so-so programmers who started polluting the language with inefficient concepts, constantly reinventing the wheel poorly because they did not know enough computer science to know that a better solution had already been invented. Now the system has been bogged down by so much cruft, it is difficult to see if it still serves the purpose it was originally designed for (a language the people can enjoy programming in).

Clojure is not ready yet. The core team is still working on refining the fundamentals for what maybe can become the 100 year language [http://paulgraham.com/hundred.html] -- look at reducers in 1.4. Right now Clojure doesn't need more people. It needs more smart people. If you are not smart enough to understand why it is worth switching to it, maybe you should wait a bit and let the design mature more. The killer apps will come. Clojure's ability to scale complexity will eventually overcome its current drawbacks, as the tools and the ecosystem matures.

⬐ fmw

Here is a shameless plug:

http://www.vixu.com (my startup) is based on open source Clojure/ClojureScript CMS (and soon webshop) software. See 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 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.

⬐ raverbashing

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)

⬐ None

None

⬐ saurik

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".

⬐ scylla

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

⬐ Xcelerate

Although Facebook uses Erlang for chat.

⬐ simonb

... and Haskell for programmatically manipulating said PHP code base. [http://www.haskell.org/haskellwiki/Haskell_in_industry]

⬐ nbm

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.

⬐ mcav

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

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

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

⬐ mgl

(nasty) typo: junk = chunk

Fablo is actually one of the most interesting startups on the Polish scene regarding technological challenges involved.

⬐ statictype

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?

⬐ gecko

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

You are selling an ML variant for someone looking for a lisp variant. Good luck with that!

⬐ groovy2shoes

"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.)

⬐ edwinnathaniel

Does it worth to write new components using Clojure if you already invested in C#, F#, IronPython?

⬐ statictype

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

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

⬐ pivo

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?

⬐ pbiggar

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

⬐ Rayne

I'm a fan of mustache. There is an excellent implementation for Clojure: https://github.com/davidsantiago/stencil

⬐ tensor

I prefer Enlive: https://github.com/cgrand/enlive

⬐ elrodeo

I'm using hiccup for HTML.

Here I gave an overview of my experiment in building a web app entirely in Clojure: http://notehub.org/2012/6/16/how-notehub-is-built

⬐ spacemanaki

> 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/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

That tutorial is truly excellent - I’ve been looking for something to replace Hiccup, and this looks to be it!

⬐ lkrubner

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-grai...

⬐ pjmlp

This is not new.

The default implementations of scripting languages do not scale, unless we making use of the advanced VMs or JIT techniques of alternative implementations.

A startup I was part of, made this discovery already back in 2002, when we moved our scripting based web framework, which was very much like Rails, but based on Apache/TCL, to the then early .NET beta.

⬐ nivertech

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.

⬐ cgag

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?

⬐ ConstantineXVI

Noticing that languages built on the Erlang VM seem to be more along the lines of "an X-like on the Erlang VM" instead of "X on the Erlang VM" (like JRuby, IronPython, ClojureScript). Is Erlang's VM less adaptable to existing languages vs. the JVM, etc.?

⬐ chc

That's part of it, but it's also just that there's little motivation for using it as a general-purpose VM. Building a precise clone of Python on the Erlang VM would be more difficult than on JVM, but more importantly, it would be pointless — Python does not have the kind of deep-rooted concurrency semantics that are Erlang's raison d'etre. If you try to stick an existing language that doesn't closely resemble Erlang on the Erlang VM, all you're doing is creating a really awkward implementation of that language and not really gaining anything. So you end up with languages that are similar to X but with a huge transfusion of Erlang's semantics so that they're useful.

⬐ jwr

It depends on how many external libraries you need. We considered both Clojure and Erlang in our project, ended up going with Clojure mostly because of available and easily accessible Java libraries.

I still find it amazing that I can:

1) add a single line to my project.clj (which will set up dependencies and download libs),

2) add a single line to my :import section at the top of the source file,

3) there is no point 3. Just call Java libraries.

But the choice really depends on your application.

⬐ edwinnathaniel

Leiningen probably has its root from Maven, which IMHO the killer tool for Java. I've done .NET, a bit of Python, and RoR development/toying/experimentation in the past, and you need Bundler+Rake+RubyGem (at least) to emulate the core (important) feature of Maven.

⬐ samrat

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

⬐ playing_colours

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

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.

⬐ astine

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.

⬐ puredanger

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

⬐ playing_colours

I had a look at it but it's pretty young. I would prefer more mature framework.

⬐ klaruz

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

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.

⬐ pbiggar

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...

⬐ None

None

⬐ Estragon

Thanks for the correction, good to know. In the example you describe, the main mismatch seems to have been getting the two Ruby runtimes to communicate effectively. Was that a common theme?

⬐ pbiggar

I think the most important thing is "complexity is multiplicative". Every slight deviation from normal led to subtle errors that took days to fix, and kept coming back in different ways. The runtimes was just the most WTF way this happened.

⬐ notb

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.

⬐ playing_colours

Yeah I am interested in the scenario with using Clojure-written web services.

⬐ TheSmoke

this is what twitter is doing with scala i believe.

⬐ pbiggar

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

⬐ technomancy

This is actually a fairly common choice for startups, the "deployment mullet". Business up front, party on the back end.

⬐ Ygg2

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&#... Tells a wholly different story than this one: http://www.indeed.com/jobtrends?q=clojure%2C+scala%2C+java&#...

Also didn't reddit switch from clojure/lisp-like language to python?

⬐ runevault

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).

⬐ Estragon

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

Noticed how your comment doesn't mention any actual complaints with the presentation?

⬐ Estragon

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."

⬐ andrewvc

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.

⬐ espeed

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.

Datomic (http://www.infoq.com/presentations/The-Design-of-Datomic) is going to be one of Clojure's killer apps -- it adds durability to Clojure's immutable, persistent data structures, and it rethinks datastore design, from the ground up, to take advantage of modern storage services.

⬐ Estragon

Datomic is super cool design-wise. It'd be great to see some apps actually using it.

⬐ bad_user

      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

⬐ mgkimsal

I'm probably too cynical, but I think a big reason for node's popularity these days is the same as it was for rails 5-6 years ago - greenfield projects.

If I'm doing node now, it's not maintaining some legacy crap from 5 years ago - it's straight up new development. I get to do what I want. I don't think that factor comes in to the equation enough when people are talking about efficiencies and productivity metrics and such.

I still do a fair amount of PHP - my productivity maintaining PHP apps written by other people 5-10 years ago is pretty different from PHP I write from scratch, getting to use modern tools/libraries/techniques.

Yes, atmosphere is pretty cool - I'm looking at adding it to a project this fall. grails install-plugin atmosphere ;)