It’s not accurate to accuse Anon of “lying,” when both their story and yours would point to the race conditions from threads being a symptom of someone who’s just learning the language.
It’s not that serious though; because it’s a greentext, it is both artificial AND homosexual.
It’s not someone who is learning, because “how to avoid race conditions” is like java concurrency 101. The entire thing is made to prevent that shit from happening. And it is incredibly easy to setup a “happens before” relationship.
Been coding Java for about 15 years now. Pretty much agree - anon’s primary mistake was using javaFX. From a junior dev perspective I can see why they’d do that, but Java isn’t really meant for building desktop applications, it’s meant to power web apps.
What they should have done instead is create a backend restful web service and wire up a frontend rest client with something suited to web app ui dev such as angular or react. Java has some awesome frameworks built for it over the years, something like spring boot would make building that backend service trivial if you know how to use it. JAX-RS/Jersey or even servlets could be utilized for this instead, if you wanted to.
Spring boot has some nice tooling for thread management, but Java also has pretty good options for this built in as well. As chunky mentioned, if you aren’t already versed in concurrency patterns, don’t try to perform concurrent operations or you’re gonna have a bad time. But do learn how to do this, because exploiting concurrency is one of the golden rules of good computing.
What they should have done instead is create a backend restful web service and wire up a frontend rest client with something suited to web app ui dev such as angular or react.
If anon’s program was designed to work as a client for some external server or if Java had absolutely no GUI frameworks, that would be fine. But if anon’s goal was to create a simple desktop application, doing this would be the programming equivalent of a Rube Goldberg machine.
With that approach, you also need to be really careful about how you do it. Fuck that part up and you can end up with the locally-hosted REST server listening on the device’s public network interface or vulnerable to CSRF from a web page opened in the user’s browser.
Rust is great, and I truly mean that. But saying you can’t get race conditions in Rust is just not true.
And also, not everything is going to be written in Rust. When the company you’re working for needs a web application quickly, that’s better done in other languages.
And also also, Spring has a lot of niceties when it comes to concurrency that make this much less of a point.
Only in the context of data within the rust code. If you’re writing threaded rust that interfaces with external IO, for example, you can still get bit by a race condition. A person can absolutely be shit enough to hit a race condition in rust.
How would you run into a race condition like this with safe Rust? You can’t share mutable file handles between threads for example. I’m not sure you’re correct in saying its still possible. Even if it is, it doesn’t sound easy.
I’ve been programming in Java professionally for 11 years. It’s not just embellishment, it’s outright lying.
Threads giving you race conditions? All concurrent programming will do that if you’re shit at it.
Java has come a long way. I will admit that UI in Java is terrible. I would never do that.
It’s not accurate to accuse Anon of “lying,” when both their story and yours would point to the race conditions from threads being a symptom of someone who’s just learning the language.
It’s not that serious though; because it’s a greentext, it is both artificial AND homosexual.
It’s not someone who is learning, because “how to avoid race conditions” is like java concurrency 101. The entire thing is made to prevent that shit from happening. And it is incredibly easy to setup a “happens before” relationship.
Been coding Java for about 15 years now. Pretty much agree - anon’s primary mistake was using javaFX. From a junior dev perspective I can see why they’d do that, but Java isn’t really meant for building desktop applications, it’s meant to power web apps.
What they should have done instead is create a backend restful web service and wire up a frontend rest client with something suited to web app ui dev such as angular or react. Java has some awesome frameworks built for it over the years, something like spring boot would make building that backend service trivial if you know how to use it. JAX-RS/Jersey or even servlets could be utilized for this instead, if you wanted to.
Spring boot has some nice tooling for thread management, but Java also has pretty good options for this built in as well. As chunky mentioned, if you aren’t already versed in concurrency patterns, don’t try to perform concurrent operations or you’re gonna have a bad time. But do learn how to do this, because exploiting concurrency is one of the golden rules of good computing.
If anon’s program was designed to work as a client for some external server or if Java had absolutely no GUI frameworks, that would be fine. But if anon’s goal was to create a simple desktop application, doing this would be the programming equivalent of a Rube Goldberg machine.
With that approach, you also need to be really careful about how you do it. Fuck that part up and you can end up with the locally-hosted REST server listening on the device’s public network interface or vulnerable to CSRF from a web page opened in the user’s browser.
Well, if you write Rust then there won’t be race conditions.
Rust is great, and I truly mean that. But saying you can’t get race conditions in Rust is just not true.
And also, not everything is going to be written in Rust. When the company you’re working for needs a web application quickly, that’s better done in other languages.
And also also, Spring has a lot of niceties when it comes to concurrency that make this much less of a point.
You can’t get data races at least, and in practice it’s very difficult to get actual race conditions.
Only in the context of data within the rust code. If you’re writing threaded rust that interfaces with external IO, for example, you can still get bit by a race condition. A person can absolutely be shit enough to hit a race condition in rust.
How would you run into a race condition like this with safe Rust? You can’t share mutable file handles between threads for example. I’m not sure you’re correct in saying its still possible. Even if it is, it doesn’t sound easy.