nercury

I hope the wages of sales people are lower than that of a calculator.

Extremely small island that stretches from New York to Atlanta..

If someone spent their time learning their tools, they will make better choices when writing the code without any additional time cost.

There are two variants of very similar code. Both do the same thing, both are readable and maintainable. The difference is not primarily in performance, it's in quality of craft.

Anything you say or do will be used against you by any future government. What's legal now, might not be legal tomorrow, and you will be jugged by your AI "friend". Welcome to dystopia.

The real threat is AI arguing/competing with itself and wasting 90% of world's power.

This is more of a preference for bridge to be visible in application. Also the bridge may seem simple at first, but it also may gain associated data, like created_at, order, etc.

Yes, I would not put it just anywhere. But I have few rules about ORMs:

- Proper DB design first. You should be able to remove the ORM and DB should still function as intended. This means application-side cascade operations or application-side inheritance is banned.

- No entities with magical collections pointing to each other. In other words, no n to n relations handled by ORM layer. Create in-between table, for gods sake. Otherwise it becomes incredibly confusing and barely maintainable.

- Prefer fetching data in a way that does not populate collections. In other words, fetch the most fine-grained entity and join related data. Best if you craft special record entities to fetch data into (easy with EF or Doctrine).

- Most ORMs allow you to inspect what kind of queries you create. Use it as query building tool. Inspect queries often, don't do insane join chains and other silly stuff.

I would use ORM in one kind of app: where I would work with data that shares records that might need to be either inserted or updated, and there is several nesting levels of this kind of fun. You know, you need to either insert or update entity, if it exists, you should update, and then assign related entities to it, if it does not, then you should insert, and assign related entities to the newly created id. The ORM can easily deal with that, and on top of that it can do efficient batched queries, which would be really annoying and error-prone to hand-craft.

If the app does not require this kind of database with these kind of relations, I would not use ORM.

Yeah, in a web app, one context per request. In desktop app... I have never used EF there.

Pardon me for the tangent (just a general comment not directed to OP).

What I have learned over the years is that the only way to properly use ORM is as a fancy query tool. Build the query, fetch/update data, MOVE THE DATA to separate business objects. Don't leave ORM entities shared across the sea of objects!

Phew, thanks, I got that off my chest.

struct Node<'a, 'b, 'c> { data1: &'a Data data2: &'b Data data3: &'c Data }

Wow. It's like teaching C++ and starting from SFINAE. Or C# and starting from type parameter constraints.

Please think of a real-world examples when teaching stuff. I am very eager to see the program a beginner would need to write that requires: 1) references in a struct; 2) 3 separate lifetime parameters for the same struct.

It's like destroying a factory when the chips it produces do not sell.

Corporate prioritization is the ultimate cookie cutter, doomed to produce the most generic thing possible.

If AMD did not come up with 64-bit extension, we would be saying goodbye to x86 architecture.

This sounds like "You aren't having fun properly".

That disappearing scrollbar is weirdly out of place.

Yes of course. You have to demonstrate that you are very skilled at building with the particular bricks they use. Don't mention anything else to show your commitment to particular brick usage.

Right, imagine a company where the team decides to use Macromedia Flash for game UI only because they need to deliver something working on the next sprint. And then everyone gets stuck with that decision for more than a decade.

Say, you use the same foundation for both the game and tool. Nothing prevents you from building features on top that are optimized either for a tool or for a game! Plus you dogfood the system all the time.

Bytes aren't bricks. Reshuffling them from scratch after a smallest change is cheap and fast. Taking advantage of that is not stupid. Proper communication and work with client is a skill, and architects have to deal with stupid requests too!

If's fun little article, but is a bit short-sighted. Probably because otherwise it would not work.

Interesting, it acts as if hearing voices in the head.

It pains to see the need for a microservice to even start thinking about system architecture. As if the additional database and additional set of classes could not be done on the same instance. And then everyone shrieks in pain when they see the monthly costs :)

I admit I don't know enough about kernel development, but from general experience one common example is resource cleanup.

Say, you have several resources that must be cleaned up in certain order. In C, you would just call the appropriate free functions. When abstracting over that with rust, you have to make an annoying choice:

Do what's in C, don't implement automatic Drop, but mark your functions unsafe. You get leanest zero-cost implementation, it is straightforward to understand, but needs additional maintenance care to prevent bugs.

Wrap resources in unsafe structs that have automatic drop (when goes out of scope). IMO this is a terrible choice, because the maintainer suddenly has to know about which structures have this unsafe cleanup going on. Simple scopes suddenly matter, order of items suddenly matter, it's a mess.

Use reference-counting wrappers to track usage and drop the items when they are no longer in use. Most libraries do this, but it's no longer the leanest possible API.

There might be another choice, to achieve both zero-cost execution and correct cleanup using metaprogramming, be it macros, generics, or both. That's exactly what I fear the most.

I am Rust developer. My advice: favor less abstractions. Especially when interfacing with C, you can always make almost 1:1 rust interface. Start with that. Then, when common patterns start to emerge, do the data abstractions first, i.e. define data structures shared by different implementations.

There is no reason why you can't write simple code in Rust. Well, except that it's tempting to over complicate things. Start using traits and generics everywhere, and you will enter meta-programming in generics hell. Soon after, you will start demanding new compiler features to survive there.

I would argue that the bloat comes when the performance impact is not perceivable compared to the development time.

The easiest optimization strategy is just to load it all up into the memory. Compare that to other strategy like catching partial file data, and it's obvious why the simpler solution is often chosen.

Another example that comes to mind is vector art vs baked art. You can render nice icons as vector art. Or you could ship perfect baked icons for all possible size variations. There are clear trade-offs here. One of them wastes more CPU cycles, and another one wastes storage space and download time.

If ants can smell where other ants have been, they are kind'a doing Dijkstra's algorithm. Is this the "swarm intelligence" the book is getting to?

The more you use GPT, the more you will understand that it's not the replacement for your attention to the work. And without the attention to the work, you can't spot bugs, blatant inefficiencies, or better design choices - in other words, if you don't take care, you won't even know what you are missing.

I write code with GPT every day for almost a year now, and it helped me greatly to kickstart code that was hard in the past, namely, audio synthesis, vulkan rendering, and other things that were hard to approach. But it's very clear at this point that it shall not be trusted, because it's like a coat of a nice paint put on top of all the clever or dumb stuff that exists on the internet. You never know which one you get, but sure it will be worded convincingly.

I would not sing praises for Microsoft Flight Simulator 2020. First, the cockpit displays are rendered at lower framerate, because they take considerable chunk of frame time. Second... It may be fine to render display and UI using js, but if you dig in, you will also find the autopilot there on top of inheritance hell.

The biggest wrapper that gives guarantees is the standard library, and usually, when people say that Rust does not do something, they have standard library in mind. For example, standard library made the choice to hide panics in out-of-memory situations. That does not mean you can't write your own version of relevant structures to gain different guarantees. I like to highlight the actual strengths of Rust (as a tool) instead of particular implementation details, especially when we are talking about situation (kernel) where Rust is used without its standard library.

I would avoid saying that it's "Rust" that "gives guarantees". It paints Rust as this magical thing that will solve anything. My preferred explanation is that Rust provides better tools to build wrappers that can't be misused. The idea is to solve hard problem once, and reap the benefits many times. But it all depends on wrapper author. In that regard, it is perfectly possible to write horrible Rust code.

First and foremost, algebraic data types, specifically, proper sum types, called "enums" in rust. Think safe C unions or sane C++ variant. Everything is built on them, they help to encode various states and ensure they aren't misused.

Second, moves by default. They make building wrappers that depend on creation and destruction of a value much easier. They can track various things: memory usage, threads, temporary pointers, or whatever else. Unlike unique_ptr, they are on stack and part of the type system.