Pretty sure we're up to billions of real world value created by software written in Javascript. If you're still dismissive at this point, it's time to catch up. You've missed the boat.
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.
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.
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.
None of what you mentioned are missing features, they are personal preferences stemming for your own language preference that differs dramatically from Javascript. I'd start by disassociating your opinionated stances from actual weaknesses in the language, of which there are many, and none of them are what you mentioned.
Nope. No it does not.
JavaScript is particularly egregious because of it's weird behaviour about types and coercion and you know, just silently failing, behaviour that I wouldn't want going on in any proper system that handles anything important. Other people have written at great length about JS's many failings.
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.
I'm very glad that you've been omniscient enough to determine what "proper" parallel support is, though. How's that working out for you? Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.
> x={}
> x.fred
undefined
Do they now?
$ irb
irb(main):001:0> "0" + 1
TypeError: no implicit conversion of Fixnum into String
from (irb):1:in `+'
from (irb):1
from /usr/bin/irb:11:in `<main>'
irb(main):002:0> ^D
$ python
>>> "0" + 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
>>> ^D
$ node
> "0" + 1
'01'
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.
Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process.
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[0]) 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.
[0] 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.
The reason so much has been spent on Javascript: it runs in the web browser. For sure, people have found other reasons to like Javascript but at the bottom of the pile, money was spent because it was in the browser and the browser vendors wanted the browser to do more.
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.
3. A sense of stability. Javascript's framework churn is just exhausting.
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.
> A sense of stability. Javascript's framework churn is just exhausting.
Feature, not a bug.
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).
Not to mention that when it comes to Javascript, you can opt-in to about as much static code analysis, including type-safety, as you want.
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.
After using something like Elixir, you'll even wish if Javascript could be permanently banned from the Software industry for ever.
I use Elixir + Ruby + Coffeescript and I still wish JS was never invented.
https://twitter.com/bendhalpern/status/578925947245633536?la...
I used to think the same thing back when I used Clojure + ClojureScript. Hah, what idiot would choose Javascript over my god tier Clojure/Script setup?
Well, one day I actually tried to build a company and my cofounder just couldn't be fucked to learn Clojure. We decided on Node. I was forced to learn how to play nice with Javascript where I learned how to appreciate it.
Nowadays, I have a hard time justifying something like Clojure/Script over Javascript. Same with Elixir. And I am very wary of people who can't spot trade-offs since that was how I used to be, and I was wrong. I just didn't have enough experience.
There is no best. There are only trade-offs. Elixir/Clojure might be a good business decision for your project, but if you can't concede any positives to Javascript, I don't think you have a firm grip. And in the end it's always a business decision, not a technical one.
"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.
The old Javascript were very bad, recent Javascripts were bad, today's Javascript are OK, future Javascript / TypeScript is actually pretty decent.
Of course I do hope something else has taken its place.
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?).
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
https://blog.bitsrc.io/11-javascript-utility-libraries-you-s...
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.