Im one of the people that cant understand the javascript hype. It's an inheritly weak language with major problems. I come from C++ and javascript is a massive downstep from that. No compiler helping you catch your errors (no, unit test are not an alternative, a type system can prevent whole categories of errors plus semantic completion). Currently I enjoy writing my backend code in Haskell. For the frontend I use typescript which fixes a lot of javascripts flaws but still suffers from leaky abstractions
Same goes for nodejs. Why would you trust you business logic to a slow and unsafe environment? An yes even with V8 JS is slow. You dont want to write your backend in C because of null pointers, then why do you use a glorified text file to run it?
When people start learning to program, they develop a strong favorable bias toward whatever language they've learned. I think javascript just-so-happens to be the first (only?) language a lot of people learn, so naturally they favor it.
I have a feeling if you sampled a large group of polyglot programmers, javascript would not fare nearly as well.
I would say this is true for me. JavaScript was effectively my second language and I thought first class functions were the coolest thing ever, along with object literal notation. It got me into functional programming which I'll be internally indebted. However the number of issues caused by it are unparalleled (except maybe by our Ruby on Rails project).
Naturally as I learned more and more languages I started to realize that while I liked the way I wrote JavaScript I hated everyone else's for the most part. I also hated my own after about 3 months generally.
Elm is like heaven sent for me. You compile it and it works. That just doesn't happen in js land. More like push it to production and have everyone find the errors. Plus the helpful compiler messages, autocompletion, Auto formatting, and enforced SemVer make it just so plesent to work in.
Oh man you should try Elm if you have a Haskell backed. Typescript might be nice for the stuff that's not supported in Elm yet though. The type system makes a world of difference, it's crazy.
Elm is not a good language. You are at the mercy of it's creators because they decide how your code should work. Elm is simply not a general purpose language.
I want to try Purescript one day though. I looks like Haskell for the Browser
Elm only runs in the browser and is only really made for front end development. However just replacing most of your JavaScript is still very useful to me. I feel that it's restrictions are mostly caused by it's purity. It can't actually do any side effects so it has to have many pure logic functions that the runtime calls. All language creators decide how your code should work.
At it's current state it can't save you 100% from JavaScript but it can do about 95% (for the typical web app). If I can say that 95% of my code is beautiful and runtime error free I feel like that's a pretty awesome deal.
PureScript could be a good option if you already know Haskell. You do miss out on the enforced SemVer and perhaps more developed libraries but those are probably just a matter of time. It might be a better fit for you.
The reason is flexibility. It has a wide range of utility, from prototyping quick and dirty tiny programs to writing sensibly performant, fairly strictly typechecked production code. Nobody seems to mention the real flaws though: lack of threading (debateable) and large ints.
It's an inheritly weak language with major problems. I come from C++ and javascript is a massive downstep from that.
The language is complex, riddled with undefined behaviour and it takes years of expertise to be able to comfortably work with any non-trivial code base. And it didn't even have lambdas until recently. JavaScript? You can write a function that returns a class. Hows that for flexibility? You can also write a function that automatically adds promise-based methods from a class/module containing callback based methods: bluebirdjs.com/docs/api/promise.pr... and have THAT be optimised by the JIT and run fast. How's that for power?
No compiler helping you catch your errors
Try two compilers: Flowtype and TypeScript. With advanced features such as union/intersection types, flow analysis, non-nullable types, mapped types, etc - both supporting a huge subset of the mind-bending flexibility.
An yes even with V8 JS is slow
Not even close to slow. Certainly blows almost every other dynamic language away (except maybe sbcl and clojure+jvm). With C and C++, null pointers are the least of your worries.
Seriously, I would take a backend written in node than one in C++ any day.
(I'm still waiting for a language to match TypeScript's flexibility when it comes to native record types. Maybe PureScript one day. Or if Haskellers get their act together and add proper row-polymorphic records, Or OCaml/ReasonML objects)
I was talking about Javascript, not Typescript. Those are different languages. I write all my fronzend code in Typescript too, because it has a very nice type system. But it has other flaws. E.g. always infering tuples as sum typed array.
I also would not write a Backend in C++ but I would like it more than a Javascript backend.
And yes JS is the fastest of the scripting languages, but if you achieve 10x speedup with something that was 100x slower, it is still slow.
Also is Javascript horrible on a multi core CPU as it cant use it fully.
10x is the worst case - you would typically get around 2x-3x worse performance compared with most compiled languages. See for example benchmarksgame.alioth.debian.org/u... - and thats with 4 cores vs 1 core for most of the programs. When limited to single core the difference is even smaller.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Im one of the people that cant understand the javascript hype. It's an inheritly weak language with major problems. I come from C++ and javascript is a massive downstep from that. No compiler helping you catch your errors (no, unit test are not an alternative, a type system can prevent whole categories of errors plus semantic completion). Currently I enjoy writing my backend code in Haskell. For the frontend I use typescript which fixes a lot of javascripts flaws but still suffers from leaky abstractions
Same goes for nodejs. Why would you trust you business logic to a slow and unsafe environment? An yes even with V8 JS is slow. You dont want to write your backend in C because of null pointers, then why do you use a glorified text file to run it?
I have a theory:
When people start learning to program, they develop a strong favorable bias toward whatever language they've learned. I think javascript just-so-happens to be the first (only?) language a lot of people learn, so naturally they favor it.
I have a feeling if you sampled a large group of polyglot programmers, javascript would not fare nearly as well.
I would say this is true for me. JavaScript was effectively my second language and I thought first class functions were the coolest thing ever, along with object literal notation. It got me into functional programming which I'll be internally indebted. However the number of issues caused by it are unparalleled (except maybe by our Ruby on Rails project).
Naturally as I learned more and more languages I started to realize that while I liked the way I wrote JavaScript I hated everyone else's for the most part. I also hated my own after about 3 months generally.
Elm is like heaven sent for me. You compile it and it works. That just doesn't happen in js land. More like push it to production and have everyone find the errors. Plus the helpful compiler messages, autocompletion, Auto formatting, and enforced SemVer make it just so plesent to work in.
Oh man you should try Elm if you have a Haskell backed. Typescript might be nice for the stuff that's not supported in Elm yet though. The type system makes a world of difference, it's crazy.
Elm is not a good language. You are at the mercy of it's creators because they decide how your code should work. Elm is simply not a general purpose language.
I want to try Purescript one day though. I looks like Haskell for the Browser
Elm only runs in the browser and is only really made for front end development. However just replacing most of your JavaScript is still very useful to me. I feel that it's restrictions are mostly caused by it's purity. It can't actually do any side effects so it has to have many pure logic functions that the runtime calls. All language creators decide how your code should work.
At it's current state it can't save you 100% from JavaScript but it can do about 95% (for the typical web app). If I can say that 95% of my code is beautiful and runtime error free I feel like that's a pretty awesome deal.
PureScript could be a good option if you already know Haskell. You do miss out on the enforced SemVer and perhaps more developed libraries but those are probably just a matter of time. It might be a better fit for you.
What I mean is that Elm is too limiting. You are forced to TEA, which is a lot of boilerplate and you cannot try your own ideas
The reason is flexibility. It has a wide range of utility, from prototyping quick and dirty tiny programs to writing sensibly performant, fairly strictly typechecked production code. Nobody seems to mention the real flaws though: lack of threading (debateable) and large ints.
The language is complex, riddled with undefined behaviour and it takes years of expertise to be able to comfortably work with any non-trivial code base. And it didn't even have lambdas until recently. JavaScript? You can write a function that returns a class. Hows that for flexibility? You can also write a function that automatically adds promise-based methods from a class/module containing callback based methods: bluebirdjs.com/docs/api/promise.pr... and have THAT be optimised by the JIT and run fast. How's that for power?
Try two compilers: Flowtype and TypeScript. With advanced features such as union/intersection types, flow analysis, non-nullable types, mapped types, etc - both supporting a huge subset of the mind-bending flexibility.
Not even close to slow. Certainly blows almost every other dynamic language away (except maybe sbcl and clojure+jvm). With C and C++, null pointers are the least of your worries.
Seriously, I would take a backend written in node than one in C++ any day.
(I'm still waiting for a language to match TypeScript's flexibility when it comes to native record types. Maybe PureScript one day. Or if Haskellers get their act together and add proper row-polymorphic records, Or OCaml/ReasonML objects)
I was talking about Javascript, not Typescript. Those are different languages. I write all my fronzend code in Typescript too, because it has a very nice type system. But it has other flaws. E.g. always infering tuples as sum typed array.
I also would not write a Backend in C++ but I would like it more than a Javascript backend.
And yes JS is the fastest of the scripting languages, but if you achieve 10x speedup with something that was 100x slower, it is still slow.
Also is Javascript horrible on a multi core CPU as it cant use it fully.
10x is the worst case - you would typically get around 2x-3x worse performance compared with most compiled languages. See for example benchmarksgame.alioth.debian.org/u... - and thats with 4 cores vs 1 core for most of the programs. When limited to single core the difference is even smaller.