Hacker News Reader

Comment by hopeless | Hacker News Reader

LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! While they might be interesting languages (particularly Elixir) I don't see any 10x advantages their web stacks have over Rails for the typical "majestic monolith" use case.

Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads. We won't know until some ActionCable code is released but it sure didn't look complicated.

It does seem odd that -api takes years to get in, but ActionCable gets a go-straight-to-core pass without any community review first. It certainly seems like a weakness in the process, which should be addressed, although I'd agree with the eventual result & priorities. -api probably isn't something I'd ever use: even if I eventually created an API-only app, I'd probably have started from a regular Rails app and gradually optimised things out.

Edited to add: I'm actually quite bullish on TurboLinks 3 if it can help me to avoid ever having to write a Javascript MVC app again. It's not so much that these apps are hard to write, it's that they're freaking hard to debug, particularly in the hands of users.

View on HN

> the idea that every Rails programmer will be switching to Clojure or Elixir! [...] I don't see any 10x advantages [...]

I do. While I cannot speak for Clojure and Elixir, I can speak for Haskell, which I have moved to from Rails.

10x for me is:

1. A 70MB all-in binary to deploy, using 1-3MB of memory when running (has a build in HTTP(S) server), responding in 2-10ms to my requests. Compare that to 700-1500MB of gems, using hundreds of MB while running, serving requests in 50-200ms... More then 10x! And my framework of choice (Yesod) consists of 23kLOC, where Rails has 210kLOC (source: openhub.net)... Another 10x!

2. Less bugs when growing the codebase; "strong compile time guarantees" is now my main weapon when fighting maintenance curve.

Back in my Rails days I'd say "typing is a very narrow form of automated testing", which given my exposure to C++/Java was defendable opinion.

Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time.

TL;DR: I believe 10x frameworks are out there.

But isn't that like saying a healthy person can run 10x faster than someone with a limp?

For context, my background has been predominantly in a dynamic language, but now I've drank all the typed kool-aid, so I'm sold, as it seems you are as well.

So we're essentially saying typed is 10x better than dynamic, but was dynamic ever really a good place to start with?

I'd say dynamic has its place. Especially Ruby since it can serve as a stepping stone for the imperative-minded into functional.

> typed is 10x better than dynamic

10x what? Rails' community is many-x larger then Yesod's, in that case dynamic wins.

Dynamic has a nice exploratory quality. It pushes off the moment of reckoning, but sometimes you need that if you're sketching an idea in code. It was good for me when I first learned, and I think that's still true now. For "in the large" systems it's basically required that stuff gets a bit more gooshy and dynamic-y and interact in an indirect, protocol-driven fashion.

But when you actually have a specific piece of engineering in mind, it's nowhere near as helpful - it tends to solve things that could probably be solved more soundly with compile-time constructs. But there's a process of building up your understanding to where you can actually have confidence in what you're building, which isn't reached so easily. Having the compiler fail your code before it can run is very "magical" in that sense.

Strong typing on the web has been an intractable problem for me so far. Sure, I can have strong typing in my server-side code. But so many errors result from the interaction between the server, CSS, HTML, and JS. For example, you define a route at the path `/apples` but send an AJAX request to `/oranges` instead. Or you write `<div class="apples">` but query it with `div.oranges` instead. These are very much like type errors or name errors, except they occur at the boundaries of languages and processes.

Have you worked out a way to catch these sorts of things at compile time? If not, do you think it's possible in the framework of the future?

Haskell has some typesafe template languages. I'm not a huge fan of them, tbh, as they're kind of rough at the moment.

More promising in my opinion is the fact that Javascript is becoming an increasingly popular backend for Haskell via GHCjs which will give a great space for building type-checked front ends which have all the guarantees you like. For instance, type checked routes already exist which prevent you from writing the wrong endpoints or sending invalid typed data to them... these can be transparently extended to the frontend without much more difficulty.

The examples you give don't seem to be typing problems, they seem to be wrong-value problems. They might incidentally also involve typing issues (e.g., "/oranges" might not exist or might be an endpoint with a different signature than "/apples"), but that doesn't seem to be the central problem in any of the examples.

> Have you worked out a way to catch these sorts of things at compile time? If not, do you think it's possible in the framework of the future?

To the extent that they are typing problems, it would seem conceptually possible to catch them through a strongly typed language and framework that abstracts all the underlying technologies and compiles to a combination of backend executable(s), and front-end HTML, JS, and CSS, and includes all the routing for both ends.

Actually building such a beast would seem to be a non-trivial engineering challenge.

"[I]t would seem conceptually possible to catch them through a strongly typed language and framework that abstracts all the underlying technologies and compiles to a combination of backend executable(s), and front-end HTML, JS, and CSS, and includes all the routing for both ends"

That would certainly do it, but I think all you need is some definition of interface that you can check your code against on both sides. This could be generated by one side and consumed by the other, or produced directly by the programmer(s) and consumed by both. You would need some means of actually checking your code against the specification on the consuming side(s), but they needn't be part of some broader framework (beyond the trivial sense in which they already are).

Sure, you can do that; but the problem is that you then have to worry about type system mismatches between the interface definition language, and the back- and front-end application languages.

There have been lots of things that do something like this: SOAP and the associated WS-* standards are probably the best known.

Very true, and certainly still a big undertaking, depending a little on how well the type systems at either end line up.

> The examples you give don't seem to be typing problems, they seem to be wrong-value problems.

They're like type or name errors because the "apple" and "orange" here are like identifiers, not data. Sure, to the browser, they're data. But in terms of the structure of the web application, they're identifiers like variables, function names, or types.

For example, the HTTP endpoint "/apples?count=5" is like a function "apples(int count)."

> Actually building such a beast would seem to be a non-trivial engineering challenge.

It certainly would. That's why I'm wondering if you consider it possible.

While a bit rough around the edges, the full type safe server-client stack can be done in Scala with Play[0] + Scala.js[1] + ScalaCSS[2]

I say rough because despite Scala.js' fantastic performance characteristics, you're looking at 100kb file size off the bat; from there generated code size is reasonable, but that's a pretty big hit, particularly for cache challenged mobile clients.

Otherwise, being able to tie Play's type safe reverse routing into the client is a big win. Previously with GruntJS + Coffeescript approach I'd get small file size, but complete lack of safety; just winging it with `routes.user.maybeNotExist(id)`.

[0] https://github.com/playframework/playframework/ [1] https://github.com/scala-js/scala-js [2] https://github.com/japgolly/scalacss

> errors result from the interaction between the server, CSS, HTML, and JS

this may be true, but I'm not sure spending resources trying to solve those problems, are the best use of resources?

I would rather be happy with a strict separation between the front-end and the server than try and deal with such an impedance mismatch and the framework cruft that generates.

I guess it just seems overly ambitious to me.. finding the right abstraction for the server is difficult enough without polluting it with the front-end.

It seems to me people are very productive in other languages that don't tightly bind the front-end code to the server; why spend time solving problems are are more incidental than essential?

> I guess it just seems overly ambitious to me.. finding the right abstraction for the server is difficult enough without polluting it with the front-end.

Certainly. That's why I'm skeptical that this will ever happen.

> why spend time solving problems are are more incidental than essential?

I wouldn't characterize these kinds of errors as incidental, inasmuch as they account for a very high percentage of the web app bugs I've encountered.

Designers of languages like Rust and Haskell noted that null pointer dereferences were the single largest class of errors in other languages. Thus, the designers chose to make null pointer dereferences impossible at the language level. With that choice, they turned a huge number of run-time errors, which developers often miss, into compile-time errors, which developers cannot ignore. This has proven itself beneficial to productivity and software quality.

So too here: If I'm correct that client-side type and name errors constitute a large fraction of all web app errors, then catching them at compile time will be a big win.

But again, I don't know how feasible this is. Nor do I know whether it would involve compiling from a type-safe language to HTML/CSS/JS or just static analysis of raw HTML/CSS/JS.

the logic of your analysis is sound. I suppose I'm just not sure that client-side type and name errors constitute a large fraction of all web app errors.

Anecdotally, the team I am on doesn't have these issues (we certainly have other issues), but I could see them being important to prevent on certain projects.

When using Haskell it feels like I more clearly have to deal with those not-strongly-types-environment issues. I have to write some interface code (which surely takes some "extra" time) to pull un-strong into Haskell; but then the unstronglyness is represented strongly in Haskell types and has to be dealt with accordingly. This reduces funny bugs that may otherwise arise when overseeing corner cases.

Main hometaker: it's like in Haskell I have to do more work up-front, to enjoy much better productivity down the road.

I'm not sure that reduction in code size or better performance is necessarily the 10x metric you want to go for. Maybe in some cases, of course, but 'my framework has fewer lines of code' is absolutely irrelevant to the delivered value of a service, for example.

Does using Yesod mean that you can deliver code that better meets your goals? In a business environment, that might mean easier maintenance, or better performance. Equally, it might mean faster development times, where maintenance is less of a priority. If it meets your goals then awesome! If it doesn't, then there are lots of other things you can use – including Rails.

Often goals are: crank out X with programmers Y on deadline Z. I assume the client has no language/framework preference.

If X is a greenfield webapp and Y are not Haskellists yet (language has a steeper learning curve then, for instance, Ruby), and Z is very soon then I will probably choose Rails (given that programmers have some experience with dynamic languages and/MVC framework, and I'm fluent with Rails).

Notice that maintenance costs are not a factor. This is often not accounted for, but a large part of a webapp's costs are maintenance: and this is where Haskell shines: maintenance and refactoring.

Let's say I'm starting up, then low maintenance costs are of PRIME importance. You want to be able to keep adding/improving with a small team, not being bogged down by an endless stream of bugs only found on production -- nothing ruins flow like that.

> Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time.

Ruby is strongly typed.

That's true.

But in practice I've come to the idea it's a meaningless distinction if you're not going to bother to declare the types on your methods/functions.

Instances may be Strongly typed in Ruby. Methods are not. So you get almost none of the benefit. It's like Types only exist in Ruby to support Mixins and inheritance chains.

Prefer Composition over Inheritance right? But what if through Composition you effectively lost all your Type information? That's the issue Ruby presents.

> Instances may be Strongly typed in Ruby. Methods are not.

Sure they are, just not all of them:

    [].first('wat') # => TypeError: no implicit conversion of String into Integer

What Ruby lacks is _static typing_ and compile time checks of these types. Instead we have runtime checks in a few places.

> Prefer Composition over Inheritance right? But what if through Composition you > effectively lost all your Type information? That's the issue Ruby presents.

This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour. For example:

    class MyArray < Array
    end

    m = MyArray.new([10, 20, 30])

    p m.map { |number| number * 2 }.class # => Array

Here one would probably expect an instance of MyArray to be returned, but instead we get a vanilla Array.

Why would you expect that if you didn't implement map in MyArray?

> This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour

No. It is advocated because it produces simpler code in the long term in most cases. It is a quite different question to inheritance from core classes.

Using introspection in Ruby is generally against convention. There's no reason to care about the class name if it #responds_to? the method you care about calling.

That's not an example of a strongly typed method in Ruby. That's an example of an assertion (most likely implemented in C).

Though in hindsight you're right anyways. Methods define an implicit type for the arguments they operate over. It's just you don't know what it is without reading the whole method. Which I think gets to "expressiveness".

I agree with the push to get people on the same page with regards to terminology. However, this comment would be far more useful if it suggested an alternate term for the real difference the parent was intending to indicate, or made explicit a claim that the difference was in fact not real.

> Ruby is strongly typed.

I think one has to bend backward in order to defend that claim; but you probably have some ground somewhere since the term "strongly" is weakly defined :)

By strong _I_ meant HM-typesystem strong, or stronger... (for instance I dont think the NullPointerException-king Java is strongly types either -- though it is strictly typed -- again a matter of personal definition)

As a Haskell programmer who has also come from Rails -- I'm a Rails developer now -- and who is also interested in writing a web app in Haskell, I'm very interested in your experiences. Are you on any forums or online communities that have helped you in developing a Haskell web app?

No, just started to use Yesod to do simple things. Then moved on to hard things. Sure I'm on relevant mailinglists and /r/haskell; but apart form that no special community forum helped me.

What would you like to know about my experiences? Please ask your questions, I'll answer :)

Well, I haven't started my web app yet. Right now I'm finishing up a Haskell app that plays Connect Four: maybe that could be the backend for a web app.

It looks like you're using Yesod. What resources did you use to learn it -- I think there's a Yesod book, was that helpful? Did you consider any other Haskell frameworks? What did you find hard about writing an app using Yesod? Do you think it took less time to write the app than it would have given a similar level of knowledge about Ruby/Rails?

Although I'm way faster writing Haskell than I was, say, six months ago, I feel I'm still really slow compared to how fast I can code in Ruby. Having said that, when I write a Haskell program, the only errors are usually logic errors, not process errors. NoMethodError (an unexpected nil) must be one of the most common Ruby/Rails errors. It's really great to just not get that anymore. :-)

This is just an anecdote as:

- I agree that most rails programmers will not move to clojure.

- For monorail apps, rails is still king.

That said, for us, when comparing clojure and ruby REST API services we've built, clojure has had the following benefits:

- Less code

- Less tests needed

- Better concurrency

- Less developer hours

- Less maintenance

- About 33% of the servers for same performance

- Easier/faster debugging

It's been far more then a 10x improvement overall, and if people are looking to move out of the monorail style of app, it's definitely worth a look.

Interestingly, we had a couple of Clojure experiments.

Takeaway was that there were some benefits in terms of performance and maintenance, but they weren't worth the tradeoff in expressivity and increased developer time.

There's no reason that Rails should be restricted to 'monorail' or monolithic apps. We've had great success writing what are essentially microservices in Rails. Code is easy to read, easy to maintain, and performs well. It's hard to find any compelling reason to use another toolset under those circumstances!

I appreciate the counterpoint!

I guess just another example of different strokes for different folks. For us developer time decreased, and expressivity increased.

I wasn't suggesting that rails shouldn't be used for microservices, we actually have a number of rails microservices in production as well.

I was more stating that I agree with OP in that if I were to write a monorail style application today, I would use ruby/rails over clojure. I was also pointing out that if you are moving to more of a SOA/microservices framework that we've had great experience with clojure, and that it's worth looking at.

I'm a huge fan of rails, and have been using it since pre-1.0. I think as we look back on this period in time, we're only going to appreciate rails more and more for really making self / low funded startups viable.

Cheers!

A great point, of course. That's why we had a crack at Clojure in the first place!

Basically, it's great to have a diversity of freely-available, open-source tools that can be used for such a wide variety of different tasks. I expect the 'my toolset is better than your toolset' nonsense will always be with us, and while it's useful to discuss some of the pros and cons, we should all bear in mind that most tools are awesome :)

If you feel Clojure is less expressive than Ruby, you're not good enough at Clojure yet. I'm not saying you have to prefer Clojure's syntax, and Ruby probably has more libraries for a lot of things you want to do. Going from Ruby to Clojure may be a productivity tradeoff for you and your team, but objectively it's not an expressivity tradeoff. Clojure has a bit more expressive power than Ruby.

Could you reference examples of this assertion please?

I think the biggest reason would be Clojure's macro system. The code itself is an abstract syntax tree that you can rewrite in arbitrary fashion at macro expansion time. There's a good example here of how Clojure's macros are more powerful/expressive than Ruby's instance_eval and class_eval: http://daveyarwood.github.io/2014/07/09/whys-guide-to-ruby-i...

And here's an attempt to objectively rank programming languages by expressiveness, measured as lines of code changed per commit: http://redmonk.com/dberkholz/2013/03/25/programming-language...

Not sure what examples the author was thinking of but functional lisps tend to be extremely expressive just because of their nature. If there is expressiveness you are missing the language can be molded in ways that are simply not possible in non-homoiconic languages.

Easy. Ruby doesn't support syntactic abstraction via macros. No, 'eval' doesn't count.

I think it's pretty uncontroversial to suggest that Clojure is more expressive than Ruby - without even getting into macros.

Just take run of the mill Ruby code and convert it to Clojure. Especially anything that looks like functional programming.

Maybe you're the one who's not good enough at Ruby yet. :)

In Ruby you can't express the concept of an empty List through a Type.

When comparing statically typed languages to non, that's generally what "expressiveness" means to me. Any idea can be expressed through expressions in a turing complete language right? That's not a useful metric.

In Ruby a method's type-signature expresses almost nothing for example.

  def f(a,b)

Does the method side-effect? What types are a or b? Are they the same type? Does the method mutate the arguments? Return a new value? What sort of values might it possibly return?

In Ruby you can't express any of these things outside of naming conventions (that are entirely useless for answering any of these questions to any tooling).

Compare that to Scala:

  def f(a: Int, b: Int): Int

Does the method side-effect? Almost certainly not (but it would typically depend on the containing Type). What are the types of a and b? Integers. What does it return? An Integer. Does it mutate the arguments? No; they're immutable. Is it possible for the method to return anything else? Throw an exception perhaps? That would be unexpected. Otherwise you'd write it to return a Try[Int], so you can assume more about the author's intent here.

Well now you're getting into statically vs dynamically typed, which doesn't apply to this conversation because both Ruby and Clojure are dynamically typed.

But in a statically typed language like Scala or Haskell, you can use the typechecker to express proofs about program correctness. That is a form of "expressiveness" that doesn't really exist in Ruby or Clojure (unless you use core.typed).

There's nothing about dynamic typing that prevents declaring types right? Because in Ruby you while you can extend an instance, you can not taketh away Types from it.

IOW, Ruby could use the Scala syntax I wrote, and still be just as Dynamic. You're already constrained by how you use that type within your method. You're just not expressing it concisely since you have to read the method to understand the implicit Type it's operating on.

In practice a lot of this gets naturally conflated though. Which I think you were getting at.

But if we're going to limit ourselves to functions with undeclared types, I guess I'd point to Clojure's partial as something you can't really express with Ruby. Or Pattern Matching in Elixer.

Well, Ruby is duck-typed with dynamic/late dispatch, so method receivers are not known ahead of time. When I call `foo.bar`, it does a dynamic lookup in the class hierarchy at runtime to see which class implements the `bar` method, and the result can be changed at runtime. So although you could theoretically declare types in Ruby, it would just be documentation. You'll still get the type errors at runtime because there's no ahead-of-time typechecking happening.

With Clojure you can actually compile your modules while developing them and discover certain classes of type errors ahead of time, so something like core.typed actually makes sense because you can run the typechecker over your code instead of having to run a separate test suite.

The main type error you always have to worry about in both languages, though, is accidentally calling functions/methods on nil at runtime. Of course that applies to null in Java too...

> You'll still get the type errors at runtime because there's no ahead-of-time typechecking happening.

That doesn't mean it's just documentation though. It could tell you that something is happening you didn't expect. Like passing a Role where you expected a User. (And if you wanted to operate on both interchangeably you shoulda put an interface on it.)

> The main type error you always have to worry about in both languages, though, is accidentally calling functions/methods on nil at runtime.

Agreed. Option/Maybe types FTW. The ?-operators sometimes presented as a solution feel very half-baked in comparison (they don't return a new type so just because you remembered to use it on line 10 doesn't mean anything to lines 20, 37 and 82).

Expressivity to me is generally about code size, for a given problem does the language allow a concise solution to be expressed?

The more concise the solution the more expressive the language.

A language that supports 4*4 is more expressive than a language that only supports 4+4+4+4, languages that require more type information to be expressed are in general less expressive.

  let add a b = a+b

is more expressive than

  func add(a:IAddition, b:IAddition) -> IAddition { 
    return a + b; 
  }

where IAddition is an interface requiring the infix + operator to be defined, and the subsequent definition of said interface, where as a more expressive language will deduce the interface from the function.

Also the empty list can be expressed as a type...

  class EmptyList 
    def empty?
     true
    end
  end

An empty List would have to be a List first. So an Instance. But at that point you'd be facing a significant challenge to ensure it's both Immutable and still a List (or Array, whatever).

But your definition of "expressive" is (IMO) backwards. Because the first example only actually expresses a label that only has meaning because you give it. It doesn't tell you if the method prints to STDOUT, concats a String, adds an Int, adds a Float to a Decimal (and how that would be achieved), etc.

All that, and Ruby is (IME) more verbose than Scala (and I suspect Elixir, Erlang, Clojure, etc) for any real non-trivial example.

Monorail? Do you mean monolithic? or do you mean "doing only one thing" (one track)?

> LOL at the idea that every Rails programmer will be switching to Clojure or Elixir!

I meant those as examples based on what I see around me. That's exactly my agony, I don't know what is next and, if I did, I would be learning it already. At this point, I just feel it is not Rails.

> Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads

If you are using Event Machine you can't abstract away from it. You need to do all I/O using Event Machine aware mechanisms. You can get rid of callbacks by using fibers but you are still required to use an API specific to Event Machine. For example, you can't use File.read to read a file as that will block your event loop.

You are confusing the real need to use EM aware mechanisms with a not-real inability to use abstractions over EM itself. Those are two different issues.

Nginx HTTP Push Module seems to much better solution than EventMachine. So Nginx keeps opened sockets and a Rails app sends messages via ordinary HTTP.

http://wiki.nginx.org/HttpPushStreamModule

Agree, very much.

I'm also wary of handling websockets from Ruby, which is demonstrably ill suited for any kind of high concurrency networking (been there, got the t-shirt).

Since most people already run nginx in their stack anyway I don't see the advantage of sticking with a Ruby-based solution that is almost guaranteed to be inferior on every metric.

Having used both Rails + Clojure here's my take.

As a general comparison, when it comes to building server-side web apps Rails is preferable to Clojure. But for the web stacks / ecosystems as a whole Clojure wins by about 10x. The main reason for this is ClojureScript. For those who aren't familiar ClojureScript is a Clojure->Javascript compiler that lets you write your UI code in Clojure and drastically simplifies Javascript codebases. Given how much time is consumed writing UI code in modern web app development, the benefits that ClojureScript gives you over the turbolinks/js framework of your choice approach that Rails emphasizes cannot be overstated.

I've found that writing web-apps/api's in Clojure, using ClojureScript on the front-end, then using Rails to write small services where you want to take advantage of some of the great Ruby libraries is the way to go. You get the best of both worlds.

I'm curious (as someone who's only dabbled in Clojure): could you write an Ember app in ClojureScript (or Angular/React/Knockout)? Is it like Coffeescript---i.e. just a compiler? If you wanted to build a SPA in ClojureScript, how would you approach it?

You'd use a React wrapper such as Om[1] or Reagent[2]. These take advantage of React's DOM diffing and pair it with ClojureScript's immutable data structures.

1: https://github.com/omcljs/om

2: http://reagent-project.github.io

You can write Ember/Angular/Knockout etc... in ClojureScript (I've done it before) but it comes out feeling weird and unnatural. You always feel like you're trying to fit a square peg into a round hole.

The preferred solution is to use a ClojureScript wrapper around ReactJS and write your own event handling logic. I'm a big fan of the Reagent library which wraps React with a dead simple API. I believe it's the best UI library ever created and I wish more people knew about it.

The big idea is that you store your UI state as one single Clojure data structure. A Reagent component is just a Clojure function that takes the necessary sub-section of the UI state as an argument and returns a Clojure data structure that represents the HTML code that it wants to render. An example of this would be the following component that displays a list of items.

(defn [items] [:ul.items (for [item items] [:li.item (:display-name item)]])])

Then whenever you change the state of 'items', the component will automatically re-render and inject the new DOM as necessary using React's diffing algorithm for high performance. The key thing here is that there is no Javascript framework to learn. All you do is manipulate Clojure data with Clojure functions and use React to render it. There's no 'Ember.component.extend' or 'ng-repeat' to worry about. You spend very little time looking through documentation. The Clojure langauge IS your framework, it's really incredible.

This is the strongest argument for Clojure in web programming. HTML (and all XML-based UI frameworks) are just tree data structures, so it's trivial to represent them as s-expressions and manipulate them using normal Clojure code, then render them to HTML at the last moment, instead of having to use different syntax to inject code into templates. Lisp/Scheme languages are uniquely well-suited to the problem domain.

But lisp/Clojure actually holds no real advantage in this area. Javascript, Ruby, Perl, Python, etc. all have built in lists and list-of-lists (ie, trees). They all have map, filter, etc. to manipulate their native lists and hashes/objects/maps in similar ways to lisp/Clojure.

http://jsml.org is just one example (Javascript). I know similar things exist in Perl and I'm sure Ruby and Python have them as well. If not, it's literally something you can write in a couple hours.

Thanks for the link, that is interesting. While I don't doubt that it's possible to create something similar to https://github.com/weavejester/hiccup in Ruby and Python as well, I am not aware of existing libraries for it and it's definitely not considered the "idiomatic" way to generate HTML in those languages. They both skew heavily toward template languages that are some variation on <div>{{foo.bar}}</div> and require special syntax, which in turn requires editor support for syntax highlighting and such. And Javascript has been the same way until recently--Angular and Ember are template-based by default. And while JSML looks pretty good, I think the other alternative Javascript is trending toward is the JSX approach taken by React, which is basically just backwards templating, and requires a precompiler pass.

Meanwhile with Clojure, because it's homoiconic (code is data and data is code), all you need to implement a DSL for generating HTML is basic functions and macros (which are just functions that process your source code), no special new syntax is necessary. In fact if browsers used Clojure (or any other Lisp/Scheme dialect) as their native scripting language, there'd be no reason for HTML, XML, JSON, or CSS to exist at all in the first place. They could all just be code.

    > As a general comparison, when it comes to building 
    > server-side web apps Rails is preferable to Clojure.

Do you generally prefer a Rails-style framework over microframeworks?

I went from full-time Rails to full-time Clojure, and I would use Clojure over Rails these days for the same reason I'd use Express/Koa (Node) or Flask (Python) over Rails.

Eventmachine itself is in kinda unmaintained state. Newer projects are starting with Celluloid and stuff, which arguably offers much easier way to reason about concurrency. I am not sure why they would pick EM as base for ActionCable.

Rails programmer switching to Clojure/Elixir here. And my workplace is switching to Scala.

I always wondered why Rails programmers prefer Clojure/Elixir over Scala, Scala syntax and concept seems to me much more translatable to Ruby than Clojure. In Scala, just like in Ruby 1 + 1 is 1.+(1), you have a scala version of method_missing, duck typing, pimp my library etc... Is there a reason why Rubists prefer a completely different paradigm such as Clojure?

I got interested in Clojure because I felt I needed to learn something LISPy. Similarly, I got interested in Elixir because I felt I needed to learn Erlang. I have yet to have any kind of similar motivation for Scala.

These are not good reasons, but they are my reasons.

Elixir is extremely Ruby-influenced, much more than Scala. I do appreciate Scala, but Clojure is just cool.

Clojure is simple and Scala is complex.

I dove into Scala before Clojure because lisp was so alien to me. After a couple months of Scala, I still felt like I didn't know where to begin with a blank slate, though I was eventually productive.

When I finally gave Clojure a shot, I was building things my first week. Kinda like my first experience with Ruby.

Clojure felt like a better Ruby to me. The aesthetics that drew me to Ruby were improved in Clojure.

    > Is there a reason why Rubists prefer a completely different
    > paradigm such as Clojure?

The leap from Ruby to Scala is a larger gulf than Ruby to Clojure, though it's not obvious at a glance.

For me, Scala is a great language that continues to present me with good surprises (i.e. literal curry syntax). The only issue for me is the JVM and the package/namespace system (not to mention mvn, sbt).

In this way, Erlang/Elixir is more enjoyable for me. I much prefer the Erlang module system (Python and Node.js get a special mention here as well) vs. what you get with Ruby, PHP, Java, etc.

Having moved to Elixir from Ruby (among other languages), I can say that Elixir's syntax is pretty natural coming from the Ruby world. That's probably no coincidence, considering that its creator (Jose Valim) is a Rails contributor.

Elixir/Erlang/OTP has a lot of useful stuff to say about testing, deployment, reliability, maintenance, and code quality. Ruby does too, but is constrained in various ways.

Honestly, websockets-as-first-class-citizen plus the E/E/O process model is a huge win, and one that Rails just won't have going for it.

That doesn't make Rails obsolete, but it's outside of its comfort zone compared to the new/old tech.

Reply on news.ycombinator.com