Javascript hate thread

You can easily get race conditions in single threaded environments - it's the asynchronous nature which causes race conditions.

I didn't say it was nice to work with, but I think you're using the wrong term here. Undefined ordering is not the same as race conditions.

See The execution path isn't interrupted in anyway, meaning that race conditions are literally not possible.

`Undefined Ordering`

Is the term?

Attached: 1502571839160.jpg (641x530, 42K)

> Typescript
you are welcome

Attached: F55F4525-2AB6-4BDE-8F6E-E4A51F63E0D2.jpg (776x1024, 122K)

Webshits dont know what multithreading is or how it works

Havnt used it yet.

You recommend?

Hey it's got perfect interop.

>>single-thread execution exclusively
Web workers exist now.

if (_someGlobal == null)
{
// InitFunction should only be called once
_someGlobal = InitFunctionWhichDoesAnAjaxCall();
}

This is a pretty common race condition in javascript. Executing the InitFunction will potentially run other functions on the event queue, which might hit this place again, calling the init functino again (since the global is still null)

Also the execution path is interrupted in js, if you do window.settimeout(func, 0) or do an ajax call, then other things on the event queue will be executed.

Not sure if it is a well established term or not, but I'm quire sure that "race condition" is not what you mean.

Below is an example of a potential race conditions, two threads calling the unsafe variant simultaneously may end up getting the same number. In JavaScript, this isn't possible because execution is single-threaded, meaning that your functions will always execute until they return without being interrupted.
int unique_counter = 0;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

int read_and_update_unsafe()
{
int copy = unique_counter++; //

Its pretty much gonna make your JS static and readable as C#, you can use TS on its own, however I would recommend Angular, it's a nice framework built with TS.

You can also get race conditions between the server and client as well

>Also the execution path is interrupted in js, if you do window.settimeout(func, 0) or do an ajax call, then other things on the event queue will be executed.
Immediately, or not before your function returns?

Will the following code result in an indeterminable sequence, or will it always be 0...1000 ?
function foo(i)
{
if (i < 1000) {
window.setTimeout(() => foo(i + 1), 0);
}
console.log(i);
}

Good to know.

My big thing is a well defined signal slot mechanism.

This "keep checking every second until this object is no longer null" solutions on SO drives me up the wall.

Attached: 1501640391935.png (540x461, 195K)

Other things might be on the event queue in that case which would definitely make it indeterminable.

Otherwise, it would probably give you 0 - 1000 - but im not sure if the event queue order is predefined in the javascript spec, it might just be all browsers use a queue. Definitely something to check.

Whether it does or not doesn't really matter, since when I saw my example in real life, any bunch of random functions could have been on the event loop. The point is the bug only happened if there were functions on the event queue which would reach the check before the initialisation logic completed - which is a classic race condition.

Use promises or await, fucking retard, and there will be no race condition

>posts jQuery
>JAVASCRIPT SUCKS REEEE

>Other things might be on the event queue in that case which would definitely make it indeterminable.
That's not exactly what I asked, though. What I'm rhetorically asking is, will execution be interrupted immediately after the call to setTimeout(), or will setTimeout() simply schedule a new callback on the event queue (the answer is the latter). This means that execution will never be interrupted, but scheduling from the event queue may be unknown. That's not what people would technically call a race condition, which would be more like the example in .

>jquery isnt javascript

Attached: 1502574913763.jpg (204x306, 7K)

>jQuery introduces a new syntax and a shit ton of unneeded functions that isn't used by vanilla JavaScript
>ever since ES6 there have been vanilla alternatives to jQuery that run faster and has a better, more consistent syntax

It isn't? It's just another library that basically became legacy at this point.

I'd say that is a very specific and simple kind of race condition (a data-race), but race conditions are just when the programmer has assumed an ordering, which isn't actually gareunteed. It's a really wide problem.

wikipedia has "A race condition or race hazard is the behavior of an electronics, software, or other system where the output is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when events do not happen in the order the programmer intended."

Ofc I agree that in javascript unless you do a window setTimeout (or ajax call or some async thing) the execution is deterministic.

Another example of a race condition i've seen is when class definition in javascript aren't output (using eval) in time for a method which depends on these classes, which resulted in an undefined error. This was a race condition involved not only on the client, but also on the server! Very horrible.

>things like ReactJS and jQuery are proper vanilla JavaScript

Attached: image.jpg (638x558, 107K)

Retard
class LoadExternalSources {
constructor() {
this.successHandler = () => (this.resolve(), this.clear());
this.failureHandler = e => (this.reject(e), this.clear());
}
clear() {
const { dom, successHandler, failureHandler } = this;
this.dom =
this.resolve =
this.reject = null;
dom.removeEventListener("load", successHandler, false);
dom.removeEventListener("error", failureHandler, false);
dom.remove();
}
setup(url) {
return this.url = url, this;
}
then(resolve, reject) {
if (!this.url) return reject(new Error("URL is not defined"));
const dom = this.dom = document.createElement("script");
this.resolve = resolve;
this.reject = reject;
this.url = void (dom.src = this.url);
dom.addEventListener("load", this.successHandler, false);
dom.addEventListener("error", this.failureHandler, false);
document.head.addpendChild(dom);
}
}

async function init() {
const urls = ["shit", "cunt", "etc"];
const loader = new LoadExternalSources;
for (const url of urls) await loader.setup(url);
main();
}

Okay, I guess the source of our disagreement is what we call deterministic execution. My argument is that execution is deterministic, because functions are executed single-threaded. Your argument is that it isn't deterministic because callbacks may occur in an unknown order depending for example on server response time and similar. I guess you could say that it depends on the granularity we look at it: statements in a function in my case and order of function calls in your case. Using your definition, there definitively is a potential for race conditions. So in that regard, you are right.

However, this can relatively easily be dealt with using trivial await and promise semantics. Multi-threaded race conditions aren't always that trivial to deal with.

>Its a library
>Its not javascript
>!function(e,t){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=e.document?t(e,!0):function(e){if(!e.document)throw new Error("jQuery requires a window with a document");return t(e)}:t(e)}("undefined"!=typeof window?window:this,function(e,t){"use strict";var n=[],r=e.document,i=Object.getPrototypeOf,o=n.slice,a=n.concat,s=n.push,u=n.indexOf,l={},c=l.toString,f=l.hasOwnProperty,p=f.toString,d=p.call(Object),h={},g=function e(t){return"function"==typeof t&&"number"!=typeof t.nodeType},y=function e(t){return null!=t&&t===t.window},v={type:!0,src:!0,noModule:!0};function m(e,t,n){var i,o=(t=t||r).createElement("script");if(o.text=e,n)for(i in v)n[i]&&(o[i]=n[i]);t.head.appendChild(o).parentNode.removeChild(o)}function x(e){return null==e?e+"":"object"==typeof e||"function"==typeof e?l[c.call(e)]||"object":typeof e}var b="3.3.1",w=function(e,t){return new w.fn.init(e,t)},T=/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g;w.fn=w.prototype={jquery:"3.3.1",constructor:w,length:0,toArray:function(){return o.call(this)},get:function(e){return null==e?o.call(this):e

Attached: 1502658920897.png (1190x906, 270K)

>hasn't learnt how to use await.

This man states that TypeScript is the same as JavaScript.

JS just works.
Deal with it.

Don't care about your made up shit, that literally never happens in real code like adding Objects and Arrays, etc.

JacaScript is fun to use and efficient to work in.
Add Node/Electron into the mix and you can do almost anything with it.

Top language.

Attached: 1542850071343.jpg (438x428, 18K)

>thinks jquery is typescript

Yeah I think that makes sense - whether you look at just a function or a series of functions as a unit of execution.

I still think it can be hard to deal with js race conditions - one of the problems being that it's easy to not notice a race condition (even if the solution is simple) till production.

>"jQuery is an exception, every set of JavaScript libraries that alter the syntax isn't JavaScript, but jQuery is, because I say so."

>one of the problems being that it's easy to not notice a race condition (even if the solution is simple) till production.
I've always argued that test code should use delays (at least random) in order to simulate network latency.

You can also still get the race conditions I've talked about even using await - the server side ones are not helped at all by await and certain global variables (like my example) are still a problem even with await. Of course you could argue that global variables are bad, but sometimes they are hard to get rid of.

There is no such thing as a dynamically typed language. There are only typed and untyped.

Attached: 1542409012334.gif (540x540, 577K)

even using delays it's hard to find, or at least that's been my experience. I think formal methods and static analysis (e.g. banning global variables) are much better solutions.

race conditions are horrible, horrible problems.

Can someone give an example of a race condition that isn't the product of bad code?

That is about as retarded as stating that `Qt` isnt `C++` because `QString` isnt part of `stdlib`.
JQuery is javascript.

Attached: 1508997862012.png (632x852, 47K)

If you want it written in javascript, then no.

Then why the fuck is TypeScript and ReactJS NOT JavaScript?

No one said that you fat 800 pound fuck.

Attached: 1501774074453.png (396x381, 130K)

It's not hard to realize that everyone so far who has dissed JS for whatever reason is an absolute brainlet, probably some dumb crossboarder too.

I bet you looooove python

Typescript is a superset of JavaScript. It is compiled down to Javascript, and does not exist at runtime (unless you tell it to inject polyfills and such for you, but that is not a language level thing). ReactJS is a Javascript library, written in Javascript. JSX is a syntax often used to write ReactJS in a more convenient way. JSX is not Javascript, it is compiled to Javascript.

jQuery is a Javascript library written in Javascript. At no point do you need to compile jQuery from some non-Javascript language. This is not a complicated topic, and it is not Javascript-specific.

It sucks because a lot of the people attacking/defending JS are ignorant of it, so the entire argument is just inane fingerpointing and strawmanning. You almost never see any of the real reasons to criticize JS, it is just shitty developers projecting their inability to use asynchronous languages.

Whats the real reason to criticise js?

Attached: download.png (500x706, 283K)

is there something about javascript I'm missing?

>> no pointers
>> poor standard library (hard to do things like convert a string to utf-16 bytes or utf-8 bytes)
>> not only null, but also undefined
>> bizarre equality
>> silently fails when misspelling variables or failing to return
>> no types so hard to refactor, easy to do errors, hard to find what's supposed to be passed to a function (can't just press f12 on the type)
>> slow
>> no threading (communicating between web workers is hard/impossible since you can't share references)
>> extremely dangerous features (overwriting existing methods in prototypes)
>> prototypes generally are poorly understood

(cont.)

Almost forgot but the absolutely worst feature of javascript is that it doesn't have integers. Just bizarre. If you want to store a precise time using a 64 bit integer, you have to use a weird mashing of two int32s or some kind of list of doubles.

Reminder all the "faults" about dynamically typed languages are a case of dev incompetence who can't write for shit, prove me wrong

Attached: 367373467.jpg (477x477, 41K)

how the fuck you get race conditions in a single threaded language?

>no pointers
JS is a scripting language, it could have pointers if your runtime environment allowed it.
>poor standard library
JS doesn't have a standard library
>not only null, but also undefined
Having 2 bottom values is indeed not that great, but checking for either of them is easy x == null
This is also the only legitimate usecase for the loose equaly operator.
>bizarre equality
Just use strict equality operator if you don't want to opt into type coercion.
>silently fails when misspelling variables or failing to return
strict mode makes your code throw if you assign like that
there is no such thing as failing to return
>no types so hard to refactor, easy to do errors, hard to find what's supposed to be passed to a function
typescript and flow exist, but well named parameters and intellisense in untyped JS also are a thing
>slow
All major JS runtime vendors JIT the shit out of JS code. It runs very fast for an untyped scripting language.
>no threading
Threading exists and your only ways of communication are message passing, SharedArrayBuffers or handing over ownership of ArrayBuffers
>extremely dangerous features (overwriting existing methods in prototypes)
That's a very subjective point. Polyfilling also relies on this, where you must reassign prototype methods where the method is not spec compliant.
>prototypes generally are poorly understood
Not the language's fault. They are very easy to understand with a little effort tho.

>doesn't have integers
BigInt is a thing and it allows integers of arbitrary width

Lots of arcane features that should have been dropped a long time ago ("with" operator, for example), poor introspection into task/microtask queue, random features that were added as hacks to improve performance yet have mixed support ("use strict", "asm.js"). Nonexistent introspection into sandboxing (try using "instanceof" with objects from different windows), no introspection into garbage collection. Godawful hacks built into the engines to support use cases that only idiots would use (look up the Google Chrome Developers talk on "for loops", now that async/await exists).

Personally, I dislike the standards body. It is great that TC39 does things in the open, but companies like Google have wayyyy too much sway. Look at the Cancellable Promises spec for an example of a relatively robust proposal that was dropped because of company politics.

/thread

References:
(with) - developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with
(instanceof) - developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof#instanceof_and_multiple_context_(e.g._frames_or_windows)
(for loops) - youtube.com/watch?v=Nzokr6Boeaw
(Task/microtask queue) - jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/
(Cancellable Promises proposal) - github.com/tc39/proposal-cancelable-promises/issues/70

>thinks code is written more than it is read

Glad I dont work with you.

its read by the computer

`Read`, but not comprehended.

This guy gets it.

>with
Not allowed in strict mode
>task/microtask queue
The event loop is not supposed to be exposed to the user and it's fortunately not.
>random features that were added as hacks
strict mode is a core language feature, asm.js is an experimental feature by Mozilla's runtime environment. It's been superseded by WASM which is now a core W3C technology.
>instanceof
is just a syntax sugar for checking equality with the constructor. Object tag names are there for a reason and you can make use of those easily.
>no introspection into garbage collection
That's quite subjective. JS is a very high level scripting language, I don't think you should be able to mess with the underlying engine to that extent.
>for loops
Pretty much every language behaves that way and it's good to be consistent with others when it comes to simple things like the for loop

I appreciate most of your counterarguments. When I referred to the queue introspection, I was more referring to inconsistencies between implementations, though I am guessing your response would be that it is an implementation detail regardless.

I understand that the 'use strict' directive is a fairly well supported feature. My argument was that such a "feature" had to be hacked in as a way of backtracking on existing language functionality. For example, "with" being disallowed in 'use strict', when I'd argue that it'd be better to just make that the norm. Backwards compatibility could potentially be a browser setting (off by default), that simply caused JS to run in an older engine (think Python 2/3). At a certain point we need to jettison the garbage that is either no longer relevant, or adds cruft to the language.

The garbage collection introspection would be helpful in environments like Electron, or even IoT devices. Being able to specify regions to not be collected, etc. Not really something I've given a ton of thought, but I can imagine exposing some JVM-like features could be a boon. I'm sure some nice WeakMap functionality could be added this way as well.

Either way, glad to see someone has some sense on this board.

for loops act like that in pretty much every language?

In C++ too?

Attached: 1536525807549.png (817x656, 127K)

JS is not responsible for inconsistencies between vendors when the expected behaviour is well defined (it is).

This whole strict mode thing ties into the philosophy of "not breaking the web". JS has _the best_ history of features being introduced that don't break already existing code. Barely any other mainstream language has that property and for JS it is a must, because there are far too many websites that would break if anything would change. a Python 2/3 style event will never occur to JS, instead TC39 is steering the language in the C++ kind of way, where they introduce new, safer and more concise way of doing things that were otherwise errorprone, clunky and required too much boilerplate.

This GC thing is very subjective, again, if you wanted to then you could do things however you wanted with hacking together things with Duktape, however since asm.js there have been ideas floating around like typed struct objects, strict types, more direct reference handling, so maybe eventually we will see things like that. But as it stands now we don't have such facilities.

Yes.

I figured that'd be your response, fair enough. I suppose things like fetch priority are just building upon higher abstractions than the task queue itself to enable fine control.

Yeah, I get the backwards compatibility philosophy, but I think it'd be relatively as easy to have JS engine directives that say "use ECMA7" or something silly like that. I think the C++ way has resulted in some pretty severe language bloat (which JS already has) and I believe it'd be worth spending the time figuring out a way to get ahead of that curve.

That's it for me for this thread, good talk.

[1,2,3,4,5,6,7,8,9,10].sort()
> [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]

Why would the youtube title then specify 'Javascript For Loops... are complicated,

instead of,

'All for loops are complicated.'

And further go into detail why for loops act differently in javascript then what they were taught.

Attached: 1544395397139s.jpg (125x70, 1K)

Dynamically typed languages are a terrible concept. And if you absolutely need that kind of featureset, any competent programmer can implement it in C/C++ with much safer outcomes and less UB

LMAO
What?

*dabs*

Attached: Screenshot_20181219_193813.png (752x108, 12K)

I forgot to address your concern regarding the cancelable promise proposal. Well indeed that sucks, however upon closer inspection I'd say the changes the proposal would have introduced to the language are pretty bad. As there is no backing off when something has bee introduced already, only very well thought out concepts make it to standardization. I would like cancelable promises myself as well, but that proposal was simply not it.
Good talk indeed, it's rare to have such conversations when it comes to JS on Jow Forums.

The video should have been titled "How variable hoisting and the result scoping rules affect your loops". This only happens because they were using var instead of the new const and let keywords. Variable hoisting is a whole can of worms in itself and there are better venues where you can educated yourself about the topic than some bored user on Jow Forums. I recommend reading up on it on MDN maybe if you are interested.

devdocs.io/javascript/global_objects/array/sort
JavaScript tries its best to _correct your error_ and so it has a default behaviour. If you don't provide a sorter then JS will sort based on string code points.
If you think about this for maybe 5 seconds then you will realise that the web is very much a string oriented platform and JS was designed for the web, it only makes sense that default like this exist.

> If you think about this for maybe 5 seconds then you will realise that the web is very much a string oriented platform and JS was designed for the web

Which is why fucking abominations like node electron should die horrible deaths in a fire.

But if JS had integers...

I dont know man. I really dont like this constant excuse that JS, an extremely high level scripting language, is not responsible for bad coders.

Pure C and things that work closer to the hardware, you could make that argument, but not with a scripting language with built_ins like `sort()` have quirky and whacky behaviour, where integers are strings and people marry their cousins.

It's a tool. Use it to build shit and make money, or keep being a queer and sit around posting complaints on anonymous image boards. Software turns to shit the minute it's written, pretty much everywhere in every language and environment.

Electron is undoubtedly the easiest way to make cross platform GUI applications.

Like I said above, JS already has integers as a core language feature. If we look at implementations, then numbers are treated as a supertype of doubles and int32/uint32. This blogpost talks about this topic v8.dev/blog/elements-kinds Smi here just means small integer (int32/uint32)
The sort() builtin doesn't have any quirky behaviour. You didn't provide any sorter function so it uses its own default one which coerces things into strings and compares based on code points.

Heroin is undoubtedly the easiest way to deal with all your problems. That doesn't make it a good idea.

That's a very dumb comparison, user.

>just design the language that will become THE language for the web in two weeks, bro
>just make every number a double, bro
>just perform bitwise operations on doubles, bro
>just add new CPU instructions to deal with the monster you created, bro

NO U!

>This is a pretty common race condition in javascript.
Then most people writing javascript are retarded.

When JS was created PCs were mostly 32bit and it made sense to use doubles instead since doubles can express more integer values than 32 bit integers could and the IEEE 754 format was very widely implemented in hardware already.
Bitwise operators cast their operands to 32 bit integers first before doing anything.

>bitwise operations on doubles
I dont see the problem. Its quite annoying that you cant do it in C actually without type punning.
Its an efficient way to implement fabs without having to include and link math.h

>I dont see the problem
doubles are floats, bitwise operations only make sense on ints

>Bitwise operators cast their operands to 32 bit integers first before doing anything.
Yes, and that's inefficient.

>Its an efficient way to implement fabs
It's an efficient way to write non-portable code.
>without having to include and link math.h
Wow, imagine having to include and link math.h.

>only make sense on ints
-1.11111 (in 32-bit IEEE754) & 0x7FFFFFFF = 1.111111
I've done this plenty of times in assembly programming for microcontrollers

>to write non-portable code.
Not all code is meant to be portable, some is meant to be efficient.

>unironically recommending CuckScript
wew lad

bigints aren't a standard feature yet.
they really aren't in order to use doubles as int32s, you have to use bitwise operators to cast them. And you can't use doubles for 64 bit integers
threading where you can't share memory is a very restricted form (you can't even send objects since that would share memory).

intellisense for untyped scripting languages is always going to be bad since it's impossible to find all the references (since objects are just hashtables and the strings used aren't known at compile time). Typescript is good, but it's not javascript.

not having a standard library is bad.

strict mode gets rid of some errors, but sometimes you get strange casts which means code which should throw an exception silently does nothing. And when working on a large codebase, some people may have used banned strict mode things (like editing arguments). You can blame the codebase, but it's still a reality that strict mode isn't mandatory which means it's not the silver bullet.

You can have a function fail to return by returning undefined. it's a very common error (just forget to type "return") and again you have a function which is silently failing.

bunch of other problems I forgot -

no in built dictionary and inbuilt hashcode function for objects. You can use objects, but then you effectively have to use strings as keys.

The bizarre this binding

the lack of gotos (makes compiling to extremely difficult since you need to detect loops and conditionals)

that's a very simple version, you can have very large code bases where it's unclear what depends on what. plus people can be in a hurry, stressed out and make mistakes.

I don't know man, I worked with Tcl for a while, it looks like JS's sort is behaving like default lsort in tcl or the sort unix program. you need to tell them both to sort numerically

ES6 is awesome.

I did a Cast(holdsUndefined) on a string and then when I did "Undefined".indexOf(holdsUndefined) it ended up returning a positive value.

WTF