Live data from Hacker News

Existential crisis at Railsconf

railsbird.tumblr.com

131–140 of 168 posts

Re: Existential crisis at Railsconf

#131
post #49

Earlier quoted context omitted.

> 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 gem…

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

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

Re: Existential crisis at Railsconf

#132
post #108
post #99

Earlier quoted context omitted.

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? A…

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.

Re: Existential crisis at Railsconf

#133
post #120
post #99

Earlier quoted context omitted.

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? A…

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…

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.

Re: Existential crisis at Railsconf

#134
post #28

Earlier quoted context omitted.

And equally bad at concurrency.

I don't buy this, having written and dealt with a lot of concurrent Django apps - I think people read something about the GIL often, and don't understand what the articles are really meaning. Basically Django is usually fronted with mod_wsgi and you use celery for backend tasks. The multiple requests part are dealt with because the web server pre-forks, and it's just fine with it. I think Django's problem is it moves…

It's speeding up development lately, 1.8 came out rather fast but it seems like the Django team likes to have ~1 year development cycle.

Re: Existential crisis at Railsconf

#135
post #92

Earlier quoted context omitted.

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 effecti…

> 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 informat…

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

Re: Existential crisis at Railsconf

#136

Earlier quoted context omitted.

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?

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.

Re: Existential crisis at Railsconf

#137
post #6

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…

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 J…

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

Re: Existential crisis at Railsconf

#138
post #55

Earlier quoted context omitted.

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

Re: Existential crisis at Railsconf

#139
post #110

Earlier quoted context omitted.

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,…

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 {{foo.bar}} 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.

Re: Existential crisis at Railsconf

#140
post #126

Earlier quoted context omitted.

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?

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

Post reply on HN