marler8997

If you have a self-contained project, where you don't depend on anyone else and others don't depend on you, MinGW works great. Problems arise when you have dependencies that don't work with it. I'd love to see if MinGW could find a way to be binary compatible with MSVC-compiled binaries. Right now it's kind of an all or nothing solution which makes it hard to adopt.

Wait till they find out what the Visual Studio Installer itself does :) I guess this person just trusts a big company like Microsoft who keeps their source hidden more than a single developer who publishes all their source?

Yeah I noticed wine wasn't able to execute the MSI files. It also had a problem with the lock files. Both problems should be fixable though.

None taken :) I think sharing our thoughts and discussing them is how we learn and grow. The best people in their craft are those who aren't afraid to put themselves out there, even if they're wrong, how else would you find out?

I avoid using exceptions myself so I wouldn't be surprised if I misunderstand them :) I love to learn and welcome new knowledge and/or correction of misunderstandings if you have them.

I'll add that inspiration for the article came about because It was striking to me how Bjarne's example which was suppose to show a better way to manage resources introduced so many issues. The blog post goes over those issues and talks about possible solutions, all of which aren't great. I think however these problems with exceptions don't manifest into bigger issues because programmers just kinda learn to avoid exceptions. So, the post was trying to go into why we avoid them.

It's a bit more than your typical "interop via C". With a "sized opaque" type you actually can stack allocate C++ values in Zig (and vice versa stack allocate Zig values in C++), i.e.

fn stackExample() void {

    var some_cpp_type: c.SomeCppType = undefined;
    c.some_cpp_type_ctor(&some_cpp_type);
    defer c.some_cpp_type_dtor(&some_cpp_type);

    // ...

}

I checked the git history to see if you included the Zig version but looks like first revision is rust...

In the Zig version did you use my zigwin32 project or did you go with something else? Also, how did you like the Zig build system vs rusts?

Hope to be able to bring Linux back at some point. Unfortunately there wasn't enough users to justify spending development time on it. It's hard to tell if the user count was low because of lack of interest of issues with app itself. It's also ironic that Linux is the hardest platform to support. It had too many pieces outside our control that would break. If/when we can get back to it I'd like to avoid Flatpak and take an approach that we can have more control over. Possibly a static build and maybe even look into native package manager integration.

Great game, cleverly demonstrates a fundamental problem with creating rules/laws. I've wondered if focusing on the goal/intent when creating rules would be more effective? For example, instead of just a rule that says "No vehicles in the park", you could say, the community wants the park: - to be safe - to be peaceful/relaxing - to accommodate physical activities/games

For these reasons, we don't allow vehicles that will unnecessarily compromise safety and/or make a lot of noise.

Of course the goal/intent I've written suffers from the same problem as the rules did, the definitions are ambiguous, but I think there's a distinction between capturing the spirit vs the letter of the law. It's a guide for why the rules exist and when they should or shouldn't be applied. It's not perfect, but, I think it's an improvement of just listing rules. If capturing/publishing the reasons for rules alongside the rules was normalized I wonder how different things could be?

D's actually worse than Zig in regard to point 3. Kristoff's example demonstrates why. In D you would have to change the "if" to a "static if", D will always evaluate normal "if's" at runtime even if they are comptime-known, it will not do this automatically for you.

The bigger issue D has with this example is that normal parameters are always runtime. If you wanted this to work in D you would need to implement 2 versions of "double", one that takes n as a template parameter and one that takes it as a runtime parameter. D keeps comptime and runtime parameters separate, making comptime-knowness a "parameter color" which in practice means having to implement things twice if you want it at comptime and often in different ways. There are some things that can work with both but it's small subset of both.