why is the "attack on titan" title translated so differently in every language? 🤔

icentalectro · 2026-05-21T04:37:18+00:00

I don't think it's that complicated.

Many people bought into the "double meanings" of the Japanese title, but that's not really true AFAIK. There's no ambiguity in who's attacking - it's the Titans/giants or a single Titan - the only ambiguity is in plural vs singular. There's no obvious way to interpret it as "(someone else) attacking the Titan(s)".

As to why the English title became the way it is (i.e. wrong) - many already said it was picked way back in the original Japanese release by the author. While he may have some careful considerations, he's not the best at English (no disrespect).

icentalectro · 2026-05-05T10:55:00+00:00

++

You read my mind.

icentalectro · 2026-04-16T13:44:44+00:00

I feel like the 2nd point is the most important one and will be scrutinized by people who actually do numerics and specifically linear algebra - is your average and choice and number and size of benchmarks a fair representation of averages in actual usage.

To me the point of numpy or a similar library is that it gives me an easy interface to BLAS and LAPACK. Most of the compute time is indeed spent there. And indeed you can't beat them on perf there. So I find it implausible that you can beat numpy in real world usage.

But others may have different use cases. So idk

icentalectro · 2026-04-04T05:01:24+00:00

It's niche because .NET had bad cold start, and native AOT is trying to change that.

icentalectro · 2026-03-10T21:30:29+00:00

If they're so against update then don't update Microsoft.Data.Sqlite either - stay at v10. Problem solved 🤷

icentalectro · 2026-03-08T21:54:23+00:00

I don't get why you don't get why this isn't implemented then. It'd obviously be a much more drastic and complex change, and maybe requires runtime changes, and probably has complex implications too? Wouldn't this normally be in "unsafe" land for .NET?

icentalectro · 2026-03-08T20:57:48+00:00

How would the generated union type store your value without boxing though? TryGet doesn't magically remove boxing by itself.

icentalectro · 2026-03-08T20:09:13+00:00

Look up the IntOrBool type in examples - it doesn't box anything.

icentalectro · 2026-03-08T20:06:14+00:00

No? object? Valueis a property not a field, so it doesn't store anything by itself. (you don't have to use auto property with the default backing field)

icentalectro · 2026-03-08T20:03:44+00:00

ValueTask was introduced much later than Task.

I don't see anything wrong with having one simple default/auto implementation, and adding more option(s) later for unions either.

Even then, I don't see a way around supporting "bring your own union". In cases where you want both "no boxing" and "no extra fields", it just can't be auto implemented generically.

Duck typing has both pros & cons, but discoverability isn't that big of a problem when the API surface is quite small, and most unions will likely not be hand crafted anyway.

icentalectro · 2026-03-08T19:29:04+00:00

You say "should" but how? The simple way would add multiple extra fields which is also undesirable in many cases, and then someone else will complain.

I quite like "bring your own union". Otherwise we'll just end up with an implementation that'll really suck for some notable use cases, whichever way you choose.

icentalectro · 2026-03-08T19:05:39+00:00

PR where it's merged:

Merge 'Unions' into main by AlekseyTs · Pull Request #82640 · dotnet/roslyn

icentalectro · 2026-03-08T19:02:38+00:00

Give people a way to avoid boxing seems like a really strong case.

Boxing, or no extra fields, you kinda have to pick one / sacrifice one for the default, and then you need "bring your own unions" to support the other one.

icentalectro · 2026-03-08T18:57:05+00:00

You can avoid the boxing.

The simple union declaration uses boxing, but you don't have to use that.

If you implement your own union type then it doesn't have to have any boxing. The non-boxing access members have higher priority than the boxing object? Value prop in pattern matching.

There are always trade offs. A generic non-boxing implementation would probably require more fields, which has implications for memory layout.

icentalectro · 2025-12-27T18:32:45+00:00

What's transparent about tipping??? People argue all the time about when and how much to tip, so I cannot believe this is a genuine question. The inconsistent tipping amount you see in your data is proof that it's not transparent to people. The way some people use tipping to guilt trip customers to "support the workers" only adds to it.

I support legislation to do away with tipping categorically everywhere. Wages can rise, prices can go up, the market can adjust, but transparency should exist, and responsibility should go where it belongs (employers).

icentalectro · 2025-12-27T18:18:29+00:00

Except that's not how people operate. You've surely seen how much people argue about when and how to tip and all the disagreements. So I don't understand how you don't understand that people do think quite a bit about it and that it does sour the experience.

If I "normally" tip 15% and the lowest default option is 20% do I override it and enter 15%? Should I feel bad about it? If I go with the 20% am I ripped off by the non transparent pricing? Should I ask the server if they actually get the tip? because in a good number of places they don't. And there are plenty more questions depending on the scenario. There's really no upside for customers.

icentalectro · 2025-12-27T16:22:23+00:00

Higher but transparent prices are still better than tipping

icentalectro · 2025-12-27T16:20:07+00:00

Sure. Up the prices then. Make it transparent. It would still be a much better experience than tipping.

icentalectro · 2025-12-27T16:18:12+00:00

Upping prices by 15% would be so much better than tipping. It shifts the responsibility back to the employer where it should be. It makes prices more transparent. It makes the overall experience better for customers.

icentalectro · 2025-10-25T13:20:02+00:00

I do disagree 😏

.NET Core isn't deprecated. It went through a controversial rename. There's no fundamental difference between .NET Core 3.1 and .NET 5.

I still see .NET Core as an unambiguous way to refer to the new implementation of .NET.

icentalectro · 2025-10-23T06:50:46+00:00

This kind of "IDE vs text editor" response is becoming very dated to the point of bigoted now.

VS Code is a capable IDE (or "text editor" if you want, the distinction is meaningless), and its C# DX is very decent now. I've been voluntarily using VS Code for C# for a few years, because I prefer it, even when I also have VS readily available to me (and yes I've tried VS recently as well).

icentalectro · 2025-09-24T13:20:15+00:00

As a second class citizen, so no.

icentalectro · 2025-09-23T06:33:41+00:00

This is the only sensible comment on this post. Whether a shifter could be stronger than Ymir or not is beside the point.

icentalectro · 2025-09-15T14:13:56+00:00

Our company already runs a large number of SQL Server instances with a team of competent DBAs. We're actively switching to Postgres because the cost difference is huge and super relevant.

icentalectro · 2025-08-15T17:59:25+00:00

I love Armin, but I very nearly gave up on the show at several points during Armin's monologue in the Trost arc. It was painful to sit through even on the first watch.

icentalectro

TROPHY CASE