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

71–80 of 168 posts

Re: Existential crisis at Railsconf

#71

Post by dragonwriter »

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…

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.

Re: Existential crisis at Railsconf

#72

Post by techpeace »

LunaSea wrote: post #56
stephenson wrote: post #8

Earlier quoted context omitted.

Re "In web framework terms, Rails is old" Oh how I love that! I would rather build my business on something old and well testet then something new and shiny.

http://www.cvedetails.com/vendor/12043/Rubyonrails.html "well tested"

Not quite sure I'm understanding the point of your snark. The fact that vulnerabilities exist mean that it's not well tested? Take a look at the tests directory.

No matter how many tests you have, security vulnerabilities exist in your code, I assure you. Their frequency of discovery says more about the popularity of a codebase than it does about the thoroughness of testing.

Re: Existential crisis at Railsconf

#73

Post by Cakez0r »

integraton wrote: post #65
makeitsuckless wrote: post #53

Earlier quoted context omitted.

> Startups and other more established companies still choose Rails as their platform As far as I can tell, this process has come to a grinding halt in the past few years. I certainly see established companies ditching Ruby, not so much because of the language or framework itself, but because of the community that only seems to be able to solve problems "the Rails way", even if that's far from the most appropriate arc…

Frankly, I'm surprised anyone would still make comments like yours after all these years. Comments like this probably peaked in 2008-2009 ("Rails can't scale" was even earlier) after the zed shaw article and there was a bunch of hype about everyone supposedly moving to Django and how Rails was supposedly dead, yet that didn't happen then, or any of the other times. The reality is that lots of companies have been and…

PHP -> Rails -> Node

Re: Existential crisis at Railsconf

#75

Post by gnufied »

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…

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.

Re: Existential crisis at Railsconf

#76

Post by pjungwir »

AlwaysBCoding wrote: post #51
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…

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…

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?

Re: Existential crisis at Railsconf

#77

Post by lifo »

As someone who's done the bulk of the work for Action Cable, I wanted to clear the confusion re: cable and eventmachine. Cable is currently using EventMachine because it uses faye-websocket for dealing with websockets. And Faye is one of the very few well maintained ruby library dealing with websockets.

And in fact, Action Cable uses Celluloid threadpool to run all the application code in threads. So the model is a combination of EventMachine + Threads.

There's absolutely no reason it can't use Threads + Celluloid all the way. But building on top of Faye was the simplest way to get things up and running.

Re: Existential crisis at Railsconf

#78

Post by brodock »

otterley wrote: post #33
rakoo wrote: post #16

Earlier quoted context omitted.

You don't need to go as far as websocket to leave the stateless world: Server-Sent Events and all its cousings (Comet, chunked transfer encoding, even long polling ...) all need to keep a connection open for an unknown amount of time and then send data back to the client. Is Rails discouraged for such use cases ?

If you could run Rails in an event-driven webserver, it might be usable with persistent connections. Otherwise you'll need a whole lotta memory for all those workers that'll be sitting around doing nothing most of the time.

in other words: "unicorns considered harmful"

Re: Existential crisis at Railsconf

#79

Post by brodock »

railsbird wrote: post #25
davidw wrote: post #3

No, Rails isn't great for web socket kinds of things, but if it were me, I'd just use something else for that, and Rails for the main site. It's still one of the best things out there for quickly iterating, and yet still maintaining some structure and discipline, from what I've seen.

Agreed. I was fine with Railsconf focus last year of being "rock solid". Rails is still the best at what it does thanks to its community. However, Rails 5 is moving to a direction that goes against the abstractions and platform it runs on. If I don't care about this, now I have even more code and dependencies in my Rails apps. On the other hand, if that is becoming the sanctioned way of building apps, I would rather…

I'm pretty sure "ActionCable" will be optional, as for example "ActiveResource" were
Post reply on HN