This is only the language for describing the volumes. That's not heavy, rather the importance is that you can express the ideas you want. The heavy lifting of rendering and computing how volumes interact etc is already implemented in native code.
That sounds like a nice improvement, just like many other aspects of jj!
Tools should adapt to us and not the other way around, but if you are stuck with git, there's a slightly different workflow that supports your use case: detached head. Whenever I check out branches that I don't intend on committing to directly, I checkout e.g. origin/main. This can be checked out in many worktrees. I actually find it more ergonomic and did this before using worktrees: there are no extra steps in keeping a local main pointer up to date.
The detached head is what I meant with keeping it on the branch while not keeping it on the branch.
The complication comes from trying to stay current. With a regular worktree I could just pull, but now I have to remember the branch, fetch all and reset hard to the remembered branch.
Especially with the recent extension of STS release support from 18 to 24 months [1]. Previously, upgrading from an LTS version to the next major (STS) version meant the support window decreased by half a year, while now it would stay the same.
Are you referring to the change tracker? FYI you can have it skip tracking as the default (or per query), but when you actually want to make changes you better opt in with `.AsTracking()`.
Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:
- Convenient definition of schema.
- Nice handling of migrations.
- LINQ integration
- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.
What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?
Dapper can be a better fit depending on the scenario. It's dumb objects. You fill them yourself with actual SQL statements. There is no change tracker. You are the change tracker.
The main issue with EF is ultimately there is an expression builder that maps linq expressions to sql. This mostly works, until it doesn't, or it does but has strange generated sql and performance. If all you are doing is CRUD or CRUD adjacent then it's fine. But for some complex stuff you spend a lot of time learning the innards of EF, logging generated statements, etc. It is time better spent writing good sql, which something like Dapper allows.
Fair enough. We use Dapper for a handful of performance-critical queries. But I wouldn't want to use it for the 99% where EF works well. Just like I wouldn't want to hand-roll assembly more than where it's really needed.
And it's not just about performance. LINQ plays well with the same static analysis tools as the rest of C#. You know, type checking, refactoring & co.
Me too! It was funny how little love it got given how well it worked.
The only issues I came across were artificial blocks. Some programs would check the OS version and give an error just because. Even the MSN Messenger (also by Microsoft) refused to install by default; I had to patch the msi somehow to install it anyway. And then it ran without issues, once installed.
Edit: if the connection isn't clear, I mean the aspect of it being difficult to argue rationally about opinions you've made part of your identity, since changing the opinion would be difficult.
I'm impressed by your, and their, hearing comprehension here! Granted, English isn't my native language but even with concentration I struggle to hear what they say.
It's easy to forget how many skills and "heuristics" go into listening. I once read a scale of language proficiency that placed "Can converse over a poor phone connection" at a very high level. When a word is garbled or lost, you have to quickly think of all the possible words that could've fit the grammar and whatever sound you heard, consider them in the context, and choose one or two. Then the next part of the conversation should let you pick one. Then add the complication of not seeing body language.
I forget where I read this. I think it was from the US Department of State, but I can't find it now.
Previous experience with aviation radio comms helps a lot. Typical radio comms essentially follow a template, and it’s done in a way where you can safely approximate a LOT (…just not numbers). But the…phraseology if you will, can be approximated quite easily with experience.
Funnily enough, American ATC / pilots are, I find, a lot more frequently ‘fast and loose’ compared to other areas, even English-speaking ones. Countless recordings online of EALD pilots being befuddled by some self-identified hotshot air traffic controller using overly casual / sloppy language, sometimes resulting in near misses or worse.
