You do actually understand that languages that aren’t JavaScript don’t have built in async runtimes and they need to be provided by a library, right?

How do you explain C#?

Does anyone have any good sources or suggestions on how I could look to try and begin to improve documentation within my team?

Documentation in software projecte, more often than not, is a huge waste of time and resources.

If you expect your docs to go too much into detail, they will quickly become obsolete and dissociated from the actual project. You will need to waste a lot of work keeping them in sync with the project, with little to no benefit at all.

If you expect your docs to stick with high-level descriptions and overviews, they quickly lose relevance and become useless after you onboard to a project.

If you expect your docs to document usecases, you're doing it wrong. That's the job of automated test suites.

The hard truth is that the only people who think they benefit from documentation are junior devs just starting out their career. Their need for docs is a proxy for the challenges they face reading the source code and understanding how the technology is being used and how things work and are expected to work. Once they go through onboarding, documentation quickly vanishes from their concerns.

Nowadays software is self-documenting with combination of three tools: the software projects themselves, version control systems, and ticketing systems. A PR shows you what code changes were involved in implementing a feature/fixing a bug, the commit logs touching some component tells you how that component can and does change, and ticketing shows you the motivation and the context for some changes. Automated test suites track the conditions the software must meet and which the development team feels must be ensured in order for the software to work. The higher you are in the testing pyramid, the closer you are to document usecases.

If you care about improving your team's ability to document their work, you focus on ticketing, commit etiquette, automated tests, and writing clean code.

That way we’ll just find maintainers went near extinct over time, just like COBOL developers that are as rare as they are expensive.

Care to take a shot at figuring out why COBOL is still used today?

I mean, feel free to waste your time arguing for rewrites in your flavor of the month. That's how many failed projects start, too, so you can have your shot at proving them wrong.

But in the meantime you can try to think about the problem, because "rewrite it in Rust" is only reasonable for the types who are completely oblivious to the realities of professional software development.

With what in mind? Evading NULL?

Depends on your perspective. It's convenient to lean on type checking to avoid a whole class of bugs. You can see this either as avoiding NULL or use your type system to flag misuses.

Languages that make use of references rather than pointers don’t have this Dualism. C# has nullable references and nullability analysis, and null as a keyword.

C#'s null keyword matches the monadic approach I mentioned earlier. Nullable types work as a Maybe monad. It's the same concept shoehorned differently due to the different paths taken by these languages.

They made a demand, based on a product launch time line.

If you read the same bug report I read, you wouldn't make that claim. They expressed their personal needs, which are their own and theirs alone, and don't extend beyond their personal roadmap.

This is absurdly rude (...)

The issue stated they found a bug that they had to get fixed. They said it was important to them for their own personal reasons. It's laughable to describe what amounts to a run-of-the-mill bug report as "absurdly rude".

Do you actually work on software for a living?

treating open source like slave labor

I'm sorry, what? Do you even pay attention to what you're writing?

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.

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?

Use unsafe and write like you’re a C/C++ programmer. You can do it.

Onboard the C/C++ project to any C++ static code analysis tool and check back with me later.

This is a nothingburger.

I think that pattern matching and sum types are orthogonal to monads, and aren't really relevant when discussing monads as alternatives to exceptions. C++ didn't required any of those to add std::optional or std::variant, and those are already used as result monads.

Supporting Result and Either monads in the standard would be nice, but again this does not stop anyone from adopting one of the many libraries that already provide those.

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?