We lo race conditions ve

Use locks, for fucks sake

@AndSoWeCode Say that to linux and the cowroot-Bug. 😂
It's not that easy with multi-cores.

@LinusCDE I code for double digit core counts all the time, and ain't got any problems with that.

Locks are key. Locks are important. Locks are what keeps the world fast and efficient.

@AndSoWeCode I am JS dev by trade, so single threaded all the way.

Learning C on the side, I did a project at uni and enjoyed it, so having a crack at it again

@Hedgepig I think JS is the source of all of this race condition panic out here.
Other languages and platforms support locks out of the bag, but I think not JS. JS is single threaded, but a lot of it has become asynchronous, so the thread switches execution from one block to another, simulating multi-threading. And from a programmer's perspective, it has the same restrictions as multi-threaded development. And with no locks on the market, I can see the dilemma.

But I would make my own locks then, though they would make it a bit more sync than without them.

@AndSoWeCode there aren't really any race conditions like the one I mentioned above. It is kind of annoying that things aren't so deterministic with async code though.

Also Async code in NodeJS is non-blocking. I can easily consume apis and read files at the same time. With promises and async/await this can even be coded in synchronous style.

@Hedgepig there are such race conditions if you have a loop that's appending to an array of chars 1 char each iteration

@AndSoWeCode not sure what you mean specifically (maybe provide a code example if you have time?). If you're talking about aysnc code then that's a pretty shitty way to code JS.

Using immutable data functions is an easy way to avoid that sort of problem

@Hedgepig immutable data functions are EXTREMELY (and I can't stress this enough) horrific waste of performance. And for this I say again: LOCKS

@AndSoWeCode premature optimisation is the spawn of the devil. Modern CPUs are blazingly fast. Code readability and maintainability should take priority.

With that being said, if optimisation is required, no doubt locks could be useful for async code

@Hedgepig that's exactly the fallacy that causes people with 16GB of RAM to buy 32GB when all they do is surf the web.
It's not premature optimization when you write code that's readable (not passing to a function mountains of arguments, or unpredictable data structures), and fast (not copying data structure for every single function call).

Performance consideration is very important, since it's the currency you're trading for new features. If you don't care about performance and spread your trivial app across all the resources, then you can pretty much bury it.

After all, if the app is trivial, why does it need multi-threaded or async stuff? But if it's UI-related, then performance is critical at every single step. If you make a text editor that eats up 50MB of RAM and 3% of the CPU I will crash and delete it immediately. People use laptops now. Laptops have batteries. How long it lasts depends on how good the programs are optimized.

The app I work on is non-trivial. The stack is mostly functional style.

Functional has many advantages over imperative, namely async code is a breeze to deal with without resorting to locks. Pure functions are reasonable, maintainable and highly testable. Same input, same output, every time. I can compose functions independly, pipe them though each other, map, reduce, filter.

Sure there are some overheads, but that's a good price for what I get

Build the app, and then profile it, and one sees where the real bottlenecks are.

Or else it's probably just a waste of time

@Hedgepig "a breeze to deal with without resorting to locks." - you say it in a way like locks are something bad. What's so hard about locks?

Map and reduce? Each of these operations will cost double the memory, and a huge premium in CPU time if you do it using functional programming. And yeah, that counts. In my case this luxury would cost an extra 5000$ per month in servers alone, and a shit ton of waiting time for testing this stuff, which costs even more developer money. And why? Because no locks? Locks are easy. Shared resources are the key to highest performance benefits.

@AndSoWeCode

In fairness my knowledge of locks are from a few embedded systems lectures back at uni

sounds like you work with very different kinds of projects.

I tell you what, next time I'm programming a resource intensive async on low memory I will endeavour to learn imperative style and locks.

For the moment though, unfortunately React can't really be coded without maps or functional style. But hey, benchmarks are still good so I'm happy.

@AndSoWeCode

Say I want to remove all odd numbers from an array

Exibit a:

function removeOdds(nums) {
const newArr = [];
for (let i = 0, l = nums.length; i < l; i+=1) {
if (nums[i] % 2 === 0) {
newArr.push(nums[i]);
}
}
return newArr;
}

Exibit b:

const isEven = num => num % 2 === 0;
const removeOdds = arr => arr.filter(isEven)