lysdexic

While I can agree we don’t have sufficient data to make hard conclusions on this front, I think there are enough early indications that point to Rust being able to stay on par with or even outperform C++ in this regard:

I'm skeptical of these claims, not because X or Y is better or worse, but because milking the last drop of performance has far more to do with software architecture than it has to do with the programming language per se.

Also, I think this sort of argument always leads to specious reasoning. C is the undisputed performance lead, and you surely do not see Rust proponents using benchmarks to argue they should rewrite all Rust code in C.

What I find surprising is that there are a lot of steps between a free-for-all and state intervention through regulation that those experts seemed to have skipped altogether, such as voluntary auditing, state-sponsored industry initiatives to specify best practices, invest in the development of static analysis tools and memory profilers, or making vulnerable companies liable for the consequences of attacks.

But no, they jumped straight into state-imposed regulation. Because keeping people out is a solution?

Highly recommended

I agree. Once we get a hang of the value that bisect brings, one unintended consequence is that we start to value atomic commits a whole lot more. There is nothing more annoying than bisecting a bug and suddenly stumbling upon a commit that does it all: updates dependencies, touches everything under the sun, does cleanup commits for unrelated files, etc. Yuck.

Does anyone have other ideas?

Being this programming.dev, I feel compelled to suggest self-hosting a Lemmy instance.

The basics would be a simple personal webpage, which you can serve directly with a file server.

I like running syncthing as my personal alternative to Dropbox.

Some registrars like Namecheap offer services such as email rerouting, which gets you to use any custom email address in your domain through Gmail.

Don't pay attention to anyone mentioning CDNs or any nonsense of the sort. If your services aren't expected to serve a lot of traffic of have SLIs to meet, you do not need them. You only need a system with static IP address open to external traffic, and get your domain registrar to resolve a domain/subdomain to that IP address.

Just make sure everything you serve through that domain can be redeployed on a whim. A rarely discussed topic is how the internet is a wild jungle with dozens of vulnerability scanners running around the clock to find any unmaintained server they can exploit. Any server that's not managed by a professional team 24/7 fits that criteria.

…it’ll still be 35 users/month

I'm not sure you are aware how irrelevant this is. This could mean as little as a single user opening the community page daily, or 30 different users accidentally navigating into the community page from the main page just because an article showed up in their feed.

To frame the absurdity of this argument, I moderate !nodejs@programming.dev , which in the past month registered also 30 users/month, and that community is also dead.

I'm sure none of these domains were big traffic movers, but the change is still quite significative:

The affected domains represent a big loss for Cloudflare, with .tk, .cf and .gq previously accounting for 23.1% of all domains hosted on its platform – and nearly all of these have now gone.

Some companies trigger alarms if any of its KPIs drop single-digit percent rates. 23% is a massive drop by anyone's account. I'm sure Cloudflare will survive and barely feel a bump on the road, but I'm not convince that it will amount to noise.

I enjoyed the read so much that I've created a community dedicated to data structures and algorithms: !data_structures@programming.dev

No, you’re lying by using a different definition of “dead”.

Now you're being silly and acting defensively. I don't need to do anything for the !dotnetmaui@programming.dev group to be dead or remain dead, as it was expected to be. Anyone can take a look at it and see that if they filter out your personal inorganic traffic, which is already of dubious relevance, nothing remains.

You can stay up all night arguing otherwise, but it is what it is.

It's ok if you feel that it's your personal mission to generate traffic for a particular channel on a lemmy instance. Just don't try to pretend it's something that's relevant for anyone beyond yourself.

I’m a scientist, and “Not a real programming language” gives me big vibes of arguing that a thing is a science

CSS is not a programming language. Neither is HTML.

This, however does not take away from its importance or the skillsets and expertise required to use it effectively.

What a weird belief: thinking the value they bring to a project is tied to whether they use programming languages or not. The majority of people working with programming languages are already bad at it. Why is it being used as a badge of honor?

Is this a "living in glass houses" scenario?

If you want to use a fourth language, first you need approval to train every single employee in that language.

I've worked at a company where each and every single engineer was free to pick up what he felt was the best tool for the job.

It was an utter mess of unmaintainable code, and everyone wasted time trying to get projects not die out of bitrot.

Training people is not a problem. You also do not have to train everyone to create a single project in a particular framework/programming language. What you do have to factor into your analysis is the inefficiency of having to waste time managing multiple fameworks/runtimes/deployments/programming language development environments, and the lack of progress you will have in your team's skillsets if everyone turns into a one-man silo.

OP,

Here's a friendly reminder that programming.dev has a community dedicated to .NET: !dotnet@programming.dev

I wholeheartedly agree: the article is just plain stupid.

What I find more amusing is that front-end work ends up being the most critical work in any user-facing application. Apps can still lumber around if big chunks of backing services are down, but if a page is rendered poorly or a button is showing up weird, or if text is missing in a place everyone looks at, that's automatically a SEV1 right there.

Unbelievable.