I guess this question pops up here once a year. And the answer is always the same.
Is Rails still relevant in 2018?
91–100 of 346 posts
Re: Is Rails still relevant in 2018?
#92I find the “just tools” attitude to be such an Anglo meme. On the other hand the French say “Good tools make good workers.” I agree with the latter.
"A bad workman blames his tools" is a counter to that.
Re: Is Rails still relevant in 2018?
#93Earlier quoted context omitted.
I personally think the deployment story heavily conflicts with container management. I’m going to give edeliver on real hardware a go at some point and things should work very well and be very simple.
Only if you want Erlang clustering or hot upgrades. In the usual army-of-one deployment scenario, Elixir and Erlang work inside a container just fine.
Sorry I wasn't clear; what I'm saying is using the default deployment story with Erlang/Elixir is actually simpler than Kubernetes in most cases.
Re: Is Rails still relevant in 2018?
#94I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish? If we know something really well and there are enough developers to support an ecosystem and the talent pool in your is big enough just use whatever you want. PHP in 2018? SURE. C++ in 2018? SURE (You masochist) Rails in 2018? Youre damn right I would. GO in 2018? OK. Fine. Whatever. This is…
"C++ in 2018? SURE (You masochist)" I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.
I think he means "C++ in 2018" to build a standard webapp, which definitely is masochistic because you can be much more productive on e.g. Rails. Just like how using PHP to build a real-time graphics engine is also probably masochistic.
Re: Is Rails still relevant in 2018?
#95Earlier quoted context omitted.
This viewpoint is so far off from reality that I don’t even know how to respond. GitHub, Airbnb, Shopify, Indiegogo, Kickstarter, Urban Dictionary... the list goes on and on and on. Having the hardline opinion that Ruby or rails is slow is plain ol’ ignorance. You can build highly performant apps in Ruby and Rails, you just need to know what to optimize. The same applies to any other language or platform. Facebook is…
Pretty much no Rails app at these large companies can even do something as basic as concurrent network requests. This is an area Ruby the language is weak in, and it's extremely difficult to graft on something like concurrent-ruby to a large existing codebase that assumes all requests are sequential... Also, in the past the multithreading/concurrency story around ActiveRecord has been "it probably works, might leak c…
Ruby has threads, when networking the GIL doesn't matter since the threads will context switch. For a company like Shopify paying for an extra 50 servers is like hiring one developer, I don't think it has much significance to them.
Re: Is Rails still relevant in 2018?
#96100% yes
Re: Is Rails still relevant in 2018?
#97Earlier quoted context omitted.
I work in a lot of Django shops and my Ruby is nowhere near as good as my Python but I'll pick Rails every time if I'm working on a side project. Why? Because the development velocity when using it is unparalleled. I can have an MVP up orders of magnitude quicker than I can with Django/Flask/Twisted. You're absolutely right on the Admin interface and auth, but auth is a gem install away [1] and Django's admin won't f…
The source of Rails ease-of-use appears to flow from Ruby's object model, which I have yet to see a more elegant one outside of the Smalltalk ecosystem. Ruby's semantics just seem to be a natural fit for the web, where visual presentation of information seems to almost demand a truly-flexible set of tools. You want a smooth progression of tooling that you can approach and slowly clarify ever-finer approaches to over…
I would wholeheartedly agree that the object model confers a large advantage to Ruby; I hadn't considered your Python point but you're absolutely right - there are demonstrably fewer ways to solve certain problems. I sometimes wonder what Python would look like if it were easier to differentiate between an attribute lookup and a method call.
Re: Is Rails still relevant in 2018?
#98Earlier quoted context omitted.
Why do you think an all-in-one framework is an advantage? As soon as you want to switch something out you end up fighting the framework and the tutorials. Better to start with dedicated libraries that each do one thing - it's inevitably where you're going to end up. (Not that I'd consider an untyped ecosystem in the first place, especially one as fond of "magic" (e.g. monkeypatching) as rails. I have sympathy for jus…
I think the types argument is bullshit but it's just my opinion. Do python or ruby devs really feel they are less productive than java devs because they have no types? What I see happening is languages like java becoming more dynamic (var etc) and languages like ruby/python getting better IDEs (auto completion will continue to improve).
Var is hardly more dynamic. Type inference is comes from statically type functional languages.
Re: Is Rails still relevant in 2018?
#99Of course it is. The question is kind of silly. For basically any startup, my advice would be: unless and until you can credibly explain a genuine reason why you can't use Rails - use Rails. I'm not some crazy fanboy but until someone can actually name a seriously competitive, batteries-included, all-in-one framework* which delivers everything, or even most of, what Rails does - it is very relevant and you ignore it…
Why do you think an all-in-one framework is an advantage? As soon as you want to switch something out you end up fighting the framework and the tutorials. Better to start with dedicated libraries that each do one thing - it's inevitably where you're going to end up. (Not that I'd consider an untyped ecosystem in the first place, especially one as fond of "magic" (e.g. monkeypatching) as rails. I have sympathy for jus…
> it's inevitably where you're going to end up
If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem".
For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra.
If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required.
It's great if you have unlimited resources to spend the time setting up the perfect tech base for a project for if it does eventually require scaling above what, Basecamp for example, can handle - but that seems like wasted resources for a great deal of orgs that don't have that level of backing.
Of course, if you truly need something novel, then it's a moot point, if you can't achieve what you need to with a stack, then just don't use it.
Re: Is Rails still relevant in 2018?
#100Earlier quoted context omitted.
RoR has always been rather impenetrable to me, more-so than some late-stage/terminal Node-based projects. I recently wanted to remove IP logging in a RoR application but I was unable to find the relevant code anywhere, the only hits that grep spat out where the migrations and I couldn't figure out how to rip all that out. In the end a project developer pointed me to the correct file and I had to change a single line…
> I recently wanted to remove IP logging in a RoR application but I was unable to find the relevant code anywhere, the only hits that grep spat out where the migrations and I couldn't figure out how to rip all that out. Usually you'd just create a custom logger[0] and tell Rails to use it[1] [0] https://ruby-doc.org/stdlib-2.5.0/libdoc/logger/rdoc/Logger.... [1] https://guides.rubyonrails.org/configuring.html#rails-g…
It wasn't putting the IP in the log but in the database and along the username and session data, there is an open ticket about that behavior too. Since I'm in Europe/Germany, this kind of data storage would have been a no-go even before the GDPR.