61–70 of 110 posts
Earlier quoted context omitted.
Ruby is changing. I doubt it will ever be as big as the Python world, but I can see it coming back into fashion. I’ve been paying attention to the community and it’s still very active.
I think there's a lot of burnout in the JS ecosystem, and many are looking for the efficiency of Rails. However, I'm not certain if Ruby on its own is gaining more of a foothold. For a few years it looked like you'd seen more Ruby generalists with tools like Chef and Puppet, but I think Docker has taken a lot of wind out of those sails.
I'm sad Ruby has been, or is, left behind by python. There are lots of little reasons but no real big one. I just love ruby. I love little things like 'unless'. I know it's still with us, but still feels a little sad.
I also love Ruby, it's all the little things. It helps me along and makes me happy every time I manage find a solution to a problem. "Woah! Can I really do it just like this?!?!"
Earlier quoted context omitted.
What makes you say it is hard to maintain longer lived projects? (I used to be a RoR developer for a few years, so I'm curious about other people's experiences.)
It's mostly the "magical" parts like before/after hooks. When you are tracing a bug and are trying to do step-by-step debugging, it has been hell. Quickly jumping to definitions? Even RubyMine can't do it. Furthermore, as the project grows, you need to introduce something more/bigger than MVC and people put these files everywhere. Sure it's a management problem but it doesn't help that people don't do the right thing…
But any large enough project needs rules for placing files/classes
I don't see how Rails failed in that way
I do agree there are some "magical" stuff like hooks that can be easily abused and introduce bad coding habits/patterns
Wish I can turn them off per class (not for the whole app since they are still sometimes useful)
Earlier quoted context omitted.
Faster hardware costs money. If this works well, and it stops being a PoC, why pay extra when you can simply add an annotation to a method, and your speed gain is free?
The thinking is that faster hardware is cheaper than developer time. E.g.: https://blog.codinghorror.com/hardware-is-cheap-programmers-...
> Everything is fast for small n. When n gets large, that's when things start to go sideways. The above graph of an ancient Trash-80 clobbering a semi-modern DEC Alpha is a sobering reminder that the fastest hardware in the world can't save you from bad code.
Earlier quoted context omitted.
Spring Boot Kotlin is worth giving a go. It has rapid prototyping abilities, but underlying Java promise of easy refactoring, great tooling. I recently refactored entire frontend and parts of backend code without ever having to restart server.
How is the ecosystem? For example - if I want to add auth, social login, profile picture and admin dashboard CRUD, are there mature packages that can be leveraged for these features?
Note to self - dont post about Java on HN, people downvote even non hateful comments!
Imagine going all in on a Ruby project with this specialized library that literally changes the way you write Ruby and still thinking that's a good idea. Keep Ruby as it is - slow and expressive. If you need to speed up, get faster hardware.
> ...If you need to speed up, get faster hardware. So if I need to speed up my Rails application on a AWS, GCP or Azure instance, you're telling me in order to increase performance, I need to upgrade to hardware that is able to take at least 4 to 6+ GB of RAM, to modern hardware on each of the servers I have to make it go faster? Not only that it will still be slow, very expensive and an unnecessary waste of money (G…
Earlier quoted context omitted.
This is what brought me to RoR land... and this is what made me leave. I agree rapid prototyping is an excellent point for RoR but when you need to actually evolve the project for years, it gets really tedious and hard. So for a dev shop RoR is quite fine -- you make the project, do very little iteration on it, and ship. That works well and I've experienced it. For longer-lived projects however, Phoenix is miles ahea…
What makes you say it is hard to maintain longer lived projects? (I used to be a RoR developer for a few years, so I'm curious about other people's experiences.)
With each new version of RoR gems just stop being compatible without replacement, and its a fairly significant effort to migrate everything to the new shiny being introduced. In fairly stable projects where there isn't much feature churn/replacement, you pretty much have entire sections of the codebase that never move past the version they were originally written in. You're constantly maintaining controllers/models written in RoR 3.2/4/4.2/5/5.1 styles since its incredibly difficult finding which features were used, but they still kinda sorta mostly work, until they silently don't.
The difference compared to other frameworks/languages is that Rails is very heavily powered by "magic". Every other tech explicitly configures and calls features being used, but Rails is mostly held together by "convention", but convention evolves. How do you search for things like "the filename of this must match the class name of this" or "the method name must match this database feature". Nevermind the metaprogrammed methods that aren't documented anywhere. The convention evolving as developer preferences changes is generally a good thing and keeps RoR from becoming too dated but it is an expensive maintenance burden.
I quite like Rails and it's still my first choice for personal projects/prototypes. But I'm definitely souring to it for long running professional work.
The obvious performance and bloat overhead with RoR aside, I have yet to see a framework and ecosystem that lets you have a programmable web application up and running with typical features in comparable time. For shipping new products or testing out ideas, I have not come across a more optimal framework in terms of going from idea to market. Most often I've tried Phoenix, Django and Laravel as alternatives, but all…
Earlier quoted context omitted.
I think there's a lot of burnout in the JS ecosystem, and many are looking for the efficiency of Rails. However, I'm not certain if Ruby on its own is gaining more of a foothold. For a few years it looked like you'd seen more Ruby generalists with tools like Chef and Puppet, but I think Docker has taken a lot of wind out of those sails.
And then Rails 6 came along and brought NodeJS by way of Yarn and WebPacks. I'm still pretty light on deep Rails knowledge (currently doing my first non-toy project with it), but I was not pleased to see that this pile of bloat now appears to be a requirement.
If you're interested in front-end performance, having a webpack build pipeline for your frontend assets is quite useful, especially if you want to leverage libraries like react or vue and build interactive reusable components, or leverage existing ones.
Tree shaking, minification, chunking, splitting, etc. will help you deliver a faster initial page load, which is a better overall experience and is also factor in search ranking for your public pages.
Front-end engineering has changed because users expect interactive experiences. Rails has an opinionated way to solve this differently using turbolinks and Rails UJS. A very significant proportion of folks don't want to go that route, enough for it to become the default.