Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Existential crisis at Railsconf

railsbird.tumblr.com

Post reply on HN
Print view View original

111–120 of 168 posts

Re: Existential crisis at Railsconf

#111

Post by oh_sigh »

YorickPeterse wrote: post #101
ssmoot wrote: 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…

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

Re: Existential crisis at Railsconf

#112

Post by virtualwhys »

jarrettc wrote: post #66
cies wrote: 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…

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 ` ` but query it with `div.oranges` instead. These are very much like type errors or name er…

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

Re: Existential crisis at Railsconf

#113

Post by juliangregorian »

eranation wrote: post #96
juliangregorian wrote: post #54

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?

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

Re: Existential crisis at Railsconf

#114

Post by thothamon »

cies wrote: post #49
hopeless wrote: 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…

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

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?

Re: Existential crisis at Railsconf

#115

Post by dragonwriter »

dllthomas wrote: post #94
dragonwriter wrote: post #71

Earlier quoted context omitted.

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…

"[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. Th…

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.

Re: Existential crisis at Railsconf

#116

Post by vezzy-fnord »

jameskilton wrote: post #7

For those wondering what the alternatives to Rails are these days, I highly recommend checking out Elixir and the Phoenix framework. http://elixir-lang.org/ http://www.phoenixframework.org/

And its vanilla Erlang counterpart, Chicago Boss: http://chicagoboss.org/

Re: Existential crisis at Railsconf

#117

Post by platz »

jarrettc wrote: post #66
cies wrote: 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…

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 ` ` but query it with `div.oranges` instead. These are very much like type errors or name er…

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

Re: Existential crisis at Railsconf

#118

Post by briantakita »

I somehow got stuck upgrading from Rails 3 to Rails 4. Nightmare...

I've been through 5 Rails upgrades. Rails 2 to Rails 3 was a nightmare...

Rails does not scale well with complexity & is a pain to maintain...

There are a number of reasons for that. Rails started off favoring syntactic sugar over architectural integrity. They are gradually iterating toward a solid architecture. However, that required some significant api changes, which causes upgrade pain.

Also, the prevalence of monkey-patching (largely due to an unsound & overly complicated architecture), exasperated these issues.

Rails architecture is still overly complicated & misses the mark, IMO.

DHH's infamous "golden path" direction put the blame on the developers, when Rails itself had some major architectural flaws.

Rails Routes + Controllers are horrible. Why do we want an extra level of indirection? Sinatra/Express.js are easier to reason about RESTfully.

Asset Pipeline is horrible. The Node.js ecosystem (i.e. browserify) is much better. Client/Server separation of architecture scales in complexity more readily than the Rails monolith monstrosity.

I'm kindof bummed that Rails became so big. The "Rails Way", while being a step forward from what was there before, became too prevalent; sucking up too much mindshare; inhibiting further evolution of the broader ecosystem.

It's time we let Rails slowly die. There are many better libraries & frameworks out there.

Re: Existential crisis at Railsconf

#119

Post by yxhuvud »

YorickPeterse wrote: post #101
ssmoot wrote: 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…

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

Re: Existential crisis at Railsconf

#120

Post by fleitz »

ssmoot wrote: post #99
heliumcraft wrote: post #85

Earlier quoted context omitted.

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

  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
Post reply on HN