61–70 of 168 posts
Earlier quoted context omitted.
> the alternatives are The main competitive alternatives to Rails are single page application frontend frameworks combined with light API focused backend frameworks. Not a single web application framework.
So far from what I've seen is that most frontend frameworks go inside one of the directories inside rails. Nice, clean and tight integration. :)
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…
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?
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/
Pros: websocket support is good, the developers are friendly and answer questions, the app is faster than what I'm used to with Rails.
Neutral: Elixir looks like Ruby but it's very different. Be prepared to learn everything from scratch. You need also to know a little Erlang and the OTP framework to be able to use some useful library functions. OTP is a world on its own.
Cons: the tooling is very immature, probably like the one for Rails at the time of the 1.x releases. Be prepared to write many things by hand instead of requiring gem_x and automagically get functionality for free. This is going to slow down developement, increase costs and possibly get you outbid from competitors. Nevertheless it could be OK for internal projects used to get familiar with the framework.
Earlier quoted context omitted.
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…
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 ru…
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 :)
Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto? I can't point out one really valid critique in this entire rant. While I imagine that you've had enough kool-aid to actually believe the things you said, I think you should probably do a few google searches to find out how many shops are hiring Rails devs versus Clojure or Elixir. You can do more experimenting by seeing who else is actually…
> 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…
The reality is that lots of companies have been and continue to be created around Rails applications. An AngelList job search focused on server-side technologies currently returns 1267 startup results for "rails" while "node.js" returns 832, "node" returns 854, "django" 434, "python" 1461, "flask" 69, "go" 441, "php" 1192, and "Java" 3163.
JavaScript has become bigger, and it hasn't killed Rails on the server. Java remains huge, and it hasn't killed Rails. Python, Django, and Rails have roughly the same relationship as they did back in 2009.
A lot of very smart people who have extensive experience with many technologies choose Rails for new projects for very good reasons, this has been the case for the 10 years people like you have been making the same FUD-filled comments, and it will likely continue to the be the case for some time.
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…
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?
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…
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.
I never hear any production app with elixir in Berlin, some noise with clojure, but some people move from node.js to Golang. As for rails, people are happy. Sometines I think is super cool to rant rails :)
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…
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.
I never hear any production app with elixir in Berlin, some noise with clojure, but some people move from node.js to Golang. As for rails, people are happy. Sometines I think is super cool to rant rails :)
As a ruby/js dev moving to Berlin in September, that's good to hear. I'm interested in talking to folks who might be more familiar with the scene there. If you know anyone who'd be good to reach out to, let me know!