strictfp

> Some apps don't need memory safety.

Maybe not, but it's still a big pain in the butt to avoid bugs in that area. I imagine that static analysis for memory safety would be something that most developers would use in existing unsafe languages if they could.

Webpages were designed to avoid complex state management. URLs, HTML and forms, i.e the original REST, is a model with a lot of power and flexibility, and almost none of the complexity of desktop UI toolkits.

Frontend web frameworks have their use in rich apps, but using them for general web pages is just complicating things for no good reason.

Thanks. Do you setup an artificial tree during testing? If so, how?

How do you people feel about the Godot object and lifetime model? I found it hard to test my code because of how objects are tied to the tree, that emulating the tree isn't easy during testing, and that initialization during live use is different than if you instantiate manually, making it hard to rely on a constructor, since you might not be able to use it live.

I can't remember the exact details around this, since I only used Godot for a couple of jams and the last time was a year ago. But I was wondering if others have had the same reaction, perhaps this could be fixed? I love the engine in general, but this thing irked me.

> The use of virtual methods is verboten for many common use cases of C++, due to the necessity of being in paged memory

I wasn't aware of this. Maybe I'm just out of the loop. Do you know where one can I learn more about this? I'm desperately trying to reduce the number of virtual calls in our codebase, but I'm hitting the aforementioned problems.

Sure. I guess template-based polymorphism is alright for code dispatch. But if you want to store the different types of objects involved you have limited choices. There's no straight-forward support for sum types. std::variant is fairly new, has a cumbersome API, and is quite slow (ballpark the same as virtual calls). There's no support for methods on enums nor anything for customizing the fields of different enum constants. There's also no pattern matching or other really convenient way of deconstructing variants.

So while it's there, I would say that the oo virtual method style is much better supported, although storage for those usually requires some type heap allocation.

I don't agree. The support for static polymorphism is in it's infancy at best.

Yes, that's true. In a sense, c++ requires good code structuring.

That's also part of why I enjoy returning to c++, the people involved know how to structure code and create clean architecture.

That said, sometimes c++ does get in the way. Creating trees or graphs can be cumbersome, and IMO it's very biased towards virtual methods to solve polymorphism.

Extending lifetimes by pooling or similar is also quite common, and is in my eyes sometimes overdoing it. If you for instance use Rust, you can be a lot more confident that the compiler catches these issues, and be more conservative and efficient in the solution.

I've worked in a variety of languages, and returning to a c++ project recently I do see that we spend a lot more time thinking about how to write the code in a way that avoids problems. Meaning that there's a lot more architecturing required to reach a sane state.

We have a sister product written in a dynamic language, and sometimes we have identical functionality.

I've noticed that when a change is discussed, the c++ gang has architectured themselves into the current solution and therefore have a much harder time making changes.

So for that reason I think it's easy to overlook these complexities when you're working in c++ alone; they feel natural and are just part of how you work. You forget that a lot of this architecturing just isn't necessary in a lot of other languages.

A debugger can work in many ways, it can also print, or trigger on altered memory. I would say that a debugger is generally more useful for finding race conditions than logging. But writing tests is really the best tool there.

In my opinion printing or logging is much more useful than debugging when you want to be able to understand the sequence of events leading up to a bug, where the debugger isn't very strong. After analyzing the logs, using conditional breakpoints depending on each other can help you catch the issue live.

Each tool has their strength and weakness, but I would never go so far as to say that debuggers are pointless. Being able to inspect memory and browse for inconsistencies can be priceless.

I think it's because it's a concept that constrains how multiple instances of a type interact, and we're used to thinking of types as putting restrictions on single instances.

Jetbrains IDEs are just as good as Visual studio. As is XCode, QT creator and friends. And they work with many languages.

I know it's a problem with Python and Node though.

Node is great for this usecase

Physics is also ran on the client, but the server is authoritative and can correct or override client decisions.

The thing is that a simple name doesn't work either, so 'server1' doesn't work, 'server1.local' doesn't work. 'server1.example.com' works, and I think 'server1.lan' also works, but I'm not sure about that last one.

Do you have a proper domain name for your local network (+ search domain)? I'm talking about the case where you don't, or have a '.local' domain; https://askubuntu.com/a/918161

For those of you who downvote this because you think I'm being disingenuous, I speak from personal experience of working closely with Red Hat in a number of projects where their code were an integral part of the solution.

Red Hat really do reinvent the wheel, for the purpose of making money selling popular kinds of software. And they're shamelessly declaring themselves superior to the product they're mimicking. And the projects are ran like side projects of the lead developers.

I think that's a colloquialism, according to several dictionaries "America" can nean the two continents.

https://dictionary.cambridge.org/dictionary/english/america

Maybe nowadays, but when it came to Ubuntu back in the day it was enabled by default and couldn't be turned off because it was being used early in the boot cycle when other resolvers hadn't booted yet. Talk about bad design decisions...

"works"

They closed this super-critical bug despite not fixing it, claiming they're making the right decision in their implementation when they in fact misread the spec

https://github.com/systemd/systemd/issues/2514

Yeah, that's right, with resolved you cannot connect to other machines on your local network by specifying their simple names, because it blackholes those requests, and there's nothing you can do about it.

I thought it was "cat -v" (https://cat-v.org/) ;P

Anyways, those breakages aren't nearly as big of a deviation from the modular design as something like systemd. I'm sorry, but that comparison just cannot be made.

I'm not opposed to the idea of a more intelligent init system, but systemd is doing waaaay to much. One example; it messed up hostname resolution on my lan by blackholing DNS traffic for single-name queries. And you cannot turn their dns component off.

Upstart would have been a better alternative.

Classic Red Hat. Arrogant and agressive. Reinventing the wheel. Usually also one or a handful of developers per project.

It brings Linux closer to Windows in philosophy. Systemd is building a coherent large codebase (albeit modular) that solves all the problems, as opposed to Linux userspaces old philosophy of having a collection of "expert" tools, where each tool or project did one thing, one thing only, and did it really well. Then the system was a collection of such expert tools.

The collection of expert tools naturally aren't as well-integrated with each other, so on a system level the solution might look a bit spotty. But every function is thought through and works really well. Plus, each tool is useful on its own, which makes the system very configurable, introspectable, and hackable.

The "one big codebase that solves all problems" approach might appear more stable all-in-all, but it's a fundamentally different approach where you no longer have a bunch of expert tools, but rather a large collection of mediocre software components who's only real purpose is to be integrated with each other.

I think the most important mind shift is from "let's make this extendable by plugins/scriptable so we can modify it while it's live" to "if requirements change, let's just change the source code and redeploy".

I also disagree with the SOLID principles. KISS is more important than adding extra code and sacrificing performance to allow extension without touching the original source files. Unless you goal is explicitly that.

You're trying to write the simplest, most straight-forward encoding of the solution. If you can avoid duplication and make the code read well, you're golden.

Why move to America when Canada's already in America? ;P

Organizing around software components is such an idiotic idea.

Good luck changing your design or making end-to-end features when you have teams protecting "their" part of the software.

You've just made sure that any significant change to the system requires coordinating many different teams, making it at least one order more difficult than before, and a lot more bureaucratic.

And?

IMHO most RedHat systems tend to be overengineered. Even the config file split is overengineered in RedHat compared to many other distros. And documentation, although existing, tends not to be detailed enough to understand how to deal with the systems. You need trial and error.

Plus that you need to architect this yourself, with all the black magic involved to not mess something up.