Well, auto looks just like var in that regard.

It really isn't. Neither in C# nor in Java. They are just syntactic sugar to avoid redundant type specifications. I mean things like Foo foo = new Foo();. Who gets confused with that?

Why do you think IDEs are able to tell which type a variable is?

Even C# takes a step further and allows developer to omit the constructor with their target-typed new expressions. No one is whining about dynamic types just because the language let's you instantiate an object with Foo foo = new();.

He’s not being run out of the project… yet.

To be honest, to me this all sounds like sociopath behavior to throw politically-inconvenient people under the bus in desperate self-preservation, and hoping this would intimidate anyone falling out of line.

Everyone in that group should present their immediate resignation. Shameful.

It was supposed to be a better C without the bloat and madness of C++, right?

D was sold as a better C++, way back then when C++ was stuck with C++98. To be more clear, D promised to be C++ under active development. That was it's selling point.

In the meantime C++ received 2 or 3 major updates, and thus D lost any claim to relevance.

There are a few coding conventions and style guides for C#:

• .NET C# Coding Style
• .NET Framework design guidelines
• C# at Google Style Guide

Github for organizations becomes rather expensive rather quickly (...)

I'm not sure if that's relevant. GitHub's free plan also supports GitHub organizations, and GitHub's Team plan costs only around $4/(developer*month). You can do the math to check how many developers you'd have to register in a GitHub Team plan to match the operational expense of hiring a person to manage a self-hosted instance from 9-to-5.

A very large part of the problem is that the people who are knowledgeable are often the ones that bought into the whole lone wolf coder shtick.

I'd add that a large part of the problem is that we have people complaining about perceived problems without being able to present any kind of solution.

Honestly, a similar tool should rethink the design to be more intuitive, orthogonal and have fewer concepts that cover all use-cases.

With regards to Git I'm a victim of Stockholm syndrome, thus it's hard for me to see where are all those alleged unintuitive design choices.

This analysis is rendered even more difficult as these criticisms of Git are depicted in vague terms without mentioning a single concrete example.

To make matters worse, these accusations become even less credible given the fact that all other Git competitors seem to copy Git's user interface almost verbatim. This means Git must be doing something right.

So given this issue, is there any concrete example of where Git is lacking in the UI department?

You’re right that that’s extremely unambiguous, but I still don’t love the idea that users don’t get to decide what’s in $HOME, like, maybe we could call it “$STORAGE_FOR_RANDOM_BULLSHIT” instead?

That's basically what $HOME is is used for in UNIX: a place for applications to store user-specific files, including user data and user files.

https://www.linfo.org/home_directory.html

If anything in computing conventions implies “user space” it’s a global variable named HOME. And it makes sense that there should be a $STORAGE_FOR_RANDOM_BULLSHIT location too - but maybe not the same place?

UNIX, and afterwards Unix-like OSes, were designed as multi-user operating systems that supported individual user accounts. Each user needs to store it's data, and there's a convenient place to store it: it's $HOME directory. That's how things have been designed and have been working for close to half a century.

Some newer specs such as Freedesktop's directory specification build upon the UNIX standard and Unix-like tradition, but the truth of the matter is that there aren't that many reasons to break away from this practice.

I was expecting a huge CICD pipeline with delivery steps automatically publishing packages for Debian Unstable and Debian Testing, but it turns out it's a relatively simple pipeline with straight-forward build and testing stages.

Less is definitely more, and targeting Debian alone does greatly simplify a pipeline, but somehow I was expecting more automation taking care of the whole workflow.

This was the first time I saw someone refer to Python's type hints as a performance tool. Up until now, I only saw references to type hints as a way to help static code analyzer tools verify that objects and invocations comply with contracts.

I guess that having additional info at hand to determine how some calls are expected to be made is helpful to gather info to drive optimization steps, but PEP 484 is clear in stating that it's goal is to help type checkers, and that code generation using type hints might be limited to some contexts.

This sounds like yet another example supporting the old law of interfaces, where all it takes for an interface to be abused is for it to exist.

Someone in the thread mentioned that to get the benefits of micro services in a monolith, you can use a linting rule to prevent dependencies across modules

I don't think that makes any sense. The main benefit of microservices is organizational, more specifically how a single team gets to own all aspects of developing, managing, and operating a service.

Lower in priority, there's enabling regional deployments and improved reliability.

How are linting rules even expected to pull that off?

That should be a disciplinary issue.

And that's how you get teams to stop collaborating and turn your work environment to shit.