Javascript in 2019 only has 0.5% more market share than in 2004?
2019 has basically every new UI (and many rewrites of old ones) being built in Javascript, 2004 it was being used for the occasional drop down menu.
(Even if you include Typescript, the only compile-to-JS language in the top 50, it still only gets to 2.7% today compared to 2% in 2004).
See also C unassailably at number 2. I think we can all agree that in 2019, there is more active development in Javascript, than C - Likely it's benefiting from their methodology giving it credit for C++ and C#, so at least we can theorise about that one, but I really have no idea for Javascript.
Part of the problem is that their methodology is based heavily on performing web searches for the phrase "$LANGUAGE programming".
Lots of developers use Javascript in the course of their work. Few of them will refer to their work as "Javascript programming" -- they will typically use either a broader term, like "web development", or a more specific one, like "React development". Neither of these would influence TIOBE's rankings.
If I want to find the MDN page for destructuring assignment in JavaScript I know I don’t need to add JavaScript or MDN, I can just search for “Array Destructuring”, and the top half dozen results are all JavaScript.
> 2019 has basically every new UI (and many rewrites of old ones) being built in Javascript
yeah... no
> See also C unassailably at number 2. I think we can all agree that in 2019, there is more active development in Javascript, than C
bubbles, bubbles, bubbles. the immense majority of large companies I see start new GUI projects in Java, C#, C++, ... daily. Count the hundred of thousands of programmers working for gigacompanies like Samsung (with more than 40k devs), ATOS (122K employees, mostly devs), CapGemini (211k employees, mostly devs), etc... they are far from all doing JS.
The Tiobe index is based entirely on search engine result counts. Those numbers aren't even particularly meaningful as a count of web pages; treating them as an authoritative source of programming language popularity, as TIOBE does, is ridiculous.
There are a couple of really strange comparisons you can spot in the results. For example, Scratch -- a visual programming language made for children which is only usable on its own web site -- is ranked higher than TypeScript, Lua, Scala, Kotlin, or Rust. Similarly, D -- a proposed replacement for C++ which has never found any real traction -- is ranked even higher.
Not to defend the TIOBE index (claims to be a measure of popularity of programming languages) but if you go by the dictionary definition of popularity ("the state of being liked, enjoyed, accepted, or done by a large number of people") I don't doubt that Scratch is more popular than Lua, Scala, Kotlin or Rust. If I think about my friends and acquaintances, most of them certainly have never heard of any of those languages, but I'm sure almost all of their kids were exposed to Scratch at some point.
This is the impression I get as well. VB.NET > JavaScript?
Here's what they say about their methodology:
> The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
And some of that "methodology" is seriously suspect.
> Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings.
Bing and Yahoo! are both front ends to the same search engine. Wikipedia, Amazon, and YouTube aren't general-purpose search engines at all, and it's unclear how accurate the results of a Baidu search would be for English-language search terms like "Javascript programming".
It's the Dow Jones Index of indicators. Totally pointless.
The best measure of a language's popularity needs to take job vacancies and github metrics as their most meaningful measures. Stackoverflow posts and google searches will help too but contain a lot of natural bias.
Agreed, but having said that there are a lot of people developing for iOS who never made the switch due to past language instability and continued poor quality tooling.
Outside of iOS I don’t think it’s made a dent and I would be surprised if things like Swift for Tensorflow make a difference there (if only because the number of ML devs is very small and the appeal of Swift for ML is also pretty small).
I'm an extreme outlier, but I'm about to start an Objective-C codebase (a 2D renderer on top of Metal), because I suspect interop with Rust will be a lot easier. In particular, it looks like you can just build .m files from a build.rs, and I'm pretty sure that's not true with Swift. It's also possible to invoke Obj-C from Rust using the dynamic features, but I think that's both code bloat and a runtime cost. [I'm interested in exploring these issues further, but it's probably outside the scope of this HN thread, get in touch if you want to discuss.]
If you want to call rust from Swift, it should be easy. I work with C libraries and it easy to interface with module maps. However, with objective C the interoperability is trivial. As long as you pay attention to retain cycles, you can hold reference and call objc methods directly. That said, please make sure your framework can be imported into Swift properly. As most of the users will be using Swift.
Yes, I've seen examples of calling Rust from Swift, and I do plan to support that. This particular thing is about calling macOS platform functions from Rust code. Projects either call Objective-C API's from native Rust code using the dynamic invocation mechanism (which I think is slow and code-bloaty but want to measure more carefully), or they use the "cc" crate to include Objective-C code (and then generally use C ABI calls from Rust code into that). I've never seen Rust code that compiles Swift from a "cargo build" but of course would love to be proven wrong.
Maybe I can, I just haven't found an example of it. Certainly the "cc" crate doesn't seem to know how to compile Swift files. This might be more of a documentation issue than a real technical limitation though.
I don't care about the random TIOBE fluctuations. But I really don't get the love for Swift.
- Optional is a nuisance and I don't think it is highly effective at preventing the dereference of a nil pointer in practice. People are going to fiddle with ? and ! until their code works, and the protection that Optional provides then disappears.
- "let" is a mess. In one context it means unwrapping an Optional. In another, it doesn't. If you use it in an expression, it interferes with the usual refactorings that people apply to expressions.
- There is so much fussy detail around preserving the syntax of object.field = expression. didSet, willSet, getters, setters, oldValue, newValue. WHY IS THIS SYNTAX SO FRIGGIN' IMPORTANT? One of the justified criticisms of C++ (IMHO) is that operator overloading means that all sorts of functions can be running under innocent-looking code. I would much rather have = mean assignment, and use function call notation when I really want functions to run.
- Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've seen examples of code that require careful and non-obvious use of weak to avoid memory leaks, (sorry, I don't have the reference handy).
It sure beats Objective-C, and it does have some nice modern features, but I think they made some unfortunate design choices.
- Optional has made null pointer exceptions virtually non-existent. There are occasions where deserialization does result in a nil value where one is not expected, but that's rare. I think this is as massive as garbage collection was back in the day.
- The language is in a sweet spot between something convoluted and heavy like Java and something overly simplistic like PHP/Ruby/Python. It's perfect for software development and large code-bases with a low learning curve.
- There is no magic (methods, properties, etc). Everything is explicit but not wordy. This may change in the future but I hope it never does.
- It's more legible than Kotlin with fewer unnecessary language features. Speaking of which...
- It's a simple language and its syntax is straight forward
It's not a perfect language:
- The package manager needs a lot of work
- Extensions can lead to confusion (eg. in the case of conformance to protocols (interfaces)).
- I would like an optional garbage collection system for long-running processes (e.g. server-side applications)
- I would like it to perform even better
You can nitpick syntax anomalies with any language, but a language is defined by how easy it is to scale to multiple programmers, how applicable it is to a problem, how well it performs, how easy it is to read for someone new to the system, how it helps the programmer not commit mistakes, etc. Of all the languages I've written, none has been as successful in all regards as Swift.
> - Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've seen examples of code that require careful and non-obvious use of weak to avoid memory leaks, (sorry, I don't have the reference handy).
This is such a bizarre statement to me. I have to wonder if the commenter has ever dealt with production systems or code that uses GC? Because with years of writing and tuning Java servers, I've long since come to the conclusion that GC is largely a false economy.
You still have to deal with memory leaks but the cause this time is objects maintaining references they don't need. Sure GCs become cleverer at detecting unused forests of objects and so on but this largely makes another problem worse: so-called stop-the-world pauses for a full GC. It's still an issue you have to deal with on Java, Go and probably every GC language.
This isn't to say that ref-counting is a panacea (what is?). Particularly on servers the critical region for updating the ref-count itself can become hot and a bottleneck.
But this isn't really a problem on mobile app code. I've long said that iOS's uses of ref-counting (ARC since 5.0+) is a strategic and competitive advantage to Android's Dalvik/Java GC.
Google's Plan9 2.0 (ie Fuchsia) makes me sad (for many reasons). Just one is that they've embraced Dart/Flutter at the application level (which isn't required as anyone who works on it will tell you, yada yada yada) but Dart is such a strange choice because it still relies on GC. What's the point?
Oh and just to be pedantic, you list ref-counting as a negative of Swift compared to Objective-C. ARC is orthogonal to that. Like I said, ARC came about in iOS 5.0.
IDK about Java, but the GC characteristics of Go seem pretty ideal for UI code. I think they're at sub-1ms pauses on multi-GB heaps now. So even if you want to run at 100 fps it shouldn't be a big obstacle to making frame rate. Of course there's a throughput trade off, but same thing with reference counting.
Although I guess it doesn't matter much since the library ecosystem isn't there. I think it would have been an interesting choice for Flutter instead of Dart though.
For just memory management, I don't see the downside of GC (vs reference counting) if the latency is good enough. Sure you can still leak memory by maintaining references but at least it deals with cycles (and it's one less thing that any dependencies can screw up).
If GC latency is OK, the only remaining advantage of reference counting I can think of is the deterministic destruction of non-memory resources like file handles etc.
I've worked with production Java systems for many years, and have had to tune GC, implement suballocation schemes etc. It is definitely not a panacea, and I meant to say that it was not, in my original comment. But at least GC fixes mostly leave the source code alone (ignoring suballocation tricks). I find reference counting to be less intuitive, and I don't like the fact that fixing reference counting problems require modifications to source more often.
My Swift usage stopped in 4.x, so I'm unfamiliar with the 5.0 improvements.
This is a common sentiment, but it rarely holds up to closer scrutiny (such as measurements...). Swift is both slow to run and very slow to compile. Both compile and runtime come with extremely high variance. Such unpredictability is arguably even worse than just plain slow performance.
and many instances of it mean something is badly wrong in the codebase, and the developer(s) haven't adapted to how must be done.
In contrast:
bad.shit.happends
Good look with that...
- "let" is a mess
Overloading keywords have problems, but in this case the rules are simple. And is not that many context to worry about.
- I would much rather have = mean assignment
Agree. Overloading keywords are fishy, but operators are in another league!
Have some sense for maths but in other contexts is not worth the extra "feature".
- Reference counting is a bad compromise
You mean, ARC. Is not exactly the same, and the compromise is totally worth. I work with .NET for iOS/android and man, is heavy.
All is about what is default.
With GC, by default, eat memory and unpredictable destructors. With (A)rc only need to worry about break cycles. That not happened often enough to be a real problem
BTW, I have use obj-c, pascal, .net, python, rust. The ARC model is the best for most kind of code most do. I honestly have more unpredictable and unfixable problems with GC (mostly on android with underpowered devices), so I prefer to get something less automatic..
> [Using Optional] mean that wrong code look wrong
...as long as you don’t use any implicitly unwrapped optionals (which virtually all Mac/iOS code does), or use any frameworks that predate Swift (like AppLit/UIKit/Foundation), or wrap any C libraries (most third-party libraries in the world).
So basically that’s true for the 5-line samples showing how cool Optional is, and no real program I’ve ever written. It was a nice experiment but in practice I have more issues stemming from Optional than I ever did with nil.
> In contrast: bad.shit.happends
Do you not read any Swift forums? There are newbies posting every single day asking why "a.b.c" crashed in Swift.
I wonder if you have real experience with swift or you’ve just been looking at the language from a distance, because i disagree with pretty much every point you made.
Optional is the best thing that could happen to a language that allows nil values ( the only other option being not allowing them at all, but that’s not common).
If let ( and guard let) is an elegant idiom for unwrapping optionals safely, but that’s about the only cass you’re going to see a let in something that looks like an expression. The only complain you could have in that part in the language is between let and var, but that’s actually quite useful in practice for self documenting code.
Operator overloading could become dangerous, but it seems that it is used very sparingly in the swift ecosystem. Standard library doesn’t overuse it, so people don’t as well.
Reference counting to me has quite the same drawback as GC : it makes you forget about memory cycles and ownership. But apart from rust who tried something very different ( and is scaring a lot of developers), once again i don’t see a lot of other options.
I do have some experience, playing with an iOS app for several months, through various versions of the language (3.x, 4.x). But this was as a hobby. I liked Optionals when I learned about them, and less as I started using them. I found that libraries sometimes changed return types, e.g. T to T? (or vice versa). The feature struck me as having some drawbacks similar to Java checked exceptions: the rigor required ran counter to clean and easy to understand code. Did I just not get the design of the feature? Perhaps, but I did find it very difficult to avoid tweaking code with ? and !.
I have no problem with var vs. let. I like that distinction. And I do understand that let is used only sparingly in expressions. But that's what bugs me about it, it is so limited. It is not an "orthogonal" feature, (usable in any expression). An expression is ideally functional (no side effects). Let definitely does have a side effect, declaring and binding an identifier. I find it awkward to mix the two ideas. This may be many years of mental baggage, from C, C++, and Java, but it is there, and I think that the introduction of such a major side-effect into the world of expressions is a genuinely bad idea.
GC vs. reference counting: GC really does allow you to forget about memory management. Until you start running into problems requiring GC tuning. But then, the fixes tend to leave the code alone completely. With reference counting, tuning requires more intrusion into code. Yes, this is subjective. Just explaining my reasoning.
Whether there is misunderstanding by the grandparent post or not, in practice there are a lot of people who do just play with ?/! until they manage to get code to compile and then hope for the best.
You can see it all over the place in code people write, posts on Stack Overflow, etc. The Apple Swift book does a poor job explaining the rationale and benefit of using option types.
> I would much rather have = mean assignment, and use function call notation when I really want functions to run.
And then you end up with Java where you have to write so many boilerplates for getters and setters, even if they are only plain attribute access, just in case you want a function later.
I agree that a very common Java pattern is to create getters/setters for every private field. Which is just stupid, might as well have the members be public. To use the popular phrase, Java classes like that have a "bad code smell". It tells me that the author of the class doesn't really understand how it should be used. I think a well-designed class will have private members and public member function interfaces that don't resemble each other very much.
From your comment looks like you do not get Swift anf that prevents from getting why it is loved.
There is no need to "fiddle" with ? and ! Optionals are not that complex. And there is nothing wrong with let. It has nothing to do with optionals.
I'm glad I'm not the only one who feels this way. I used to absolutely love writing Objective C, like totally get into a zone and lose track of time. I've never managed to achieve that same feeling with Swift.
Personal opinion: if the index is based on search, then if one language has better documentation, better ide support, less surprises, then the search count will be less and probably has a lower ranking in Tiobe.
And also, since swift's adoption domain mainly in ios development, it heavily affected by the iOS ecosystem.
My take on why objective c is higher ranked, not because it is better, but it has tons of gotchas, that people have to do heavy search to get things done.
I think good documentation, both authoritative but also that created by active users from blogs and also Stackoverflow are what make people productive in a language and enables both newcomers and experts to progress. And of course libraries and tools are being developed, which also facilitate usage. Look for example at R, much earlier than Python it had various libraries with machine learning algorithms, at the same time the language is really "unusual", so people rather rewrote libraries from scratch in Python. At least for time series analysis I think even today there are more advanced libraries available in R. But the documentation at least some years ago was just not on par with the difficulty/unconventional ways to do things. (Despite having a super helpful tightly knit community as far as I can tell) The Python equivalents on the other hand have often more documentation than needed.
I think also JS won a lot due to good documentation, in fact there used to be an SEO campaign to boost MDN docs because the JS docs used to be so bad making people write bad code, I think the language's reputation still didn't recover from that.
It might be lacking, but there is definitely a culture within iOS of using the Apple docs for things, Apple tooling, Apple development practices, etc. It’s a much more closed ecosystem in many ways than most of the other ecosystems I’ve been exposed to (JS, Python, Ruby, even .NET in some ways).
Because of this, I wouldn’t at all be surprised if searches aren’t common because Apple provides documentation, regardless of its quality.
This is not a rank of which language is "better". It's merely about usage. I'm sure there is a lot of documentation and not that many "gotchas" in Java for that to be the reason for searches by Java developers. There are a lot of Java searches because Java is popular.
Swift is a good but not great language considering when it came out.
One good thing about it is that it lets iOS apps run as well as Java/Kotlin apps in ~60% the memory. I'm sure the layers of legacy Android APIs also contribute to this.
The other good thing is that it's close enough to Kotlin to switch between iOS/Android without as much friction.
I code for iOS (in ObjC) and Android (in Java) and honestly the language differences are trivial to me. The much harder parts to deal with are the APIs and the IDE differences. (In particular, I really loathe gradle and Android Studio.)
have used swift since version 2.x to create several mobile apps so i consider myself proficient, for the record, i have also used php, nodejs, c/c++, java, ruby, python, and golang quite extensively. i consider myself a full stack developer.
regarding swift, i am not a fan of the language at all, i use it more out of necessity, when i started to write ios apps, swift was available and i had already gotten used to not having to deal with memory management and such so chose the language, i also thought objc as a language for ios apps was a bit too verbose after looking at some tutorials, i had been used to using interpreted languages and syntactically concise languages like golang so thought i'd give swift a try.
somehow, over the years, i've managed to write a few apps with swift, so it does the job, the 2 things i dislike the most is the "as/as?/as!" statement, e.g. when i have a dictionary like object [String: Any] and having to "as" that is annoying to me, and you can't cast which to me is more direct, you have to first "as? Int" and then de-convert the optional with an !
The second thing i really hate about the syntax is the whole thing with "let" constants, i'm fine having to check for NULL first, but to do if let apples = fruits["apples"] as? String {...}, i guess this is kind of related to the first issue.
my swift code is such a spaghetti mess of these statements, i imagine a lot of it has to do with me, but this doesn't seem to be a problem with other languages. it could also be that i'm just trying to plow through the code so that i can get functionality working asap.
If you're doing so much casting you're doing something wrong. Swift's power comes from the type system, which alleviates the need for all casting in general. Instead of using a [String: Any] dictionary which bears no meaning at all, consider converting it to a struct with accessors of the right types. If you work with the type system, Swift will be a joy to use, because that's where it shines.
I’d agree with this completely. A lot of the people I see having issues with it are trying to write it like python or something. For this style of coding objective-c is a much better choice.
not sure why you were downvoted, i voted for your comment, makes perfect sense. i was using a generic [String: Any?] to hold a mix of variables, you are absolutely correct, should use a struct or maybe even a class.
I don't see Swift used for anything outside of iOS development. I don't really think it has enough to offer over more neutral languages like Python or TypeScript to make it worth the time of learning a new language. It's in a position similar to C# in my opinion.
Maybe over TypeScript but I would love it if Swift displaced Python. Python is ridiculously popular for some good reasons (the clarity of code that tends to come out of it) but a whole lot of bad ones - complete lack of an effective type system, no usable multithreading etc let novice developers write bad code lazily without really feeling bad and it still passes as good code ... it's effectively the PHP of this decade.
This simply won't happen till Swift can interop with C, C++ and possibly even ASM, fluently.
Even then, you need structure, data types, and actual foresight while writing code, which leaves out all the less CS/SE trained peeps, such as scientists.
And Swift is never going to be better as a scripting language. Lua, Python, Bash etc all have a few things in common, and Swift would stand out like a sore thumb in that company.
Readit News
https://www.tiobe.com/tiobe-index/javascript/
Javascript in 2019 only has 0.5% more market share than in 2004?
2019 has basically every new UI (and many rewrites of old ones) being built in Javascript, 2004 it was being used for the occasional drop down menu.
(Even if you include Typescript, the only compile-to-JS language in the top 50, it still only gets to 2.7% today compared to 2% in 2004).
See also C unassailably at number 2. I think we can all agree that in 2019, there is more active development in Javascript, than C - Likely it's benefiting from their methodology giving it credit for C++ and C#, so at least we can theorise about that one, but I really have no idea for Javascript.
Lots of developers use Javascript in the course of their work. Few of them will refer to their work as "Javascript programming" -- they will typically use either a broader term, like "web development", or a more specific one, like "React development". Neither of these would influence TIOBE's rankings.
yeah... no
> See also C unassailably at number 2. I think we can all agree that in 2019, there is more active development in Javascript, than C
bubbles, bubbles, bubbles. the immense majority of large companies I see start new GUI projects in Java, C#, C++, ... daily. Count the hundred of thousands of programmers working for gigacompanies like Samsung (with more than 40k devs), ATOS (122K employees, mostly devs), CapGemini (211k employees, mostly devs), etc... they are far from all doing JS.
Clojure is right next to it on the list. It’s not only compile-to-JS but 100% of the people I know using it use it that way.
There are a couple of really strange comparisons you can spot in the results. For example, Scratch -- a visual programming language made for children which is only usable on its own web site -- is ranked higher than TypeScript, Lua, Scala, Kotlin, or Rust. Similarly, D -- a proposed replacement for C++ which has never found any real traction -- is ranked even higher.
It isn't a measure of popularity - its a measure of which languages either intentionally or accidentally have the best SEO.
Here's what they say about their methodology:
> The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
> Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings.
Bing and Yahoo! are both front ends to the same search engine. Wikipedia, Amazon, and YouTube aren't general-purpose search engines at all, and it's unclear how accurate the results of a Baidu search would be for English-language search terms like "Javascript programming".
The best measure of a language's popularity needs to take job vacancies and github metrics as their most meaningful measures. Stackoverflow posts and google searches will help too but contain a lot of natural bias.
Outside of iOS I don’t think it’s made a dent and I would be surprised if things like Swift for Tensorflow make a difference there (if only because the number of ML devs is very small and the appeal of Swift for ML is also pretty small).
Example build.rs: https://github.com/emoon/rust_minifb/blob/master/build.rs
- Optional is a nuisance and I don't think it is highly effective at preventing the dereference of a nil pointer in practice. People are going to fiddle with ? and ! until their code works, and the protection that Optional provides then disappears.
- "let" is a mess. In one context it means unwrapping an Optional. In another, it doesn't. If you use it in an expression, it interferes with the usual refactorings that people apply to expressions.
- There is so much fussy detail around preserving the syntax of object.field = expression. didSet, willSet, getters, setters, oldValue, newValue. WHY IS THIS SYNTAX SO FRIGGIN' IMPORTANT? One of the justified criticisms of C++ (IMHO) is that operator overloading means that all sorts of functions can be running under innocent-looking code. I would much rather have = mean assignment, and use function call notation when I really want functions to run.
- Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've seen examples of code that require careful and non-obvious use of weak to avoid memory leaks, (sorry, I don't have the reference handy).
It sure beats Objective-C, and it does have some nice modern features, but I think they made some unfortunate design choices.
- Optional has made null pointer exceptions virtually non-existent. There are occasions where deserialization does result in a nil value where one is not expected, but that's rare. I think this is as massive as garbage collection was back in the day.
- The language is in a sweet spot between something convoluted and heavy like Java and something overly simplistic like PHP/Ruby/Python. It's perfect for software development and large code-bases with a low learning curve.
- There is no magic (methods, properties, etc). Everything is explicit but not wordy. This may change in the future but I hope it never does.
- It's more legible than Kotlin with fewer unnecessary language features. Speaking of which...
- It's a simple language and its syntax is straight forward
It's not a perfect language:
- The package manager needs a lot of work
- Extensions can lead to confusion (eg. in the case of conformance to protocols (interfaces)).
- I would like an optional garbage collection system for long-running processes (e.g. server-side applications)
- I would like it to perform even better
You can nitpick syntax anomalies with any language, but a language is defined by how easy it is to scale to multiple programmers, how applicable it is to a problem, how well it performs, how easy it is to read for someone new to the system, how it helps the programmer not commit mistakes, etc. Of all the languages I've written, none has been as successful in all regards as Swift.
Wha? It has about 100 reserved words — more than C++, now, I think. Even its own designer said [1]:
“You’re unlikely to run into anybody that says that Swift is a simple language. Swift is a complicated language.”
If you consider Swift simple, what language do you consider complex? Of all the languages I've written, none has been as complex as Swift.
[1]: http://atp.fm/205-chris-lattner-interview-transcript
This is such a bizarre statement to me. I have to wonder if the commenter has ever dealt with production systems or code that uses GC? Because with years of writing and tuning Java servers, I've long since come to the conclusion that GC is largely a false economy.
You still have to deal with memory leaks but the cause this time is objects maintaining references they don't need. Sure GCs become cleverer at detecting unused forests of objects and so on but this largely makes another problem worse: so-called stop-the-world pauses for a full GC. It's still an issue you have to deal with on Java, Go and probably every GC language.
This isn't to say that ref-counting is a panacea (what is?). Particularly on servers the critical region for updating the ref-count itself can become hot and a bottleneck.
But this isn't really a problem on mobile app code. I've long said that iOS's uses of ref-counting (ARC since 5.0+) is a strategic and competitive advantage to Android's Dalvik/Java GC.
Google's Plan9 2.0 (ie Fuchsia) makes me sad (for many reasons). Just one is that they've embraced Dart/Flutter at the application level (which isn't required as anyone who works on it will tell you, yada yada yada) but Dart is such a strange choice because it still relies on GC. What's the point?
Oh and just to be pedantic, you list ref-counting as a negative of Swift compared to Objective-C. ARC is orthogonal to that. Like I said, ARC came about in iOS 5.0.
Although I guess it doesn't matter much since the library ecosystem isn't there. I think it would have been an interesting choice for Flutter instead of Dart though.
For just memory management, I don't see the downside of GC (vs reference counting) if the latency is good enough. Sure you can still leak memory by maintaining references but at least it deals with cycles (and it's one less thing that any dependencies can screw up).
If GC latency is OK, the only remaining advantage of reference counting I can think of is the deterministic destruction of non-memory resources like file handles etc.
My Swift usage stopped in 4.x, so I'm unfamiliar with the 5.0 improvements.
I think optionals are a great way of saying: “Hey developer, this value can sometimes be nil; be sloppy or not, your call.”
Any language you pick is an interplay of choices and compromises. No such thing as perfect.
This is a common sentiment, but it rarely holds up to closer scrutiny (such as measurements...). Swift is both slow to run and very slow to compile. Both compile and runtime come with extremely high variance. Such unpredictability is arguably even worse than just plain slow performance.
And that is GOOD. This mean that wrong code look wrong:
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
and many instances of it mean something is badly wrong in the codebase, and the developer(s) haven't adapted to how must be done.
In contrast:
Good look with that...- "let" is a mess
Overloading keywords have problems, but in this case the rules are simple. And is not that many context to worry about.
- I would much rather have = mean assignment
Agree. Overloading keywords are fishy, but operators are in another league!
Have some sense for maths but in other contexts is not worth the extra "feature".
- Reference counting is a bad compromise
You mean, ARC. Is not exactly the same, and the compromise is totally worth. I work with .NET for iOS/android and man, is heavy.
All is about what is default.
With GC, by default, eat memory and unpredictable destructors. With (A)rc only need to worry about break cycles. That not happened often enough to be a real problem
BTW, I have use obj-c, pascal, .net, python, rust. The ARC model is the best for most kind of code most do. I honestly have more unpredictable and unfixable problems with GC (mostly on android with underpowered devices), so I prefer to get something less automatic..
...as long as you don’t use any implicitly unwrapped optionals (which virtually all Mac/iOS code does), or use any frameworks that predate Swift (like AppLit/UIKit/Foundation), or wrap any C libraries (most third-party libraries in the world).
So basically that’s true for the 5-line samples showing how cool Optional is, and no real program I’ve ever written. It was a nice experiment but in practice I have more issues stemming from Optional than I ever did with nil.
> In contrast: bad.shit.happends
Do you not read any Swift forums? There are newbies posting every single day asking why "a.b.c" crashed in Swift.
Optional is the best thing that could happen to a language that allows nil values ( the only other option being not allowing them at all, but that’s not common).
If let ( and guard let) is an elegant idiom for unwrapping optionals safely, but that’s about the only cass you’re going to see a let in something that looks like an expression. The only complain you could have in that part in the language is between let and var, but that’s actually quite useful in practice for self documenting code.
Operator overloading could become dangerous, but it seems that it is used very sparingly in the swift ecosystem. Standard library doesn’t overuse it, so people don’t as well.
Reference counting to me has quite the same drawback as GC : it makes you forget about memory cycles and ownership. But apart from rust who tried something very different ( and is scaring a lot of developers), once again i don’t see a lot of other options.
I have no problem with var vs. let. I like that distinction. And I do understand that let is used only sparingly in expressions. But that's what bugs me about it, it is so limited. It is not an "orthogonal" feature, (usable in any expression). An expression is ideally functional (no side effects). Let definitely does have a side effect, declaring and binding an identifier. I find it awkward to mix the two ideas. This may be many years of mental baggage, from C, C++, and Java, but it is there, and I think that the introduction of such a major side-effect into the world of expressions is a genuinely bad idea.
GC vs. reference counting: GC really does allow you to forget about memory management. Until you start running into problems requiring GC tuning. But then, the fixes tend to leave the code alone completely. With reference counting, tuning requires more intrusion into code. Yes, this is subjective. Just explaining my reasoning.
You can see it all over the place in code people write, posts on Stack Overflow, etc. The Apple Swift book does a poor job explaining the rationale and benefit of using option types.
I suspect that might be a sympton of excessive complexity and parent's example of C++ seems spot on.
And then you end up with Java where you have to write so many boilerplates for getters and setters, even if they are only plain attribute access, just in case you want a function later.
And "let x = someOptional" doesn't, right?
So the first form does have something to do with Optionals, and it is true that the two forms of let behave differently with respect to them.
(I have moved on from Swift, so if things have changed since Swift 3.x and 4.something, my apologies.)
Swift is just too much, too many things, and yes, they kind of dorked optionals. To me it's just trying to hard.
And also, since swift's adoption domain mainly in ios development, it heavily affected by the iOS ecosystem.
My take on why objective c is higher ranked, not because it is better, but it has tons of gotchas, that people have to do heavy search to get things done.
I think also JS won a lot due to good documentation, in fact there used to be an SEO campaign to boost MDN docs because the JS docs used to be so bad making people write bad code, I think the language's reputation still didn't recover from that.
Because of this, I wouldn’t at all be surprised if searches aren’t common because Apple provides documentation, regardless of its quality.
One good thing about it is that it lets iOS apps run as well as Java/Kotlin apps in ~60% the memory. I'm sure the layers of legacy Android APIs also contribute to this.
The other good thing is that it's close enough to Kotlin to switch between iOS/Android without as much friction.
regarding swift, i am not a fan of the language at all, i use it more out of necessity, when i started to write ios apps, swift was available and i had already gotten used to not having to deal with memory management and such so chose the language, i also thought objc as a language for ios apps was a bit too verbose after looking at some tutorials, i had been used to using interpreted languages and syntactically concise languages like golang so thought i'd give swift a try.
somehow, over the years, i've managed to write a few apps with swift, so it does the job, the 2 things i dislike the most is the "as/as?/as!" statement, e.g. when i have a dictionary like object [String: Any] and having to "as" that is annoying to me, and you can't cast which to me is more direct, you have to first "as? Int" and then de-convert the optional with an !
The second thing i really hate about the syntax is the whole thing with "let" constants, i'm fine having to check for NULL first, but to do if let apples = fruits["apples"] as? String {...}, i guess this is kind of related to the first issue.
my swift code is such a spaghetti mess of these statements, i imagine a lot of it has to do with me, but this doesn't seem to be a problem with other languages. it could also be that i'm just trying to plow through the code so that i can get functionality working asap.
Even then, you need structure, data types, and actual foresight while writing code, which leaves out all the less CS/SE trained peeps, such as scientists.
And Swift is never going to be better as a scripting language. Lua, Python, Bash etc all have a few things in common, and Swift would stand out like a sore thumb in that company.
https://medium.com/@richardeng/smalltalk-and-tiobe-5409afb19...