2 months ago
—
2 months, 1 week ago7 of 7
Tip Reveddit Real-Time can notify you when your content is removed.
your account history
Tip Check if your account has any removed comments.
view my removed comments you are viewing a single comment's thread.
view all comments
Yes, deterministic multithreading is still faster than singlethreading, but it is still slower than not caring about determinism with multithreading
Yep :)
But then when it comes to actually coding it, I feel like going multithreaded and doing it right would be such a hard task, especially for a team of devs on a large scale project (like Minecraft) that the time needed for it would make the business side reject it at every occasion. Also the boilerplate code that would be necessary to achieve this…
But then I’m jr dev so please correct me if I’m taking out of my ass since it’s not even my side of things
Writing multithreaded code is relatively easy if you write pure functional code. Since FP never updates any values ever, and race conditions always involve writing (write/write or read/write), all those problems are avoided. Since lambda calculus is Turing complete, you can write any program using a purely functional paradigm.
Well yeah I guess if you do purely FP maybe, but then they use Java and not say Haskell.
And I’m not saying that you cannot do FP in Java, but then it’s not what Java was made for, and for some reason they rewrote it in C# (I believe other than that it’s just their creation).
Isn’t bedrock c++? I think a big reason for the rewrite was better performance.
And yeah Java isn’t the best language for FP. But you can definitely write stuff with lees or no mutation if you know you’re going to have to deal with multithreading.
Oh yeah, C++, my bad. But still.
My main point is that it takes a significant chunk of development time in order to achieve it when ‘migrating’ the code base from something that was exactly the opposite. And higher ups usually don’t like when the time goes elsewhere rather than new features.