Nobody’s perfect and time has shown multiple time that you can’t trust human beings with memory safety.

That's perfectly fine. That's not a problem caused UB, or involving UB.

Again, UB is a red herring.

It is however the language’s fault to allow UB in the first place.

It really isn't. Again, mindlessly parroting this doesn't give any substance to this claim. Please try to think about it for a second. For starters, do you believe it would make any difference if the C or C++ standard defined how the language should handle dereferencing a null pointer? I mean, in some platforms NULL is a tombstone, but on specific platforms NULL actually points to a valid memory address. The standards purposely leave this as undefined. Why is that? Seriously, think about it for a second.

Am I blaming those languages? Nah, it was a different time.

It really isn't. It's a design choice that reflects the need to work with the widest possible range of platforms. The standards have already been updated with backwards-incompatible changes, but even the latest revisions purposely include UB.

I repeat: I see people mindlessly parroting nonsense about UB when they clearly have no idea what they're talking about.

I use C++ all the time, undefined behavior is not something I encounter ever. I run undefined behavior sanitizer often.

From the looks of some of the posts showing up in this thread, I doubt the bulk of the commenters portraying UB as the root cause of any problem have any experience at all with C or C++. They are clearly resorting to unrealistic strawmen to pretend UB is something that it clearly is not. That just goes to show their technical background and the substance behind their claims. I really don't know how this helps advocating for Rust.

Some people also feel strongly about topics they are very familiar with 🙂. I have experienced my fair share of undefined behaviour in C++ and it has never been a pleasant experience.

If you had half the experience you claim to have, you'd know that code that triggers UB is broken code by definition, and represents a bug that you introduced.

It's not the language's fault that you added bugs to the code. UB is a red herring.

Sure, sometimes use of undefined behaviour works (...)

You missed the whole point of what I said.

By definition, UB does not work. It does not work because by design there is no behavior that should be expected. By design it's up to the implementation to fill in the blanks, but as far as the language spec goes there is no behavior that should be expected.

Thus, code with UB is broken code, and if your PR relies on UB then you messed up.

Nevertheless, some implementations do use UB to add guardrails to typical problems. However, if you crash onto a guardrail, that does not mean you know how to drive. Do you get the point?

What do you mean wrong “already”?

This is one of the problems in these discussions about undefined behavior: some people feel very strongly about topics they are entirely unfamiliar with.

According to the C++ standard, "undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data." Some examples of undefined behavior still lead to the correct execution of a program, but even so the rule of thumb is to interpret all instances as wrong already.

It seems to be a combination of both things. They believe that switching will attract contributors and make it more modern… but also they seem to have had some trouble with thread safety in C++ that would have required them to do some restructuring anyway.

It still feels like at best they are optimizing for the wrong metric and at worse they are just trying to rationalize an arbitrary choice.

I mean, the first reason they point out is "high probability of still being relevant in a decade." I mean, is Rust even a candidate in this domain? All leading programming languages have been around for longer than Rust and are actually specified in international standards, which ensures they will be around for essentially all eternity. Rust provides nothing of the sort. Is there anyone willing to put their hands in the fire for the expectation they will be able to build today's Rust projects a decade from now?

Also, Rust is renowned for having a steep and tough learning curve. Those are hardly the traits you seek to increase your potential userbase.

More importantly, threading stuff is limited to key architecture components that once in place are expected to change little to nothing. It's like picking .NET because you think it supports background processes well. Except the bulk of your code changes won't touch that, so what's the point?

Anyway, anyone is free to invest their time and effort in any venture without having to explain their motivations to anyone.

Non profit doesn’t mean they earn nothing

You need a valid business model to keep an organization ticking. Staff doesn't live out of hopes and dreams. It's hard enough to get a for-profit software company to stay up. If your starting point is that the company is not focused on getting a profit then it all sounds as hopes and dreams instead of an actual business plan.

Gitea is so much better than this.

Is it, though?

Also, Apache Allura supports revision control services other than Git, which apparently Gitea does not.

MIT licensed as well.

Why do you think that is relevant, specially given Apache Allura is released under the Apache license?

Here are some possibly related communities in the instance:

Instead of deploying annoying bots, if you care about traffic then you should post some discussions from now and then.

@Ategon , !opensource@programming.dev is basically dead and you haven't posted a single message there. If you care about content, shouldn't your effort be focused on creating posts instead of deploying annoying bots?

The problem with the article is that it’s confusing hard realtime and low latency requirements. Most UIs do not require hard realtime, even soft realtime is a nice to have and users will tolerate some latency.

I don't think that's a valid take from the article.

The whole point of the article is that if a handler from a GUI application runs for too long then the application will noticeably block and degrade the user experience.

The real time mindset is critical to be mindful of this failure mode: handlers should have a time budget (compute, waiting dor IO, etc), beyond which the user experience degrades.

The whole point is that GUI applications, just like real-time applications, must be designed with these execution budgets in mind, and once they are not met them the application needs to be redesigned avoid these issues.

Maybe I’m dumb because I’m a backend dev, but if we can’t offload these tasks to Async tasks and we need to block the main thread, why can’t we just put up a loading screen?

That's not the problem. These tasks can be offloaded to async. The underlying issue, and the reason why I think this is an outstanding article, is that running code on the UI thread straight from handlers is easy and more often than not it goes perfectly unnoticed. Only when the execution time of those handlers grow do these blocking calls become an issue.

There's a gray area between "obviously we need to make these calls async" and "obviously we can run this on the main thread", and here's where the real-time mental model and techniques pay off.

“Don’t turn off the application we are saving” games have been doing this for a decade and you can’t convince me that your enterprise application is heavier than a AAA game.

You're missing the whole point.

The point is that running handlers in the main thread leads to far simpler code and, depending on the usecases, is adopted in scenarios where the approach works well with 99.9% of the conceivable usecases. But then the software starts to be modified and get features added, and some of these code paths start to do more things and take more time to run. When this happens, the 99.9% starts to shrink and some main thread blockages start to become more and more noticeable.

The article does a very good job in underlying the mental model that needs to be in place to avoid this slippery slope to become a problem.

Let me give you a quick life lesson.

You've typed too many words to try to rationalize your toxic behavior.

I repeat: pay attention to what you say and do. All communities have their bad apples, but this does not grant the likes of you the right to spoil the whole barrel.

I'm going to play devil's advocate for a moment.

following best practices we laid out in our internal documentation

Are you absolutely sure those "best practices" are relevant or meaningful?

I once worked with a junior dev who only cared about "best practices" because it was a quickly whipped document they hastily put together that only specified stuff like coding styles and if spaces should appear before or after things. That junior dev proceeded to cite their own "best practices" doc with an almost religious fervor in everyone else's pull requests. That stopped the very moment I made available a linter to the project, but mind you the junior dev refused to run it.

What's the actual purpose of your "best practices" doc? Does it add any value whatsoever? Or is it just fuel for grandstanding and petty office politics?

his code works mind you,

Sounds like the senior dev is doing the job he was paid to do. Are you doing the same?

It’s weird because I literally went through most of the same training in company with him on best practices and TDD, but he just seems to ignore it.

Perhaps his job is to deliver value instead of wasting time with nonsense that serves no purpose. What do you think?