bitblender

Plagiarism is theft because it does take something away from the original author (attribution). Plagiarism and piracy are different concepts. Making a copy and forking the code is not what they did wrong, that part was authorized. Deleting the author's name and pretending it was their original work is the issue.

I want to call my Uncle Steve in Melbourne. What time DOES THE SUN RISE there?

Google tells me it happens at 7:17am. It is currently 4:25am.

It's probably best not to call right now.

For starters, "the world is flat" is falsifiable and trivially disproven with evidence. "Dynamic types are better" is neither of these. If you're going to pin someone's professional value to a single technical opinion, you should at least be able to back it up with data.

Again, I don't mean "personal" in the sense that you are making a statement about someone's worth as a person. It's "personal" because you extrapolate information about an individual person's technical skills from a single opinion than you have any real factual justification to do so. People will always find ways to defy your preconceived notions.

It is "personal" if you attach someone's technical opinion to broader implications about their own competence. If you disagree with a technical opinion, say so and move on, there is no reason to even discuss someone's own personal skillset, experience, or value as a developer. It's a silly fallacy to automatically label people who disagree with you as incompetent. All it does is foster bias and stifle actual discussion. The responses to this post are evidence that this is not as cut and dry as the original posts suggests, so I suggest we try our best not to cover our ears and embrace tribalism just because we think less of someone's opinion. I don't think I'm being oversensitive by saying this is unproductive dogmatism. It is my honest opinion, yet I do not extrapolate to mean anything about the proponents' value as a developer. Unconscious bias is a pervasive problem for everyone, especially when it comes to binary holy wars like static vs. dynamic types. This is more akin to a builder who uses a nail gun rather than a hammer. Hammer enthusiasts can either acknowledge that both approaches have tradeoffs or they can petulantly insist that people who don't use their methods aren't "real" builders.

I don't consider it productive to be personal about technical topics. It's best to divorce yourself and the other party from the issue to limit as much bias as possible. You don't need to worry about the good-faithness of an objective, egalitarian discussion. It's never truly objective, but you can at least catch yourself saying things like "I might think less of you as a developer" and recognize that's a preconceived notion. In some cases, it may be turn out to be accurate, but it's definitely not always. Dynamically typed languages have had an important role historically in software. We should not categorically denounce people who prefer it as lesser developers. I also generally prefer static types.

Disliking async/await does not make someone "generally bad at programming". This is a childish ad-hominem mindset that has no place in technical debates. Rust's decision to adopt async/await over green threads was intended to keep the runtime lean, not because it is an inherently better abstraction. Java certainly could have async/await syntactic sugar around its existing futures api, but project loom has greater ambitions by retrofitting asynchronous IO onto the existing thread api. The authors are certainly not "simply wrong" for this decision.

I think your disagreements are valid, but I don't think it is fair to say this is an amateurish take or infer the author's level of experience. Your example of unnecessary inheritance hierarchies (which I have also faced many times in real world scenarios) may even be a symptom of exactly what the author is saying: what you might call a "bad fitting abstraction" the author would just call "bad code". The implementation details of how code gets shared (composition vs inheritance) is a subtle but still vital consideration to the cost benefit analysis. The author is observing that it might be misleading or dangerous advice to urge developers to choose duplication just because issues with abstraction have been historically observed, which I completely agree with and do not consider myself to be an amateur. I also agree with you and other posts that the author fails to mention the (exponentially higher) costs of abstraction boundaries that also span human organizational boundaries.

Bun is apparently targeting September 7th for a 1.0 release. I also have concerns about delivering a stable api using a language that doesn't have one yet.

That 'balance' is not for everyone - but crucially it is what some people want

I've never seen anyone that could sustain an 80+ hour per week grind and make it out without severe personal issues (whether they are willing to acknowledge it or not). I've seen many, many incredibly talented people burn out and suffer permanent health or career damage to hit their short-term goals. I personally know an otherwise healthy 30 year old swe who had a stress related heart attack. It may be what some people want but you can't grind your way out of being a human.

Is there a way to disable arbitrary I/O in macros? I would like to use this feature to compute lookup tables and inline the results of pure functions, but I really really do not want my bundler making arbitrary http calls or other sorts of nondeterminism. I need to be able to reproduce my bundles confidently.

Yes really. The fact that you can "often just return an object straight from the database" and have it fulfill the functional requirements of your client is just a coincidence, or more likely it's an invarient that you have decided to enforce. What people have discovered (usually very painfully) is that unavoidable breaking changes to either your client representation or storage representation are bound to happen, and when they do if you haven't separated these concerns this will have a ripple effect through the entire application. This may be fine. If your applications are tiny or downtime is okay, then you likely won't care about this. But to casually dismiss this advice as simply always being overcomplicated and overengineered is a grave oversimplification that you may regret someday. Many of the topics in this post fall into this category - people do it for a good reason, and you might not need it, but everything is a tradeoff and "I'm just going to do the stupid simple thing" is not the silver bullet.

In this case SignupRequest is your contract representation, Account is your storage representation, and the "backend code path" is the transformer/napping layer.

I don't have two representations of the same object. Rather I have two different object

Exactly! Your api contract and your storage are ALWAYS two different objects, because they serve two different concerns. Sometimes by coincidence they can share the same shape but there's no reason that they need to be coupled together and impossible to change independently, other than the fear of inconvenient "boilerplate" mapping logic. By doing this up front, and not even letting it enter your data model, you create a formal abstraction boundary; it's reserving the right to change two pieces of data independently. Also, mapping/transformation logic can often just be simple, pure, total functions; which are trivial test and maintain compared to anything that touches I/O.