News for hackers. Stuff that matters.

A comment on Swift should not be the future of iOS, and why TypeScript should.. Parent comment

Re:Swift should not be the future of iOS, and why TypeScript... by sbjs on Tuesday August 14, 2018 @04:33PM (#17761644)
Swift is #6 on that list, TypeScript is #4. Swift is a completely new language which has a big overhead to learn from start to finish, but JavaScript has a lot of momentum and existing developers since it is already the lingua franca of the front end of the web. Swift is evolving slowly, but JavaScript is making very quick progress through TC39 during the same time span that Swift was alive. Swift has ambiguous and biased leadership but JavaScript has a well defined and established committee with members from major competitors who have common interest in the language succeeding. TypeScript inherits a lot of these benefits, as it intends to always keep up with the latest JavaScript standards and specification.
[ Parent | on HN ]
Re:Swift should not be the future of iOS, and why TypeScript... by colonelrascals on Tuesday August 14, 2018 @05:00PM (#17761849)
Swift is #6 on that list, TypeScript is #4.

This was meant to highlight that Swift developers don't seem unhappy with the language

Swift is evolving slowly, but JavaScript is making very quick progress through TC39 during the same time span that Swift was alive.

I'm not sure this is a bad thing

Swift has ambiguous and biased leadership but JavaScript has a well defined and established committee with members from major competitors who have common interest in the language succeeding.

I think this is a bit biased. Have you read Swift's Community Guidelines? https://swift.org/community/#communication

I don't really have a dog in this fight and would love some input from a Swift developer.

I still claim that introducing JavaScript is not the solution.

[ Parent | on HN ]
Re:Swift should not be the future of iOS, and why TypeScript... by sbjs on Tuesday August 14, 2018 @05:56PM (#17762275)
I did pick JavaScript as an opinionated suggestion. But really what I meant was that a garbage collected, simple OOP, high-level language is much better than a performance-based efficiency focused language when most of what you use it for has no need for efficiency or high performance.
[ Parent | on HN ]