6 ms·
What language and/or framework doesnt have this problem? - Ruby - if your Ruby/Rails app falls behind, you will be paying back debt to get it up to date - PHP
by jmondi 3y ago
What language and/or framework doesnt have this problem?
- Ruby - if your Ruby/Rails app falls behind, you will be paying back debt to get it up to date
- PHP - if your Laravel/CI/Cake/Slim/Symphony App falls behind, you will be paying back debt to get it up to date
- Go - if your Go app falls behind, you will be paying back dept to get it up to date
- Python - if your Django app falls behind, you will be paying back debt to get it up to date
- Elixir - if your Phoenix app falls behind, you will be paying back debt to get it up to date
- icedchai 3y agoI have 10+ year old sites on PHP 5 and Laravel 4.x that the client doesn't want to pay to upgrade.
- 2023throwawayy 3y agoI have CakePHP code bases that are over a decade old and still run fine. Go is backwards compatible.
- potta_coffee 3y agoI have years-old Go code that just keeps running. PHP is very stable. I've found Python to be a PITA sometimes. Javascript rots faster than anything else I've encountered.
- the_gastropod 3y agoOf course any system will require maintenance. The question is more about the significance and frequency of the maintenance required. You can take a Ruby on Rails app from 2005, and it will mostly look the same as a 2023 Rails app. You'll need to update some gems, use the newer routing DSL, and update the environment configs. But that's pretty much it, after nearly 2 decades. Contrast that to a React app written 5 years ago, where you'd pretty much need to completely rewrite everything (class components => functional, use hooks instead of callback methods, etc.)
- jmondi 3y agoA React app can be written in 2023 the same exact way it was written in 2016. You don't need to use hooks. React has literally barely changed at all since its creation. Hooks are a choice. Function components are a choice.
- robertoandred 3y agoNo don't you see, it's their preferred language so its maintenance and churn don't count.
- jmondi 3y ago10000% this.
- tl 3y agoAll 5 of those age better than React. Also, you are conflating languages and platforms. Counterexamples / Retorts: - https://catonmat.net/5-best-programming-languages https://catonmat.net/5-best-programming-languages - https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ Choose ecosystems free of hamster wheels, friend.
- Daishiman 3y agoAs someone with over a decade of Django experience, _very little_ has changed in Django since it started; you can bring up a very old app to speed in a matter of a couple of days. I've had to spend a week moving a 3 year-old React app to the latest versions and failed because certain dependencies were just a mess.
- kerkeslager 3y agoHaving spend over a decade in Python backend/JS frontend ecosystems at this point, I can confidently say from my experience that Django backends are much easier to update than React frontends. If you import every bleeding-edge nonsense through pip that you can, there can still be problems, but Python has a better culture around this, so it's usually easy to steer teams away from doing this. In JS, importing every bleeding-edge nonsense through npm that you can is the only culture I've found, and this problem is pervasive enough that even guarding your direct dependencies doesn't isolate you from it, since your dependencies are likely to introduce bad dependencies of their own.
- jmondi 3y ago"I like python because I picked python." Literally not one argument here that makes any point.
- DangitBobby 3y agoI've just updated a codebase from Django 3 to 4, about to do another one. It took very little time, with 0 breaking code changes and a mandatory postgres update to 12+. Even going from pandas 1->2 and celery major version bump (5, I think) caused 0 problems. Mature codebases like these tend to be careful about backwards compatibility.