I agree that they are problems, but their impact on day to day use of the language is zero.
If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to death by the community.
The language itself is the last problem with JS
I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard.
I guess worse really is better.
While I understand that a problem like this is unnerving, it isn't the rule.
People throwing around strawmen in here like nobodies business.
We can do this with all languages and tell ourselve we're using the "superior" language.
How exactly? I'm really curious. AFAIK it's pretty hard for a JS string to be casted into anything (pretty easy the other way around though).
I guess maybe parseInt can do that, but that's neither casting not implicit.
I could easily reproduce the bug but it took me forever to work out why JS was choking. I think I added in some ridiculous string padding to prevent the auto casting.
https://stackoverflow.com/questions/2547836/why-doesnt-an-oc...
That was published 9 years ago.
I do agree with you that the JavaScript community's issues you mentioned are hell to deal with; however, in my opinion, JavaScript's internal weaknesses are one of the driving factors behind this churn.
> re: it doesn't have multiple ways of declaring a function...
Python does have multiple ways of declaring a function, the usual `def` syntax and via `lambda`. Lambdas are restricted to one line (due to Python's whitespace sensitivity), which can be inconvenient (but hey at least no one can abuse it right?).
Python functions also have a scoping gotcha: you can read the variables in the outer scope, but if you write to it (without declaring it as nonlocal) it actually treats that as a separate variable declaration (this is due to its assignment syntax).
> re: Python's datatypes are straight forward...
While Python's type system is nowhere as lenient as JavaScript's, there is at least one unexpected case which works: `True + 1` produces as valid result (2). Also, having to explicitly cast non-strings is rather inconvenient when concatenating stuff to produce a string (even Java doesn't require this). Thankfully, Python has a decent string formatting function built-in.
> re: 9999999999999999 is precisely 9999999999999999
It'll still fail if those are floating points. Yes, I am aware that Python has decimal and rational types in its standard library. My point is, no matter what language it is, programmers need to be aware of the data types and data structures they are dealing with.
FWIW, I don't think JS is better (or worse) than Python (as long as we're talking about "modern" JS with modules). Python also has its fair share of major issues, notably v2 vs v3, which is slowly becoming a non-issue as everyone (finally!) migrates to 3.
JavaScript is more dynamic than most languages and yes this may be hard to grasp for the average developer, especially when they come from languages that are considered "more mature".
True, and we could go one step further: it's unambiguously defined, with invariant rules that can be used to prove a conformant implementation.
XMPP had been defined as formally: where have we ended up with it now?
Python's type handling is much better, but that can be mostly avoided in JS by understanding and avoiding the cases where js typing sucks.
Other than Python's superior type handling and standard library they seem like very similar languages to me.
JavaScript numbers are IEEE754 double precision floating point format.
But I'd wager that the "no integers over 2^53" is seldomly a problem, and in most other languages there's a similar problem at 2^64. If you reasonably expect to get integers above 2^53, you probably want to think about how to deal with integers above 2^64 as well. So really it's the exact same thing except JavaScript's numbers are easier to complain about on the internet.
I did some Ethereum front- and backend development in both Python and in JS, and this made a lot of difference in the readability of the code. In Python, the only problems we encountered was when writing into ndb, which has 64 ints by default, whereas in JS, we had to use BigNumbers everywhere.
Pretty cool! Learn something new each day :-)