While some people are hard lined enough on their anti-ORM stance that it sort of becomes weird, I agree with you that my beef with ORMs comes from being burned before a couple of times by a super inefficient aggregation ActiveRecord did on GROUP BY queries that it 1. not only took a really long time to figure out why a particular page in our app was loading slow but 2. we ended up having to write raw SQL to fix it.

I think the answer of whether to use one depends on the type and load/volume of app you're working with combined with the dynamics, size, and skill level of your team(s). I'm extremely comfortable writing, profiling, query planning, and debugging SQL queries. Others aren't, and therefore having an ORM to query data in the DB with the syntax of the language you're using in your projects makes way more sense, if nothing other in order to speed your team up.

Not sure when you used ActiveRecord, but slow query logging helps a lot to identify these issues. I also appreciate that in the docs for ActiveRecord they make it very clear that jumping to raw SQL is absolutely fine and normal, and they make the interface for doing that very nice.

While some people are hard lined enough on this that I agree it sort of becomes weird, I can tell you my beef with ORMs comes from being burned before a couple of times by a super inefficient aggregation ActiveRecord did on GROUP BY queries that it 1. not only took a really long time to figure out why a particular page in our app was loading slow but 2. we ended up having to write raw SQL to fix it.

I think the answer depends on the type and load/volume of app you're working with combined with the dynamics, size, and skill level of your team(s). I'm extremely comfortable writing, profiling, query planning, and debugging SQL queries. Others aren't, and therefore having an ORM to query data in the DB with the syntax of the language you're using in your projects makes way more sense, if nothing other in order to speed your team up.

I think the mistake is thinking an orm is actually going let you be free of knowing or caring database fundamentals. That only applies in the most simple cases. An orm has other benefits though.

1. Don't rename your columns, but if you have to

2. project search and replace on $COLUMN_NAME

If your column name is a common keyword, variable name, etc. in your code base and it's difficult to find using project search, that's unfortunate, but we organize our backend code and tests in a logical enough way that it's never taken longer than an hour to create a PR to create a migration to rename a column and update all places in code that reference it.

Renaming a column is an operation which showcases the weakness in not using an ORM. Other operations of the sort do exist, anything that operates on columns across multiple arbitrary spots in the code.

IMO an hour for a change you have so little confidence about is not acceptable when the alternative allows you to do it in a second with full confidence.

While this is fair and I don't disagree that changing a column name or possibly other schema changes using an ORM and it's subsequent migration scripts is potentially going to be a faster exercise than without one, changing a column name (or any schema change for that matter) in a database in my experience is rare. If you choose to use an ORM for reasons like it might (emphasis on might) be a bit faster and easier to change a column name than without one instead of for other more meaningful people or efficiency-oriented reasons of the day-to-day developer workflow is probably a poor approach.

Keep in mind I've installed and used an ORM in projects where the ORM is used only for migrations, but not used in application code and this is absolutely a fine reason to use one imo. But adopting an ORM for migration purposes and forcing or using in application code simply because it's installed isn't necessarily a good approach.

This is a very simplistic view of the situation.

ORMs have very basic support of current SQL standards and database specific features.

This means that using an ORM reduces the power of the database choice you made.

Also things like arbitrary SQL support imply you have to manually creat return value typings.

Having to leave the nice ORM wrapper functions for arbitrary SQL means you lose all the ORM niceties like soft deleted or updated_at fields

Overall I see very little use for ORMs.

While this is true, I've found over time it's easier for me to quickly see in my code if I need to `await` on something if the function is an `async` function and not just that it returns a Promise.

I prefer

async function foo() { return await new Promise(...) }

as opposed to

function foo() { return new Promise(...) }

They're the same thing for the most part but the latter I have to potentially dig deeper into the function to confirm it returns a promise compared to the former.

The problem is that this is more than just a syntactic difference. There's a chance it will take two ticks to resolve instead of one.

For documentation purposes, I recommend block-commenting the `async`:

const foo = /async/ () => new Promise(...);

I did not know this and appreciate the insight! Will definitely store this back of mind and try and remember to use block comments when needing to explicitly return a promise.

That's not true if you just return the promise instead of using return await, right?

No. `async` on a function automatically defers it even if the return value is immediate.

> async function foo() { return "hello"; } foo().then(console.log); console.log("after")

after hello

I think it's necessary to put emphasis on the "get-rich-quick schemes" part, and not the "blockchain/cryptocurrencies" part.

I hope you're not implying blockchain tech and all cryptocurrencies don't/can't provide real utility value, but if so I beg to differ substantially. I built a hook to the Stellar blockchain to store SHA256 hashes of audit evidence that can be validated against at a later time as tamper-proofing evidence. This is just one extremely simple use case, not to mention the entire Defi ecosystem that's being developed as we speak.

I am absolutely implying that blockchain tech is fundamentally useless, and cryptocurrencies doubly so.

Depends how you define useless. They're pretty good at demonstrating what happens when the immature, privileged assholes of this world run amok with shitty ideas, devoid of any true foresight or reflection.

They're also pretty good at demonstrating how a borderless financial system can facilitate innovation and development whilst retaining IP without VCs (Aave, Uniswap).

Now all we need is the autogenerated whitepapers.

A bold statement is expected to have an argument. A trustless, censorship-resistant ledger is fundamentally useless? Come on.

The tamper-proof timestamping has been around for a long while - there are many timestamping servers which sign hashes using a simple protocol [0][1]. Get a signature from a few servers in different jurisdiction if you are worried that one will get compromised.

This is one of the reasons I don't like the blockchain hype -- people have real problems. Instead of choosing existing simple and reliable solutions -- TSA, CT-style logs[2], people go with the blockchain stuff which directly powers cryptolockers, ponzi schemes, and other crime.

Yes, I know cryptolockers don't use Stellar... but most people don't -- and they see posts like yours as a justification that to put their life savings into another scam.

[0] https://www.freetsa.org/index_en.php [1] https://gist.github.com/Manouchehri/fd754e402d98430243455713... [2] https://certificate.transparency.dev/howctworks/

Tamper proof timestamping is just a small part of blockchains and they exist in parallel with different security guarentees.

Blockchains aren't going to dissappear so in my mind the only good solution is to educate instead of fear monger.

Why not use Twitter or GitHub instead?

So you don't need to put your trust into all the people that have or could gain write access to their databases?

Lastpass is centralized so if they get breached your info will as well. This is a tool where you can use and write your own connectors to store you account info (w/ AES-256 but encryption) wherever you want with control in your hands.

This inspired me so I will find more time to do this as well. Went ahead and started at one of my favorite projects that I use across several professional and personal projects :)

https://github.com/actionhero/node-resque/issues/496

Thank you!

I guess I’ll chime in and say - as an OSS maintainer, please flood my inbox with messages like this. It really makes my day!

I've used the Night Eye Chrome extension for a white and it does a great job of converting any website/web app to dark mode.

So

1. I’m glad this is the most upvoted comment in order to provide visibility and

2. I’m glad the founder wants to make it right apparently by having the alleged freelancer send details to rectify

but the the fact that the founder doesn’t immediately refute that this occurred and only wants to now potentially make it right by having the freelancer send his details over to get paid is very troubling for me. I hope this comes out as a false allegation but if not I wouldn’t want to support this at all.

Imagine if they did immediately refute that this occurred. Wouldn't you be more suspicious of the defensiveness?

A: five years ago you made a pretty bad mistake that hurt me personally.

B: I must have let my priorities slip, and it sounds like in my oversight I hurt you personally. Reach out with more details and we can make this right.

or

A: five years ago you made a pretty bad mistake that hurt me personally.

B: I don't really make mistakes like that.

> I must have let priorities slip

saying a metaphorical “fuck you, I can’t pay you for the work you did for my business” by ignoring OPs alleged many emails and correspondence to get compensated is just as bad if not worse than a literal “fuck you, I can’t pay you” imo, but I’m also one that appreciates honesty and not sketchiness or being ghosted even if the outcome is not in my favor.

So, I just checked. We have easily engaged upwards of 500 freelancers over the last 8 years. Not possible to personally keep track. If something has slipped by, would like to know and rectify.

The problem is though that it didn’t just “slip by” if OP tried to contact you/your team through various channels (email, whatsapp) for weeks as he says. This was either a complete mistake (ie OP didn’t do work for you) or a purposeful, coordinated effort to prevent paying OP (and I imagine others).

Your character is at stake here and again, a sleezy ghosting for years is almost certainly worse I assume for most people than a phone call, email, whatever to tell someone you unfortunately just can’t afford to pay them right now but will as soon as you can. That’s the biggest issue here.

> Your character is at stake here and again, a sleezy ghosting for years is almost certainly worse I assume for most people that a phone call, email, whatever to tell someone you unfortunately just can’t afford to pay them right now but will as soon as you can. That’s the biggest issue here.

Why would you assume for there to be no proper conclusion? It is not like running away from the truth helps anyone. Is it not obvious that anyone would inform of payment delays, non-payment against dissatisfactory services, etc? What’s there to gain by not informing? It is not like these things don’t happen, because they do happen. Often more times than you did like.

I would like to take this claim at face value and just assume it to be true that a payment was not made. If its a troll, it would be a really sad one. Going forward under this assumption, the freelancer certainly thinks that he/she should have got paid for the services delivered. This is where a communication gap could exist. I highly doubt we have not properly closed an engagement. It is more likely it was closed against the interest of the freelancer, and the freelancer won’t take NO for an answer, and is now making a claim under an incorrect pretex.

What would you advise as the best course of action in such a scenario?

> Why would you assume there is no proper conclusion

I wouldn’t and am not. It’s your responsibility to confirm one way or the other.

If this is a case of a disgruntled freelancer who isn’t getting more than what he/she wants even under a contractual and agreed upon arrangement, then I’ll gladly retract from my former concerns and sincerely apologize for my personal issues towards the matter.

But if this is almost literally anything else where the freelancer did work and wasn’t compensated under the terms of a contractual agreement, I will hold up my concern and maintain my disdain towards the matter.

Absolutely agree with you. We are on the same page here.

From someone who is working on a couple of now larger Typescript apps (both frontend and backend) I’ve began noticing compilation take long enough that I have a currently low hanging (but will obviously increase in priority) TODO to go through and refactor to improve compilation speed. I wouldn’t know how to google for this other than using the word “performant”. Although I realize in most cases performance specifically deals with production execution and what end users experience/perceive, I at least believe performance is not incorrect to describe what the author is helping with here.

> TODO to go through and refactor to improve compilation speed. I wouldn’t know how to google for this other than using the word “performant”

But you already used the words naturally in your sentence, "compilation speed". A quick google search brought up lots of useful results with 'typescript compiles slow', 'typescript compile faster', etc.