Can somebody please design even worse language so that we can progress by reimplementing everything in it, keeping us occupied for the next 20 years?
And no, a JIT can't save you from this, it can only make things acceptable.
That it can create "real world value" is an extremely low bar, which is passed by any turing complete language. COBOL creates "real world value".
From everything I've seen, its performance sits just below Java (4x slower, perhaps) on some standard algorithms or tasks, and significantly faster than languages like Ruby, Python, etc.. I never see hate for those languages like for JS, so I'll disregard that.
>not terribly good
This one never has made sense. What is it missing that makes you hate it so? I think it has rather robust asynchronous handling, 'everything is an object' has lots of nice implications when paired with functionality like Object.keys / .assign, ... So what are the issues you see that make it 'bad'?
"4x" is a lot slower, and a lot of things are much worse than this. You have to have deep knowledge of the VM (such as knowing how "hidden classes" work in V8) to be able to get JS close to Java.
> so I'll disregard that.
You shouldn't. Claiming a JIT'ed language is fast due to being faster than Python, an entirely interpreted language, is like saying a moped is a fast vehicle because it's faster than biking. Apples and oranges.
Being faster than PyPy, the JIT'ed Python implementation, is a more interesting thing, but this is still very far off "fast" languages.
> What is it missing that makes you hate it so?
Most language features, really. "Everything is an object and objects are hashmaps, EVEN ARRAYS" (terrible for performance, type safety), "array of int16" strings with totally broken unicode codepoint handling (ES2016 brought new ways to deal with codepoints, but the standard way is still broken), the "Number" type which is totally retarted, the terrible "prototype" system, the malice that is "this" and how any bare function expression had its own this context (arrow functions are a good workaround now), and god I could go on.
"Everything is an object" is only useful if you either actually need a hashmap (then use one!), or you have sloppy types.
JS, as a langauge, is not well designed. I'm not saying it had to be Haskell or Rust, but JS is far below average.
It works, and does it job decently due to the very hard work of JS engine implementors trying to make this crazy thing fast, but that's not the same as being good.
That's a solid argument for only programming in C and Assembly because they are often 4x faster than anything.
> Most language features, really.
AKA, your preferences are "language features".
> Everything is an object
So you don't like Python. Or Ruby.
> the "Number" type which is totally retarted
Very technical argument there.
> the terrible "prototype" system
So you prefer classical inheritance. Cool. Doesn't mean prototypal inheritance is a bad thing.
But you still have to compute hashcode yourself :D
Name a few.
>terrible "prototype" system
>malice that is "this"
It sounds like you are talking about ES5, not ES6+
He did, literally exactly after that sentence.
Nope. No it does not.
JS is not the only language with nice async support, practically every mature language has async support and a good number of the compiled ones have proper parallel support as well.
sure wish i knew what you are talking about w/r/t "silently failing". JS has working exceptions just like 99% of widely used languages.
Do they now?
irb(main):001:0> "0" + 1
TypeError: no implicit conversion of Fixnum into String
from (irb):1:in `+'
from /usr/bin/irb:11:in `<main>'
>>> "0" + 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
> "0" + 1
If you never worry about those things, then you're either not sharing any resources at all (in which case threads are also dead easy), or you're failing to deal with the shared resources properly.
DBs, files, etc etc. in-process memory isn't the only resource you're sharing.
No, that's not true at all. Dynamic languages don't necessarily have type coercion at all, much less weird behavior around it (and, conversely, statically typed languages they have coercion may have weird behavior around it; there's just no link between dynamic typing and weird coercion behavior.)
Well, if someone has to do it, I will: not doing type coercion isn't weird, and doing inplicit type coercion (not strict promotion) is both weird and dangerous.
But, in any cases that's not really the point. The point is that in this...
> Every dynamic language treats things slightly differently.
“dynamic” is irrelevant. Languages have a wide variety of approaches, doing promotion, coercion, neither, or both (though where both are done, it's often just called coercion even when it is promotion), and dynamic vs. static is mostly irrelevant.
 that is, where the “from" type has a range that is a subset of the range of the “to” type.so that there is never a change in meaning resulting from the conversion.
Yeah, and I can do the same thing in Python, and it will be equally as lame: both languages are fundamentally single-threaded.
You act as if JS has all problems solved: Erlang/Elixir/Golang have far superior async & parallel stories and will happily thrash JS/Node in performance and efficiency.
How’s it working out for me? Well I do a lot of stuff in Haskell and Rust now, so pretty great actually.
1. Type Safety. TypeScript helps, but until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. This is also true of Python, et al.
2. A sane dependency management framework. Maven solved this problem a decade ago. Gradle is trying to fix Maven's XML mistake. But the fact is, if I need a dependency in Java, I know how to get it. And as a bonus, Maven Central isn't going to go down next Tuesday because Timmy in Alberta threw a temper tantrum or something.
There are quite a large number of counter-examples to show type safety isn't especially important to the success of large projects.
I think the guarantees it provides are far too limited and weak to support large software systems. It relies on static code analysis, which doesn't mean much unless your app is a single build and runs as a single instance. That's more of a '90's style Microsoft Word type of app than what a typical large software project is today. Meanwhile the guarantees it does provide are only helpful to the extent developers can map their domain problems to the capabilities of the type system. Sometimes there is a nice natural fit, but usually the typesystem is both too weak (doesn't provide a convenient and natural way to impose the constraits of your problem domain) and too strong (imposes constraints your don't need or want, encumbering your development process).
There are massive JS projects in production today, but that's moot. It's never going to be mandatory because that ruins the point. Typing isn't a requirement of a language.
> A sane dependency management framework. Maven solved this problem a decade ago.
A Rube Goldberg machine that solved a problem? Maven's goals may have solved the problem, but its implementation did not.
Feature, not a bug.
The only other language that I have seen generating as much hostility is vb6, and also I believe because some developpers found themselves forced to use it.
I use Elixir + Ruby + Coffeescript and I still wish JS was never invented.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
- Bjarne Stroustrup
Luckily, filesystem designers worked hard at making their filesystems journaling, fault tolerant, and more. And we stopped complaining angrily about filesystems ruining weeks (or months) of work, because it stopped being a regular occurrence.
We still complain about the flaws of C++ because they are a constant source of pain.
Stroustrup is arguing that if something is popular criticisms against it must therefore be invalid. He's wrong.
No. Stroustrup uses his snarky retort to deflect criticism. When C++ is criticized by (academic) language designers, his comment reads as "and yet people use my language and not yours". And that's pretty immature.
Popular tools have to meet a high quality standard because every wart in the language affects millions of people.
Are you suggesting C or Haskell are without their problems? What is your definition of a "good" language?
Other languages have great ideas in them, but the languages themselves are a mixed bag. Perl, Java, C++. Perl inspired Ruby. Java inspired C#. But we haven't seen a good successor to C++ yet, probably because building a systems language is much more difficult than building an interpreted/scripting language.
Maybe D, but outside Facebook nobody really uses it.
Existing projects were written in whatever language for whatever reasons, it's "Would I start a project in this language today?" that's the bar to beat in terms of language "quality" and, in that sense, COBOL is a fairly low bar for most domains.
Some extra hoops to jump above "delivering value (measured in revenue)" are:
- Not creating extra problems for yourself down the line (maintenance costs, complexity, technical debt).
- Not creating extra problems for everyone else (promotion of technologies causing problems if adopted).
- Not dumping externalities on other people (inefficient solutions causing worse UX, more frustration and extra electricity usage).
- Delivering actual value, as measured on the user end (whether or not the software makes them more productive), instead of revenue end (i.e. did we manage to trick enough people to pay us?).
Of course I do hope something else has taken its place.
Every time someone waits for an Electron app to load, or watches it eat their ram? That gets added to the prejudice scale. Every overly-slow page load that eats mobile battery. The feeling that "it doesn't have to be this way" is very strong.
Maintainability is a problem regardless of language, scaling is moot as these run native code, scalability is an odd word choice given we are talking about desktop apps, and intrinsic conversion can be solved via TypeScript, Flow or any other typing framework. C, Java and C# all have their own set of downsides as well, but we don't pretend those aren't "real" languages.
You are correct that "it doesn't have to be this way" which is why native compilation exists and is continuing to grow.
Microsoft are using React Native here (aside from the Win32 build), which is going to be a lot more lightweight because it relies on the native platform for the heavy lifting.
There are pros and cons, but within the next few years it could become common to write in your language of choice, compile to WebAssembly, and ship an app that’s within roughly 50% of native speed.
I imagine JS will still be hugely popular even in that scenario, but that’s a different topic.
There, I fixed that for you. I didn't miss the boat. I've had to maintain mountains of awful code written by careless programmers in a pathetic language with a morass of constantly changing libraries for run-times (web browsers) that can't even be counted on to interpret the code the same.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup
It's too big for a TLDR;
But, just #1 in that list - You need to use a utility library to work with data types in a normalized form? In 2018?? Let that sink in. I hadn't had to do this with any other language.
What's wrong with JS, exactly, that isn't made up for by its advantages?
I see these 'kool-aid' / 'JS is cancer' comments all the time, but they don't come with any real details.
I feel like you've probably never really used JS, if I'm being honest.
JS's only unique, redeeming quality is its availability through the deployment of web browsers, and the benefits that come with such widespread use. JS wins marketshare because it has marketshare. Any language could have taken JS's place, and most would have been better. WebAssembly, when DOM integration and others become a thing, might allow us to throw JS off its throne.
JS doesn't have advantages on its own to make of for its disadvantages, and relies heavily on extremely advanced JITs to make it borderline acceptable. The language itself still has very clear signs of having been designed on the back of a used napkin (its number type, its "array of int16's" string, "this", "prototype", ...).
I would like to acknowledge that ES2016 brought some things that did remove some retarded areas of JS (like arrow functions, which do not have its own "this" context, unlike the old function expression, class definitions that can briefly make you forget the terrible underlying "prototype" madness, and ways to access proper unicode code points in strings), but we are very far away from having actual advantages here.
I wrote bleeding-edge games and other crazy stuff in JS you might be using right now in your business, so my opinion is not unfounded.
On the web, and now suddenly on the desktop, velocity is not what we need. We need quality and consolidation. Down the line can you see any ES6 based API lasting as long as win32? Hell no. Why would I want to risk building a major capital product on such guarantees?
From a technical perspective, there are couple disadvantages in the long run that can make large codebases unmaintainable. In particular JS and PHP are resistant to static code analysis since they support functions like exec. So it becomes difficult to deprecate functions because the references are not necessarily explicit, thus can lead to tech debt buildup. ES6 does a better job but its backwards compatibility can leave the code vulnerable.
I think the prestige comment is a bit unfair, but today at work I had to educate a JS dev on what headers are in a HTTP request/request and some other pretty basic things (a dictionary/record type object and a JSON string are not the same thing for one). They were like "I know I've got to do these things, but I don't know why/how they work".
So yeah, I don't think disliking it because that's the average quality of JS dev I see is an unreasonable position. I'm sure there's some great ones out there doing impressive things, but I'm sure you could point them towards nearly any language and they'd produce something equally cool.
I'd say they'd produce something massively cooler ;-)
The language has some very ugly warts (although ES6+ fixes many things), I find that the quality/maturity/stability of third party libraries lags behind other languages, and the whole build/dev environment best practices is constantly in flux and breaking things all the time. Also Electron, for all it's advantages, is renowned for being a massive resource hog making what is otherwise a fairly fast and efficient language appear horribly slow at times.
That being said, developing in JS today is a lot better than 3-4 years ago, and I suspect that that pattern will continue.
For developers though, this is chargeable so I'm on the fence :)
a little overstatement, but okay. js is very suitable for this in my opinion. i don't what counts as "serious" application development in your world, but i've seen quite many good, performant applications around written in js. and servers too!