3 ms·
Yes, me too. But it makes absolutely no sense business wise. We like to play with tech, and learn and use the new shinny. While you're writing your frontend in
by midrus 5y ago
Yes, me too. But it makes absolutely no sense business wise. We like to play with tech, and learn and use the new shinny. While you're writing your frontend in elm and building your graphql API with Apollo and your serveless functions on kubernetes your causing a cost to your company which could have been avoided.
That's not engineering. That's playing with Legos just because we can.
- treis 5y agoI don't think this is a fair characterization of their post. They aren't playing with legos. Rails trades boilerplate code savings for abstraction. The GPs point is that boilerplate isn't hard to write while abstraction makes everything harder. And I think it's a fair criticism. Large Rails projects are difficult to work in because of that abstraction. It can be hard to even figure out what code is running let alone identifying bugs there.
- waffle_maniac 5y agoThe abstraction hasn’t hindered me much and I work on a monolith. One problem I have faced is when the amount of database queries on a page explodes it becomes hard to optimize without caching. I would prefer to avoid caching but that doesn’t appear to be the rails way (and for obvious reasons). Also, at a company with a Rails app you do sometimes get other sources and processes polluting your Rails app. And when that happens you can’t utilize the efficiencies that rails provides.
- quesera 5y ago> Large Rails projects are difficult to work in because of that abstraction. It can be hard to even figure out what code is running let alone identifying bugs there. I read this a lot, but I have never experienced it, even on projects that I have joined after they were already huge. Rails conventions are pretty reliable. Most Rails developers choose predictable patterns that resemble the framework conventions. Obviously people coming from other frameworks will often build things differently (sometimes fighting Rails to do so), but a few minutes in the REPL makes everything clear.
- Fire-Dragon-DoL 5y agoThrow a junior rails developer in a big app and let them work. Is shocking the amount of overhead we get used to as Rails developers. You get used to it, but it shouldn't be like that
- quesera 5y agoI think this is a universal truth, with nothing specific to Rails. What framework/language/environment can you think of where a junior dev can be dropped in to a big project, and not flounder?
- Fire-Dragon-DoL 5y agoIt's probably a problem related to any framework with a lot of magic. With Go and Phoenix, this problem is not there. They are very explicit, so when something unknown is found, it's written there what it does. With rails there are things going on at all time: write a record? Some stuff is written on the db, other stuff is triggered, some stuff depends on thread variables, then other stuff is magically saved in other tables, other is updated (touched), which in turn might trigger more things. It is painful for a new developer because all of this happens implicitly.
- quesera 5y agoComing from a systems background, I might have a higher tolerance for "implicit" actions. They're always there, and almost never covered in code, although your code depends on them to function. But I think I understand your point. You can ask a neighbor to "run to the market to get bread and milk" and expect reasonable results -- but you'll need to be more explicit with a foreign visitor. Rails optimizes for neighbors, but in fairness the phrasebook and guidebooks are excellent. :)
- Fire-Dragon-DoL 5y agoThey are, indeed
- midrus 5y agoThe complexity is still there even with microservices or a Go or a Clojure codebase, it's just that either you've created a mess or you've created your own framework. In my experience, you either use one of these big frameworks, or you end up building one. I've seen that happen more than once, and these "home made frameworks" are far worse, less documented, more buggy and have like 6 different patterns depending which generation of developers before me built it (and of course, I had left own opinions and mistakes too). Writing microservices in Go or Flask or Sinatra won't make all the complexity related to the Web go away magically. The're still there. Now they're distributed across services and implemented mostly from scratch. If you are not FAANG and don't use one of these big frameworks, you have only two options: 1. Create a distributed spaghetti mess of random libraries tied together 2. Build your own "big framework". I've been many times in companies which were through the process of breaking up the monolith into separate services. It never finished, and every single service was just a proxy to the monolith, and everything took twice the time to implement, and now both all the services and the monolith have to be kept running and maintained. The only "positive" was the group of devs that wanted to play with new tech and somehow managed to become a team that only works on one of those services, so now they're "free" from the monolith hell. Business wise it was a disaster, would have been better to just let those engineers find another job with the tech stack they preferred and hire new ones willing to work on a single codebase and keep things simple. Again, this was not a Google scale company, these were 50 ~ 100 engineers organizations.
- deleted 5y ago[deleted]
- Fire-Dragon-DoL 5y agoHow can it not make sense, if when there is an issue with devise, then it takes weeks to debug vs 1 day with the handrolled code?