That's weird. I noticed the post being marked as a dupe from the same community but I only saw one entry.

It’s from 2015, so its probably what you are doing anyway

No, you are probably not using this at all. The problem with JSON is that this details are all handled in an implementation-defined way, and most implementation just fail/round silently.

Just give it a try and send down the wire a JSON with, say, a huge integer, and see if that triggers a parsing error. For starters, in .NET both Newtonsoft and System.Text.Json set a limit of 64 bits.

https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonserializeroptions.maxdepth

Can you clarify how “Not even Github managed to pull that off”?

GitHub actions has an atrocious user experience, to the point that even a year or so ago people where doubting it was production-ready.

Sure, you can put together a pipeline. But I challenge anyone to try it out with GitHub actions and then just try to do the same with GitLab or even CircleCI or Travis.

The fact that people compare GitHub Actions go Jenkins of all things is everything anyone needs to know about it's user experience.

I mod the MAUI Community, which was created shortly before Xmas, and I made some announcements then (like on Mastodon, Daily Dew Drop, etc.) and some people joined then.

I'm late to the game but I should point out that the MAUI community is a textbook example of how communities should definitely not be created, and it was clear from the start that it was already born a dead community.

The C# barely gets a single post per week. The .NET community is even more of a niche community, and in spite of all the non-organic posts it's already dead.

Even though you were fully aware of this and you were repeatedly pointed out the obvious fact that a niche of a niche won't take off, you ignored te feedback and still went ahead with the creation of the community. Which is of course dead.

Lemmy in general and programming.dev in particular already have groups with traction. I hope that moving forward the group creation process is based on peeling specialized topics from existing communities. Otherwise the MAUI fiasco will repeat itself and we'll end up with an even longer tail of dead communities vulnerable to spam and takeovers by bad actors.

In Java, your objects start lowercase, so if you see uppercase, its a static call.

Not really, that's just the way a specific coding style was specified. You're free to refactor all your projects to follow any other coding style if you really want to, and your programs will continue to work just fine.

I don’t have an account there because of that reputation, and why would I now that I have access to chatgpt?

I think StackOverflow is rolling out a GPT-based service that generates answers to your questions based on SO's data.

You need to train ChatGPT to get it to output decent results. SO seems to be working to do that for you.

Leaving my 0.02$ here:

Please don't deploy this bot. It's annoying, it contributes nothing to actually create interesting content for the community to engage, and in fact its main output is spam.

It does more harm than good. Please don't.

I'd add that if the idea was any good then instead of spamming people left and right, it would suffice to crosspost stuff on target communities.

Using linting to prevent coupling between modules can give you some of the benefits of micro services without going all in.

My point was that modularizing an application and decoupling components does not, by any mean, give any of the benefits of microservices.

The benefits of microservices are organizational and operational independence. Where do you see coupling between components to play a role in any of these traits?

Java is the only programming language to get popular as a result of marketing.

I don't think this is true. Java is an outstanding tech stack and was revolutionary in a lot of ways, to the point that it motivated others to shamelessly clone it and in the process create other outstanding tech stacks. See C#.

For starters, Java solved the deployment problem way before containerization was a thing. Developers could simply put together a fat JAR, drop it in a web server like Tomcat, and it would simply reload without a hiccup.

Java is also very tooling-friendly, and has a solid versioning policy.

Does it have to?

If you're a developer looking for a pastime working on a personal project, no. You're free to waste your time and effort doing anything that pleases you.

Everyone else in the world only bothers with something if it provides any value at all. If a project such as this one fails to provide any value them no one will have any reason to waste their time with it, no matter how many times you rewrite it in Rust.

There is no C++ tool (AFAIK) providing an exhaustive check of ALL the data lifetimes.

Your reply reads like an attempt at moving the goal post.

The initial point was "Sometimes it’s easier to try a new idea in a new language (e.g. the borrow checker in Rust) rather than trying to shoehorn it into an existing language", to which I pointed the fact that yes it's indeed possible to "try a new idea" like borrow checking, and it only takes adding a tool that runs in a post-build/unit test step. It's simpler, easier, and does not force anyone to rewrite projects from scratch.

Claiming "oh but it might not work as well" is not an answer or a refuttal.

I already explained it to you: protocols apply to types you do not own or control, let alone can specify a base class.

You just specify a protocol, specify that a function requires it, and afterwards you can pass anything to it as-is and you'll be able to validate your calls.