kfuse

"IEnumerable should not be forced to return a type-erased = heap allocated IEnumerator instance."

Foreach loops use compile-time duck typing, so if you don't intend to use your enumerable in LINQ then both the enumerable and enumerator don't need to implement any interfaces.

This optimisation covers only one common use case, but that's the way of things in C# land.

"For" statement can become quite messy if used outside of several common patterns. And the fact that c/c++ are getting this so late shows that this is not such an obviously good idea.

This golangism hurts readability, it puts an important piece of logic at the end of a pontentially long line. Usually, it's just an ok test, but it's easy to miss when it isn't.

No need to insult JavaScript. In two out of three times the "JavaScript" written will be something like:

    interface Box<T> { value: T }

    function map<T, U>(input: Box<T>, func: (value: T) => U): Box<U> {
        return { value: func(input.value) }
    }

C# was already a very mature language when it had referenes and later "ref safety" added to it.

They do worry, they just can't do anything about it. Like the fact that error handling code takes at least three lines no matter how trivial it is. I'm sure error handling would not be critisized nearly as much if it didn't consume so much vertical space and could fit in one line, which go compiler does allow.

Raylib is a very good option for 2D games. For me it was the easiest way to translate my toy Doom renderer from javascript that used html canvas to C#.

Updated a pet project of mine and got a minor break:

  var pixels = new uint[renderers.width * renderers.height];
  var pixels2 = MemoryMarshal.Cast<uint, ulong>(pixels);
  pixels2[idx] = ...

In NET9.0 pixels2 were Span<ulong>, but in NET10.0 a different MemoryMarshal.Cast overload is used and it is ReadOnlySpan<ulong> now, so the assignment fails.

Spans is such a fundamental tool for low level programming. It is really unfortunate they were added relatively late to the language. Now every new version includes a slew of improvements related to them but they will never be as good as if they were there from the start or at least as early as generics were.

That's not just Java and there is nothing really cursed about it: throwing in a finally block is the most common example. Jump statements are no different, you can't just ignore them when they override the return or throw statements.

Node now has limited supports for Typescript and has SQLite built in, so it becomes really good for small/personal web oriented projects.

Jupiter is 5 times farther from the Sun than us, there is basically no lighting and heat from the Sun there.

I think for a civilization capable of sending reasonable amount of people people at reasonable speeds to colonize such planets, creating suitable atmosphere, lighting and heating is very much possible. Gravity is the only hard requirement.

Why is everyone so fixed on interstellar travel? What if the galaxy is chock full of rogue planets? There may be hundreds if not thousands of worlds between us and the surrounding stars. Hopefully, Roman Telescope set to launch in 2027 is going to find lots of them.

As I said, traditional doom bsp-walker software renderer is quite parallelizable. You can split the screen vertically into several subscreens and render them separately (does wonders for epic maps). The game logic, or at least most of it, can probably be run in parallel with the rendering.

And I don't think any of the above is necessary. Even according to their graphs popular doom ports can render huge maps at sufficiently high fps on reasonably modern hardware. The goal of this project, as stated in the doomworld thread, is to be able to run epic maps on a potato.

"Rendering engine is also completely orthogonal to polygon-based 3D accelerators"

Software rendering engine, yes (and even then you can parallelize it). But there is really no reason why doom maps can't be broken down in polygons. Proper sprite rendering is a problem, though.

Frankly, that doesn't explain much, because that sounds like how modern computing works: every program has its own continuos 32/64 bit address space. With 24 bits you can address 16MB which seems enough to be useful if you throw away reflection and such.

All modern popular languages are fast, except the most popular one.

Maybe one reason is its verbosity for small everyday tasks, like config files or when representing arrays. If xml allowed empty tags there probably would be no need for json.

Doom doesn't use raycasting, it uses binary space partitioning.

From the description it seems to be a DOOM clone. Physics feels a bit off, but all the little details may trick you into believing that it's the real thing.