7 ms·

How much more real world evidence does HN need to see before the "JS isn't a real language" meme is abandoned? Pretty sure we're up to billions of real world v

How much more real world evidence does HN need to see before the "JS isn't a real language" meme is abandoned? 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.

arghwhat 8y ago
It's a "real" language, it's just not a terribly good or fast one. It's works decently when its use is limited to what it was made for: manipulating web pages. For anything else, the "designed on the back of a used piece of toilet paper" starts to shine through. 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".
- nawgszy 8y ago
  >it's just not a terribly good or fast one 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'?
  - arghwhat 8y ago
    > (4x slower, perhaps) "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.
    - bitL 8y ago
      > objects are hashmaps But you still have to compute hashcode yourself :D
    - xamuel 8y ago
      >Most language features, really. Name a few. >terrible "prototype" system >malice that is "this" It sounds like you are talking about ES5, not ES6+
      - bitL 8y ago
        Can you guarantee all ES6- code to disappear immediately? Or are you forced to dive deep into warts when you have to work on some older JS project?
        jhall1468 8y ago
        Wow, now we're complaining about the outdated versions of a language? Come on man. Nobody is going to write a modern application in ES5 and there are plenty of warts in old Java, C and Python applications as well. That's the nature of them being "old".
        shawnz 8y ago
        Why does that impact whether or not it's a reasonable choice to use the language today? Old libraries I could understand, but old independent projects? How do they affect the current state of the language?
        bitL 8y ago
        Isn't it obvious? You apply for a job, company that isn't a startup has code that is likely written with old JavaScript whose replacement is not economical, so even if you do everything new in ES7, you still have to wade through old ugly code, likely everyday.
      - StavrosK 8y ago
        > Name a few. He did, literally exactly after that sentence.
  - FridgeSeal 8y ago
    If I threw billions of dollars of vested interest at Python/Ruby/COBOL/(insert language of your choice) we can probably make those run at JS speeds as well. Does that solve the fundamental drawbacks of the languages? 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.
    - workinthehead 8y ago
      every dynamically-typed language has "weird" behaviour around type coercion, that's simply the nature of the beast. 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.
      - tom_ 8y ago
        Probably this thing, easy to spot in isolation but much harder when part of a larger system: > x={} > x.fred undefined Actively unhelpful!
      - pdpi 8y ago
        > every dynamically-typed language has "weird" behaviour around type coercion 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' > Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions. 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.
  - thomascgalvin 8y ago
    > What is it missing that makes you hate it so? 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.
    - snorremd 8y ago
      2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.
    - jhall1468 8y ago
      > until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. 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.
    - jmull 8y ago
      > ...until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. 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.
  - cm2187 8y ago
    What creates hostility is the sentiment of being forced to use a bad language. There are many alternatives to python or php but none really to javascript (transpilers hacks apart). Webassembly might change that. 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.
    - paulie_a 8y ago
      Also VB 6 syntax was complete shit.
      - cm2187 8y ago
        Pretty much any old language has an odd and inconsistent syntax. I am getting into python now and it feels so much like doing VBA.
        bitL 8y ago
        Oh yeah, just wait until during a job interview somebody complains that you aren't "pythonic" enough, i.e. don't use some weird inconsistent syntactic wart somebody learned to love.
  - throwaway13456 8y ago
    Have you ever used a language like Elixir? After using Elixir, my first thought was "why the f would anyone even use JS in 2018?" That's how poor the design choices of JavaScript are. Not to mention that the name itself is trademarked by the biggest troll (Oracle corporation). 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?lang=en https://twitter.com/bendhalpern/status/578925947245633536?la...
    - bitL 8y ago
      That tweet was golden!
    - always_good 8y ago
      Honestly your post just reeks of amateurism. 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.
- mcphage 8y ago
  Not only is JavaScript a “real” language, it’s also a real language.
- em500 8y ago
  > It's a "real" language, it's just not a terribly good or fast one "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup
  - gizmo 8y ago
    "There are only two kinds of file systems. Those that corrupt your data eventually and those nobody uses." 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.
    - osrec 8y ago
      I don't think he's saying the criticisms are invalid, but just that they are at the forefront of more people's minds because the respective language is more prevalent. Languages that are barely used also have their problems - they are just undiscovered or spoken about less.
      - gizmo 8y ago
        If he wanted to make the really mundane point that people don't complain about things they don't use there would be absolutely no reason to bring C++ into it. He could just remark that nobody complains about the bad handling of the Model T anymore because nobody drives it. It's true but why is that relevant or at all interesting? Do we really believe this is the mundane observation Stroustrup is making? 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.
        8y ago
- tinus_hn 8y ago
  What part of ‘acceptable’ is unacceptable to you then?
- ksec 8y ago
  I wonder if they are using TypeScript. 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.
  - randomname2 8y ago
    The linked Twitter thread states that they do use TypeScript: https://twitter.com/TheLarkInn/status/1006861097729585154 https://twitter.com/TheLarkInn/status/1006861097729585154
- Brass 8y ago
  Why the shot at COBOL here? COBOL's creation of "real world value" by comparison is hardly a low bar: https://thenewstack.io/cobol-everywhere-will-maintain/ https://thenewstack.io/cobol-everywhere-will-maintain/
  - pdpi 8y ago
    COBOL was the state of the art when it was designed, but any evolution on top of that is, by necessity, limited by a 60-year-old core design. While it _has_ produced a lot of real world value in the almost 6 decades of its existence, starting a new project in COBOL would be ill-advised. 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.
- codingdave 8y ago
  "real world value" is a completely fair metric. You might be able to argue that different languages offer more value than JS, for different use cases. But mocking the idea of "real world value" seems to completely miss the underlying point of app development -- which is to deliver value.
  - TeMPOraL 8y ago
    Again, "delivering value" is a ridiculously low bar, when you measure "value delivered" by revenue. We ought to do better than that. 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?).
cm2187 8y ago
Let's not confuse popularity (as in lots of users) and popularity (as in lots of love). Death and taxes are popular too! People write javascript because they have no other choice to run in the browser. I don't see that as a testimony that it is a great language.
- actsasbuffoon 8y ago
  If your only concern is the ergonomics of the language then there are lots of compile-to-JS languages. Some of them also compile to WebAssembly, which allows them to bypass the GC. It’s still not native speed, but it’s close enough for many applications. 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.
bitL 8y ago
JS empowers beginners and disempowers advanced developers. If you are learning programming, JS helps you, if you need sensible pro-level features, you are out of luck.
throwaway13456 8y ago
Funnily enough, there's another post on HN's front page that (self) explains why JS is a flawed language: https://blog.bitsrc.io/11-javascript-utility-libraries-you-should-know-in-2018-3646fb31ade 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.
osrec 8y ago
It's about prevalence. The more prevalent a language is, the more the complainers come out in force. PHP is another language that has created billions of dollars of value, yet it doesn't stop the computer science purists from bashing it every other day. Just ignore the negativity and keep writing code in what makes sense to you.
redleggedfrog 8y ago
"Pretty sure we're up to billions of technical debt created by software written in Javascript." 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.
- dkns 8y ago
  As opposed to The One Language that is perfect and doesn't incur technical debt when programs are written in it. "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup
pjc50 8y ago
It's very much in the same state that VB was, or even "Excel programming" is today: it certainly works and it certainly produces a lot of business value. It's just that the downsides appear further down the road; maintainbility and scalability issues, or intrinsic conversion causing data loss. That kind of thing. 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.
- jhall1468 8y ago
  These aren't Electron apps. They are applications written in Javascript and compiled to native via ReactXP and react-native-windows. 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.
- scq 8y ago
  I don't think JavaScript itself is the problem here. Electron is slow to load and uses a lot of memory because it's loading an entire multiprocess Chromium runtime with all of the Web platform implemented, optimized for speed and security rather than memory usage. 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.
emodendroket 8y ago
Nobody is claiming you can't write real software in JS. What they're saying is that it is a waste to do so when so much better tools are available. When you're in the browser there are such huge benefits that it makes sense. Elsewhere I find it hard to understand JS mania.
cirgue 8y ago
I will abandon my skepticism of JavaScript as soon as JavaScript boosters abandon their infomercialesque “millions of people can’t be wrong!” attitude and make a compelling case for the language itself. JavaScript is all we have for web dev which is why it’s so popular. That doesn’t mean it isn’t a fundamentally flawed language, it just means that no one has been able to popularize better solutions because of network effects.
- titanix2 8y ago
  JavaScript is so good Microsoft created Typescript to avoid dealing with it directly. (edit: wrong parent)
- kozhevnikov 8y ago
  What is the fundamental flaw in JavaScript language?
- htor 8y ago
  the millions are not saying it's perfect. that would be wrong. as you say what we have is js, so let's move on and make something useful with it instead of complaining about it being flawed. it is evolving, being standardized and getting new features. its not going to go away anytime soon, so instead educate yourself into avoid the pitfalls that exist in the language and have fun being productive.

arghwhat 8y ago

It's a "real" language, it's just not a terribly good or fast one. It's works decently when its use is limited to what it was made for: manipulating web pages. For anything else, the "designed on the back of a used piece of toilet paper" starts to shine through. 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".

nawgszy 8y ago
>it's just not a terribly good or fast one 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'?
- arghwhat 8y ago
  > (4x slower, perhaps) "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.
  - bitL 8y ago
    > objects are hashmaps But you still have to compute hashcode yourself :D
  - xamuel 8y ago
    >Most language features, really. Name a few. >terrible "prototype" system >malice that is "this" It sounds like you are talking about ES5, not ES6+
    - bitL 8y ago
      Can you guarantee all ES6- code to disappear immediately? Or are you forced to dive deep into warts when you have to work on some older JS project?
      - jhall1468 8y ago
        Wow, now we're complaining about the outdated versions of a language? Come on man. Nobody is going to write a modern application in ES5 and there are plenty of warts in old Java, C and Python applications as well. That's the nature of them being "old".
      - shawnz 8y ago
        Why does that impact whether or not it's a reasonable choice to use the language today? Old libraries I could understand, but old independent projects? How do they affect the current state of the language?
        bitL 8y ago
        Isn't it obvious? You apply for a job, company that isn't a startup has code that is likely written with old JavaScript whose replacement is not economical, so even if you do everything new in ES7, you still have to wade through old ugly code, likely everyday.
    - StavrosK 8y ago
      > Name a few. He did, literally exactly after that sentence.
- FridgeSeal 8y ago
  If I threw billions of dollars of vested interest at Python/Ruby/COBOL/(insert language of your choice) we can probably make those run at JS speeds as well. Does that solve the fundamental drawbacks of the languages? 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.
  - workinthehead 8y ago
    every dynamically-typed language has "weird" behaviour around type coercion, that's simply the nature of the beast. 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.
    - tom_ 8y ago
      Probably this thing, easy to spot in isolation but much harder when part of a larger system: > x={} > x.fred undefined Actively unhelpful!
    - pdpi 8y ago
      > every dynamically-typed language has "weird" behaviour around type coercion 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' > Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions. 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.
- thomascgalvin 8y ago
  > What is it missing that makes you hate it so? 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.
  - snorremd 8y ago
    2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.
  - jhall1468 8y ago
    > until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. 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.
  - jmull 8y ago
    > ...until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. 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.
- cm2187 8y ago
  What creates hostility is the sentiment of being forced to use a bad language. There are many alternatives to python or php but none really to javascript (transpilers hacks apart). Webassembly might change that. 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.
  - paulie_a 8y ago
    Also VB 6 syntax was complete shit.
    - cm2187 8y ago
      Pretty much any old language has an odd and inconsistent syntax. I am getting into python now and it feels so much like doing VBA.
      - bitL 8y ago
        Oh yeah, just wait until during a job interview somebody complains that you aren't "pythonic" enough, i.e. don't use some weird inconsistent syntactic wart somebody learned to love.
- throwaway13456 8y ago
  Have you ever used a language like Elixir? After using Elixir, my first thought was "why the f would anyone even use JS in 2018?" That's how poor the design choices of JavaScript are. Not to mention that the name itself is trademarked by the biggest troll (Oracle corporation). 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?lang=en https://twitter.com/bendhalpern/status/578925947245633536?la...
  - bitL 8y ago
    That tweet was golden!
  - always_good 8y ago
    Honestly your post just reeks of amateurism. 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.
mcphage 8y ago
Not only is JavaScript a “real” language, it’s also a real language.
em500 8y ago
> It's a "real" language, it's just not a terribly good or fast one "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup
- gizmo 8y ago
  "There are only two kinds of file systems. Those that corrupt your data eventually and those nobody uses." 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.
  - osrec 8y ago
    I don't think he's saying the criticisms are invalid, but just that they are at the forefront of more people's minds because the respective language is more prevalent. Languages that are barely used also have their problems - they are just undiscovered or spoken about less.
    - gizmo 8y ago
      If he wanted to make the really mundane point that people don't complain about things they don't use there would be absolutely no reason to bring C++ into it. He could just remark that nobody complains about the bad handling of the Model T anymore because nobody drives it. It's true but why is that relevant or at all interesting? Do we really believe this is the mundane observation Stroustrup is making? 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.
      - 8y ago
tinus_hn 8y ago
What part of ‘acceptable’ is unacceptable to you then?
ksec 8y ago
I wonder if they are using TypeScript. 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.
- randomname2 8y ago
  The linked Twitter thread states that they do use TypeScript: https://twitter.com/TheLarkInn/status/1006861097729585154 https://twitter.com/TheLarkInn/status/1006861097729585154
Brass 8y ago
Why the shot at COBOL here? COBOL's creation of "real world value" by comparison is hardly a low bar: https://thenewstack.io/cobol-everywhere-will-maintain/ https://thenewstack.io/cobol-everywhere-will-maintain/
- pdpi 8y ago
  COBOL was the state of the art when it was designed, but any evolution on top of that is, by necessity, limited by a 60-year-old core design. While it _has_ produced a lot of real world value in the almost 6 decades of its existence, starting a new project in COBOL would be ill-advised. 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.
codingdave 8y ago
"real world value" is a completely fair metric. You might be able to argue that different languages offer more value than JS, for different use cases. But mocking the idea of "real world value" seems to completely miss the underlying point of app development -- which is to deliver value.
- TeMPOraL 8y ago
  Again, "delivering value" is a ridiculously low bar, when you measure "value delivered" by revenue. We ought to do better than that. 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?).

cm2187 8y ago

Let's not confuse popularity (as in lots of users) and popularity (as in lots of love). Death and taxes are popular too! People write javascript because they have no other choice to run in the browser. I don't see that as a testimony that it is a great language.

actsasbuffoon 8y ago
If your only concern is the ergonomics of the language then there are lots of compile-to-JS languages. Some of them also compile to WebAssembly, which allows them to bypass the GC. It’s still not native speed, but it’s close enough for many applications. 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.

bitL 8y ago

JS empowers beginners and disempowers advanced developers. If you are learning programming, JS helps you, if you need sensible pro-level features, you are out of luck.

throwaway13456 8y ago

Funnily enough, there's another post on HN's front page that (self) explains why JS is a flawed language: https://blog.bitsrc.io/11-javascript-utility-libraries-you-should-know-in-2018-3646fb31ade 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.

osrec 8y ago

It's about prevalence. The more prevalent a language is, the more the complainers come out in force. PHP is another language that has created billions of dollars of value, yet it doesn't stop the computer science purists from bashing it every other day. Just ignore the negativity and keep writing code in what makes sense to you.

redleggedfrog 8y ago

"Pretty sure we're up to billions of technical debt created by software written in Javascript." 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.

dkns 8y ago
As opposed to The One Language that is perfect and doesn't incur technical debt when programs are written in it. "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup

pjc50 8y ago

It's very much in the same state that VB was, or even "Excel programming" is today: it certainly works and it certainly produces a lot of business value. It's just that the downsides appear further down the road; maintainbility and scalability issues, or intrinsic conversion causing data loss. That kind of thing. 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.

jhall1468 8y ago
These aren't Electron apps. They are applications written in Javascript and compiled to native via ReactXP and react-native-windows. 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.
scq 8y ago
I don't think JavaScript itself is the problem here. Electron is slow to load and uses a lot of memory because it's loading an entire multiprocess Chromium runtime with all of the Web platform implemented, optimized for speed and security rather than memory usage. 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.

emodendroket 8y ago

Nobody is claiming you can't write real software in JS. What they're saying is that it is a waste to do so when so much better tools are available. When you're in the browser there are such huge benefits that it makes sense. Elsewhere I find it hard to understand JS mania.

cirgue 8y ago

I will abandon my skepticism of JavaScript as soon as JavaScript boosters abandon their infomercialesque “millions of people can’t be wrong!” attitude and make a compelling case for the language itself. JavaScript is all we have for web dev which is why it’s so popular. That doesn’t mean it isn’t a fundamentally flawed language, it just means that no one has been able to popularize better solutions because of network effects.

titanix2 8y ago
JavaScript is so good Microsoft created Typescript to avoid dealing with it directly. (edit: wrong parent)
kozhevnikov 8y ago
What is the fundamental flaw in JavaScript language?
htor 8y ago
the millions are not saying it's perfect. that would be wrong. as you say what we have is js, so let's move on and make something useful with it instead of complaining about it being flawed. it is evolving, being standardized and getting new features. its not going to go away anytime soon, so instead educate yourself into avoid the pitfalls that exist in the language and have fun being productive.