51–60 of 79 posts
Earlier quoted context omitted.
I don't know why something with many LOC is a problem. Why does OP care about LOC?
More code, more liability. If you can get away with achieving the same with less code, things tend to be harder to turn into big messy piles of code.
Earlier quoted context omitted.
I don't know why something with many LOC is a problem. Why does OP care about LOC?
More code, more liability. If you can get away with achieving the same with less code, things tend to be harder to turn into big messy piles of code.
Do you have the same concerns about your compilers? Your web servers? "More code, more liability" is a very sloganeering/cargo-cult take.
I like Ruby but I don't like Rails. No idea if this is better now but I would get weird exceptions that would be from metaprogramming goofiness that was really difficult to debug and find documentation for, and it uniquely bothers me when I can't figure out where errors are coming from in code (same critique of async/nodejs). The general heaviness also just didn't mesh well with my programming style, I like things cl…
Earlier quoted context omitted.
> What do you mean by "heavyweight"? Rails latest release (7.0.4) have 386,970 lines of code in total, 310,779 of it being Ruby code. 3000 files in total. Just the `lib` directory of `activerecord` has 33,036 lines of code, across 369 files. By most metrics, RoR is pretty heavyweight, as their literal taglines are "Ruby on Rails scales from HELLO WORLD to IPO" and "A web-app framework that includes everything needed…
> By most metrics, RoR is pretty heavyweight, as their literal taglines are "Ruby on Rails scales from HELLO WORLD to IPO" and "A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern", so it needs to be pretty big to support those use cases. Not sure what do you mean by "most metrics". Framework supporting features is not sam…
Maintaining a Postgres server or cluster is hard. But it offers way more functionality.
I agree that the term heavyweight can mean many things to people. I’ve take it as a generic mix of maintenance, complexity of project, ease of use for your purposes.
Earlier quoted context omitted.
> What do you mean by "heavyweight"? Rails latest release (7.0.4) have 386,970 lines of code in total, 310,779 of it being Ruby code. 3000 files in total. Just the `lib` directory of `activerecord` has 33,036 lines of code, across 369 files. By most metrics, RoR is pretty heavyweight, as their literal taglines are "Ruby on Rails scales from HELLO WORLD to IPO" and "A web-app framework that includes everything needed…
> By most metrics, RoR is pretty heavyweight, as their literal taglines are "Ruby on Rails scales from HELLO WORLD to IPO" and "A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern", so it needs to be pretty big to support those use cases. Not sure what do you mean by "most metrics". Framework supporting features is not sam…
Yes. There’s not a definition of “lightweight” that could be applied to psql, at least without making the word useless.
The whole service (which isn't too complex) is a file script in Ruby managed through SystemD. This script turns off/on the screen based on API calls, and is also in charge of scheduled/remote restarts, pinging the backend and stuff like that.
What I like the most is how easy and reliable is. Beeing a below average guy, ruby makes really easy to combine system calls, API calls and shell commands within the same context.
Ruby is pretty good for writing scripts to run in the terminal. For things where I need to do a bunch of string manipulations, I prefer it over something like creating a shell script.
We have a lot of internal APIs written using Sinatra. I first started writing my APIs using Sinatra about 10 years ago. I had started with Rails when it first came out around 2005, liked it, but then ran up against a lot of issues. Sinatra and the Sequel gem were amazing so I switched to that, since I didn’t need most of what Rails had. Now I just use those two out of habit. Rails is a LOT better now, but i still jus…
I really like Sinatra but a lot of the Rails improvements kind of took away some of the benefits of using Sinatra over Rails.
I started with Rails when migrations were just .sql files you wrote by hand. I switched to Sinatra mostly to use Sequel, because ActiveRecord at the time would do horrible queries unless you wrote them by hand. I know they have solved that issue, so I should try Rails again… but my Sequel muscle memory is pretty strong at this point.
Earlier quoted context omitted.
More code, more liability. If you can get away with achieving the same with less code, things tend to be harder to turn into big messy piles of code.
This is a real inexperienced take about a codebase with a huge number of contributors and users, with a lot of test coverage, that has a history of addressing P0/P1 issues quickly. Do you have the same concerns about your compilers? Your web servers? "More code, more liability" is a very sloganeering/cargo-cult take.
I’m currently down with the Flu B, so don’t feel like looking up citations, and for that I apologize. My recollection is that this was, unsurprisingly, a fluid estimated, with lots of caveats attached to it. Regardless, it struck me as true, and something I’ve never failed to take into consideration when writing my own code.
Earlier quoted context omitted.
> By most metrics, RoR is pretty heavyweight, as their literal taglines are "Ruby on Rails scales from HELLO WORLD to IPO" and "A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern", so it needs to be pretty big to support those use cases. Not sure what do you mean by "most metrics". Framework supporting features is not sam…
yes is heavyweight, SQLite for example isn't , but is kind the point you want database to use multiple formats, have acid compliance, json support, parallelism, easy debuggability, scalability, fault tolerance. this are problems that you pay only little cost because 1 PostgreSQL database can scale to thousands or millions of users, and is more like a video editor you doesn't code directly in it, and data replication…
Suggesting that LOC does not support this argument, and perhaps is not a great metric in general, especially across different languages.
https://www.sqlite.org/amalgamation.html (as of Version 3.37.0 - 2021-11-27)