4 ms·

> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazi

by SPBS 6y ago

> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now it can happen with frameworks too. Is the author calling Rails as 'lock-in'?

eloff 6y ago
It is no? It's not easy to rewrite into something else if you need to. With rails the biggest reason you might need to do that is the abysmal performance. You need twenty servers to do the work you could have done with one.
__jem 6y ago
Is it not? Even if it's open source, I would view monolith frameworks as a form of ecosystem lock-in. We use Spring at work and I would certainly describe us as suffering from "lock-in" to the Spring ecosystem.
- mewpmewp2 6y ago
  In which case are you not going to lock in building something like that? Even if you opt to go framework-less you are now locked in to whatever you are building.
  - codingdave 6y ago
    This is somewhat true, but that is why separation of concerns is a best practice. Maybe you do have one piece of the stack "locked in" to Rails, but the rest of the stack can stay in place if you want to move from Rails to a different framework.
    - Tainnor 6y ago
      In Rails, this is unfortunately somewhat difficult (though not impossible) to achieve due e.g. to the autoloading magic that Rails adds and that can make isolating library code a bit more challenging if you're not aware of some intricate details of Ruby's and Rails's loading behaviours.
  - gshulegaard 6y ago
    Not quite the same. I moved away from Django some years ago when I ran into a bug that I traced back to the Django ORM. At the time it was neither obvious to fix nor easy to replace the Django ORM with something like SQL Alchemy. It’s not necessarily about avoiding rewriting entirely, but rather minimizing the amount of rewrite required if you have to improve, change, or fix something. If your roadblock is in the framework, the bigger the framework, the more you have to rewrite.
nahname 6y ago
It's hard not to become jaded when every framework turns out to be just another team's personal preferences. I would say the statement is generally true about frameworks, but not true about rails. Perhaps the author did not spend enough time with rails.
- BossingAround 6y ago
  > It's hard not to become jaded when every framework turns out to be just another team's personal preferences. Isn't that a definition of a framework? A more or less opinionated way to structure a particular type of an application?
  - nahname 6y ago
    Too many are... Some are built upon a novel ideas though. Can we build web apps like desktop apps? Can we use one language on the frontend and the backend? Can we write everything in java? Rails was built upon the novel idea of, "Can we build a CRUD app framework developers enjoy using?". As there is no silver bullet, this comes with tradeoffs many do not want. Performance is not a first class citizen. Code is prescriptive. A lot of rails apps are just gluing together gems. I will say though, if you are building a CRUD app. There is no other option that will get you to done faster than rails.
- horsawlarway 6y ago
  Having spent time with Rails, I'd say you're biased. I went from a dotnet shop to a rails shop, and despite the attitude that Rails is "marvelous", I can't help but feel like Rails is the bastard child of ASP.net. It feels incredibly similar to working within the constraints of ASP - the framework knows best. Don't questions their choices. Don't do it any other way. Lock yourself into their good choices. Their choices turn out not to be great for your use case? Fuck off. Compounded by the fact that Rails is currently in the same death spiral dotnet was before scrapping everything and releasing dotnet core - Rails is great in v1. Rails is much less great in v6, where documentation is shoddy, splintered across versions, there are 5 ways to do anything, but god help you if you don't know the most recent incantation. Memorize all of our conventions, but hey - best practices have changed like 6 times in the last 10 years, so our conventions from yesteryear don't apply, and no, we won't update our documentation and stack overflow answers are bad/outdated. Basically - Coming in from all sorts of other languages and frameworks I've used in prod (Golang, Dotnet, Dotnet Core, Node, Ts-Node, Rails, PHP, etc) Rails is currently sitting in my shitlist.
deleted 6y ago
[deleted]
steve_adams_86 6y ago
I saw a reference to Ruby, but not Rails. Are you inferring Rails from the mention of Frameworks towards the end?
swyx 6y ago
yes, but lock-in can be worth it, and Rails is increasingly worth it as the ecosystem and core grows. i wish we had an alternative term to "lock-in" that had more neutral instead of negative connotation. it's got tradeoffs, like with anything, but doesnt mean we gotta be scared of it.
imhoguy 6y ago
> Is the author calling Rails as 'lock-in'? I read '5. Beware of Lock-In' section as "be generalist". It looks to me as generic career advice to not stay fixated to single all-in-one tech choice and role - SAP dev, Ruby dev etc. Ruby is just an example here ('even', 'frameworks too'), I guess the author witnessed the "rockstars" and evangelists hype wave of RoR circa 2005-2010. Possibly it could be e.g. ReactJS or Kubernetes today too.

by SPBS 6y ago

eloff 6y ago

It is no? It's not easy to rewrite into something else if you need to. With rails the biggest reason you might need to do that is the abysmal performance. You need twenty servers to do the work you could have done with one.

__jem 6y ago

Is it not? Even if it's open source, I would view monolith frameworks as a form of ecosystem lock-in. We use Spring at work and I would certainly describe us as suffering from "lock-in" to the Spring ecosystem.

mewpmewp2 6y ago
In which case are you not going to lock in building something like that? Even if you opt to go framework-less you are now locked in to whatever you are building.
- codingdave 6y ago
  This is somewhat true, but that is why separation of concerns is a best practice. Maybe you do have one piece of the stack "locked in" to Rails, but the rest of the stack can stay in place if you want to move from Rails to a different framework.
  - Tainnor 6y ago
    In Rails, this is unfortunately somewhat difficult (though not impossible) to achieve due e.g. to the autoloading magic that Rails adds and that can make isolating library code a bit more challenging if you're not aware of some intricate details of Ruby's and Rails's loading behaviours.
- gshulegaard 6y ago
  Not quite the same. I moved away from Django some years ago when I ran into a bug that I traced back to the Django ORM. At the time it was neither obvious to fix nor easy to replace the Django ORM with something like SQL Alchemy. It’s not necessarily about avoiding rewriting entirely, but rather minimizing the amount of rewrite required if you have to improve, change, or fix something. If your roadblock is in the framework, the bigger the framework, the more you have to rewrite.

nahname 6y ago

It's hard not to become jaded when every framework turns out to be just another team's personal preferences. I would say the statement is generally true about frameworks, but not true about rails. Perhaps the author did not spend enough time with rails.

BossingAround 6y ago
> It's hard not to become jaded when every framework turns out to be just another team's personal preferences. Isn't that a definition of a framework? A more or less opinionated way to structure a particular type of an application?
- nahname 6y ago
  Too many are... Some are built upon a novel ideas though. Can we build web apps like desktop apps? Can we use one language on the frontend and the backend? Can we write everything in java? Rails was built upon the novel idea of, "Can we build a CRUD app framework developers enjoy using?". As there is no silver bullet, this comes with tradeoffs many do not want. Performance is not a first class citizen. Code is prescriptive. A lot of rails apps are just gluing together gems. I will say though, if you are building a CRUD app. There is no other option that will get you to done faster than rails.
horsawlarway 6y ago
Having spent time with Rails, I'd say you're biased. I went from a dotnet shop to a rails shop, and despite the attitude that Rails is "marvelous", I can't help but feel like Rails is the bastard child of ASP.net. It feels incredibly similar to working within the constraints of ASP - the framework knows best. Don't questions their choices. Don't do it any other way. Lock yourself into their good choices. Their choices turn out not to be great for your use case? Fuck off. Compounded by the fact that Rails is currently in the same death spiral dotnet was before scrapping everything and releasing dotnet core - Rails is great in v1. Rails is much less great in v6, where documentation is shoddy, splintered across versions, there are 5 ways to do anything, but god help you if you don't know the most recent incantation. Memorize all of our conventions, but hey - best practices have changed like 6 times in the last 10 years, so our conventions from yesteryear don't apply, and no, we won't update our documentation and stack overflow answers are bad/outdated. Basically - Coming in from all sorts of other languages and frameworks I've used in prod (Golang, Dotnet, Dotnet Core, Node, Ts-Node, Rails, PHP, etc) Rails is currently sitting in my shitlist.

deleted 6y ago

[deleted]

steve_adams_86 6y ago

I saw a reference to Ruby, but not Rails. Are you inferring Rails from the mention of Frameworks towards the end?

swyx 6y ago

yes, but lock-in can be worth it, and Rails is increasingly worth it as the ecosystem and core grows. i wish we had an alternative term to "lock-in" that had more neutral instead of negative connotation. it's got tradeoffs, like with anything, but doesnt mean we gotta be scared of it.

imhoguy 6y ago

> Is the author calling Rails as 'lock-in'? I read '5. Beware of Lock-In' section as "be generalist". It looks to me as generic career advice to not stay fixated to single all-in-one tech choice and role - SAP dev, Ruby dev etc. Ruby is just an example here ('even', 'frameworks too'), I guess the author witnessed the "rockstars" and evangelists hype wave of RoR circa 2005-2010. Possibly it could be e.g. ReactJS or Kubernetes today too.