I have seen people wanting to do Java, and while I personally prefer rust, I do see why.
Outside of the entire Sublinks discussion, it’s important to note that Java is not just Java anymore either. Kotlin offers many of the same advantages syntax-wise that Rust does (including the lack of null), and has access to Java’s excellent ecosystem.
Ultimately, it is up to people to decide what they want to use. Regarding of your opinions on Java or Rust, it is a valid choice either way for this type of software. It’s a personal choice.
I’ve never really seen this in (Java/Rust/PHP) backend personally, only in client-side JS (the CORS preflight).
It’s a security feature for browsers doing calls (checking the CORS headers before actually calling the endpoint), but for backends the only place it makes sense is if you’re implementing something like webhooks, to validate the (user submitted) endpoint.
Java is a perfectly valid choice for something like this.
Yes, Rust is “faster”, uses less memory, etc…
Java is fast enough, though. It offers a fantastic ecosystem and, seeing as these projects are ran by volunteers who do this in their free time, there’s a lot more people willing to chip in some work.
Hey, it’s me, your friendly neighbourhood corporate shill, telling you to not buy any more nonstick cookware because I love Tefal so much. More for me!
But seriously, I’m not disputing that the chemicals you listed are bad, just that the coating itself doesn’t affect you.
PFAS bad, but only there during production. PTFE fine, and that’s what’s on your pan. PTFE does not get into your blood. Any PTFE you consume comes back out, because it is not PFAS.
TL;DR: use pan until pan bad, then buy pan with no PTFE.
Yes, the final product comes back out. The final product is PTFE, not PFAS. PTFE is harmless unless degraded or overheated (which is why you shouldn’t do that with non-stick cookware).
To produce PTFE, PFAS are used (or are intermediaries in the process), which is why the production is dangerous, but the product isn’t.
That stuff sticks to (aka reacts with) literally nothing. That's the point of it. The whole innovation of nonstick cookware was the fact they got it to stick to something. It’s not even dangerous if you ingest it, it doesn’t react with anything so it just comes back out.
What IS dangerous is the by products and intermediate products, as well as the stuff that comes off if you overheat it. (And also, like you said, when they get old)
This whole movement against non-stick is alright, but so many people do it for the wrong reasons. If you have nonstick, just use it and don’t buy nonstick next time. Throwing away perfectly fine cookware like that is like boycotting charmin by flushing down all your remaining rolls in one go and going to the store to buy new toilet paper from another brand.
I can see the case for some of them after you’ve been in a crash (although if the pyro fuse has blown, not much requiring switches will work anymore, regardless of the type of controls), but if you want physical controls for the rear view mirror for safety, you should probably start adjusting that before you start driving.
Same for cabin lights, whatever you’re doing that needs the lights on should probably be done stationary, if you care about safety.
it’s still comically bad compared to various alternatives, even apples-to-apples alternatives like C#.
I'd be interested to hear why. IMO Java has the superior ecosystem, runtime(s!), and community. The best part is that you don't even HAVE to use java to access all this - you can just use kotlin, groovy, scala,.... instead.
In terms of the language itself, while it (still) lacks some more modern language features, it has improved massively in that area as well, and they're improving at a significant rate still. It also suffers from similar issues as PHP, where it has some old APIs that they don't want to get rid of (yet?), but overall it's a solid language.
The difference being that when you’re 10 billion into a renewables project, you usually have SOME generation already, whereas your nuclear reactor isn’t doing shit until it’s fully completed.
I don’t mind nuclear, but the fact is that the reactors take decades to build, whereas renewables can be deployed far quicker. Going all-in on nuclear, and then twiddling your thumbs for 10-15 years while the reactors are built doesn’t sound like a great idea.
I don’t think programming language is a good metric for security. I assume everything I host has issues, and then try to mitigate from there.
IMHO, a better approach is to vet the project beforehand, looking at whether it is still actively maintained. I usually use things like commits, issues, etc to try and gauge whether a piece of software is actively maintained so that when an issue arises, it can be fixed.
You can mitigate much of the risk by using some basic best practices, like isolating all apps from each other (using docker, for example), using a reverse proxy, tools like fail2ban or a web application firewall, using proper database permissions for each app, etc
What I also do is add another layer by making certain applications accessible only over vpn. That won’t work for some tools, obviously, but also reduces the risk for tools you are only using yourself.
I have seen people wanting to do Java, and while I personally prefer rust, I do see why.
Outside of the entire Sublinks discussion, it’s important to note that Java is not just Java anymore either. Kotlin offers many of the same advantages syntax-wise that Rust does (including the lack of null), and has access to Java’s excellent ecosystem.
Ultimately, it is up to people to decide what they want to use. Regarding of your opinions on Java or Rust, it is a valid choice either way for this type of software. It’s a personal choice.