Yeah, Kotlin is stuck in an uncomfortable position, like F# is in the .NET world. It has pioneered several important features, but now the big brother has implemented them slightly differently and people demand interop from you.
At least Kotlin can theoretically retreat to Android.
I did a decent amount of AoC this year in F#. I felt it was more verbose than I would have expected. There were a lot of things that helped brevity; I really liked type definitions, unless I was using OO features where it was extremely verbose to define members. I also really didn't like having to to Seq.map or List.filter for everything instead of just calling methods off of the seq or list.
Proper unicode font support is like 1.2GiB (noto, but I haven't found any complete unicode font collections that are significantly smaller). There's bloat for sure, but supporting universal text is one that I think is not a waste of space.
Maybe not proper support, but when I tried NetBSD recently my entire installation was around 1.5 GB on disk and seemed to handle Unicode well enough for me (for languages I care about). Not doubting some more packages would be needed to support every language, but happy everything wasn't installed by default.
Ye by proper i mean being able to render unicode in any language without tofu. I get that not everyone needs that, but its a reasonable thing to have on your disk in 2025.
The best is probably something like GLM 4.7/Minimax M2.1, and those are probably at most Sonnet 4 level, which is behind Opus 4.1, which is behind Sonnet 4.5, which is behind Opus 4.5 ;)
And honestly Opus 4.5 is a visible step change above previous Anthropic models.
Oh, of course not, you might need up to 100GB VRAM to have those models at decent speeds even just for low-quant versions.
And all the hype about Macs with unified memory is a bit dishonest because the actual generation speed will be very bad, especially if you fill the context.
One of the things that makes Opus 4.5 special in comparison to e.g. GPT 5.2 is the fact that it doesn't have to reason for multiple minutes to make some simple changes.
Because it was Microsoft that developed XNA a long time ago. It was XNA that inspired all the other frameworks you mentioned, and when Microsoft invariably abandoned it there were enough people using C# to make games to create demand for an open-source reimplementation.
Yes, this is basically correct. When you start writing a game with MonoGame, all you get is basically a class with two methods, Update() and Draw() that MonoGame will be calling in a loop, plus a bunch of libraries for input, graphics, audio, content loading etc. you can use in your code. It's a step beyond something like bare raylib or SDL2, but it's a far cry from Unreal, which lets you think in terms of game entities from the very start: "here's the map, here's where the player will spawn, here, add some buildings and you can run around them".
With MonoGame/XNA/FNA, LOVE2D, libGDX, HaxeFlixel you are getting a bunch of tools instead, which is probably not bad if you like coding and your game doesn't fit into one of existing popular genres.
I think a lot comes down to whether a game is art-first or code-first, and almost all modern games are art-first, so it makes sense to have your platform be one that artists and designers are immediately productive in, and the software people are basically writing behaviour modules and plugins for that established system.
But it's good that code-first engines still exist. There are always going to be projects that are more experimental, or don't have a clear pattern of entities, or are dynamic enough that that kind of thing doesn't make sense.
This is a somewhat naive view of engines in modern game development. Full-featured engines allow every department to dive in head first in parallel. The first gameplay elements often get programmed before the first pieces of content arrive. Scenes can be blocked out and drafted immwdiately at the start of the project. Complex animations with states and blend trees can be created amd tested independently of the gameplay code. Audio scenes, complex cues and (dynamic) music can be mixed and mastered independently of any code to integrate audio into the game. The whole process is highly parallelized these days and the engine tools serve to insulate the departments from one another to some extent so that everybody can move faster.
Right, yes. I think all I meant is that in earlier generations you could do modeling/sprites and concepting from the beginning, but there was a hard line in terms of how much code had to exist before the whole thing started to look or feel like much.
Thinking here especially of the Doom / Quake / HL1 era where they were basically building the level design tools in parallel with the game.
Whereas nowadays you can have movement, mobs, dialog flow, etc all with very little code, and it's placeholders like "oh we need a custom shader for this effect" or "that boss needs some custom logic".
You don't have to reinvent all these systems, but in my experience, you still have to code a lot to wire these very generic building blocks up in a good way that fits your specific use cases.
I'd say it was much shorter than 30 years. Facebook opened to the public in 2006, and I was surprised to learn Myspace (the first "normie" space on the Web) isn't much older. And before that your digital persona was separate from your offline persona, unless you were one of the grognards with a faculty .edu address.
Not literally exponentially, but the damage is proportional to the FOURTH power of the axle load. Imagine how expensive shipping would've become overnight if all these trucks had to pay their fair share and passed the costs to their customers.
Honda Civic weighs 0.7t per axle, or 0.24tttt of wear.
F-150 weighs 0.9t per axle, or 0.65tttt of wear.
A school bus weighs 7.5t per axle, or 3164tttt of wear. That's more than thirteen thousand Honda Civics' worth of road damage. Imagine the driver of the Honda had to pay 1c per mile. The school bus would have to pay $130 per mile. Yes, it's carrying 78 passengers, so the cost would be $1.67 per mile per student, but I think most people would just drive their kids to school.
>Imagine how expensive shipping would've become overnight if all these trucks had to pay their fair share and passed the costs to their customers.
The roads are already being paid for and maintained at their current state. All you'd be doing is making goods slightly more expensive and other taxes slightly less. About 1-4% of your total tax burden goes to the roads. That's a small enough total number to be easily buried among your annual spend on goods.
Like if roads were these huge financial burdens that didn't amortize away to practically nothing.
reply