
What's Going Down at the Tiobe Index? Swift, Surprisingly - mpweiher
https://blog.metaobject.com/2019/04/what-going-down-at-tiobe-index-swift.html
======
enneff
The Tiobe index is not a reliable indicator of anything; their methodology is
extremely noisy. A fractional percentage drop is meaningless.

~~~
Macha
The clearest example to me that Tiobe does not reflect reality is the
Javascript chart:

[https://www.tiobe.com/tiobe-index/javascript/](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.

~~~
mr_toad
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.

~~~
stephenr
And if _I_ want to search for say which of call/apply takes an array, or even
confirm what version of php a new flag is introduced, I’m not searching for
“$language programming $feature”.

I’m using DDG bangs to reduce the noise from the start and take me straight to
a site specific result : `!mdn function apply` or eg `!php preg_split`.

------
raphlinus
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.]

Example build.rs:
[https://github.com/emoon/rust_minifb/blob/master/build.rs](https://github.com/emoon/rust_minifb/blob/master/build.rs)

~~~
suraj
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.

~~~
raphlinus
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.

------
geophile
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.

~~~
cletus
> \- 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.

~~~
throwaway34241
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.

------
shuoli84
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.

~~~
Hamuko
Does Swift have "better documentation"? Because I've always found Apple's
developer documentation a bit lacking.

~~~
danpalmer
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.

------
karmakaze
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.

~~~
js2
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.)

------
epynonymous
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.

~~~
infinisil
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.

~~~
pixelrevision
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.

~~~
epynonymous
also not sure why you were downvoted, i voted you back up.

------
symlinkk
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.

~~~
zmmmmm
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.

~~~
sk0g
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.

~~~
zmmmmm
Yes, I agree completely. Indeed, I would say the same thing in reverse if
Swift was taking over the world of scripting (a bit like how people propose
Kotlin and Scala as scripting languages ...). Using those languages for
interactive analysis & high level scripting is as bad an idea as using Python
for building a complex application with large numbers of rich data structures.

~~~
sk0g
> using Python for building a complex application with large numbers of rich
> data structures.

Eh, you don't need to though. Python can be the glue for your tools, if you
will. Writing the meaty parts can be done in C/++, while you glue everything
together in Python, giving you the best of both performance and ease of
writing.

------
mpweiher
Oh, and it appears that Smalltalk has at least re-entered the top 50 after a 5
year absence:

[https://medium.com/@richardeng/smalltalk-and-
tiobe-5409afb19...](https://medium.com/@richardeng/smalltalk-and-
tiobe-5409afb19ef3)

~~~
Yhippa
This took me down a rabbit hole. I wonder if there are any legit reasons to
use Smalltalk (Pharo) these days?

------
barbecue_sauce
My main issue with Swift, at least initially, was how much of a moving target
it was/(is?). It's been in public use for under five years and it's already on
it's 5th major version. I'd learn it to a certain degree, start working on
something else, then come back and find that a lot had changed while I wasn't
paying attention. That said, the difficulty in iOS development stems from
getting a good understanding of the core libraries, and thats much easier to
do in Swift than in Objective-C (unless you're already familiar with that
language or coming from something like Smalltalk).

~~~
plorkyeran
Swift 3 was the last version that had dramatic changes. The first two years it
was pretty upfront about being a work-in-progress that wasn't for people who
wanted something stable, and the last two years it's been pretty stable with
only very minor incremental changes.

~~~
infinisil
> The first two years it was pretty upfront about being a work-in-progress
> that wasn't for people who wanted something stable

I've been very much on the Swift train in its first 2 years, but I've never
heard of anything like that. Do you have a source?

~~~
pixelrevision
[https://swift.org/blog/abi-stability-and-more/](https://swift.org/blog/abi-
stability-and-more/)

Almost every release has been pushing towards this. That’s not to say that
that swift has been “unstable” as it was pretty solid from the beginning but
they did make it pretty clear that you would need to accept a lot of changes
in the early days.

------
Doubl
The tiobe index always seems to be way out of line with the other indices out
there. Nobody but tiobe ranks VB.net above c#. Also the other day I read that
Lazarus isn't taken into account in terms of assessing the popularity of
object Pascal, because Lazarus is an IDE, not a language. Tiobe also seen to
be constantly tweaking the methodology such that if you look back at
historical rankings they can be totally different to the rankings for the same
period that were reported historically. Which is verging on the dishonest. It
would be like a tipster going back and revising his tips after the fact.

~~~
oaiey
Microsoft own "statistics" claim million of C# devs, 100ks of VB.NET devs and
10ks of F# devs.

Tiobe is strange. Either they blend all Basic together (legacy code bases) or
something more stupid happens :)

~~~
staffanj
Its not strange. Just a result of bad input.

Search for:

+"C# programming" \- 2 340 000 results <\- USED

+"Visual Basic .NET programming" \- 17 000 000 results <\- USED

+"C# .NET programming" \- 26 600 000 results.

~~~
oaiey
Okay. So it is "more stupid happens" :).

------
childintime
Tiobe compares search engine queries and lists the most popular languages
mentioned in its list. So as an example PHP will naturally end up high on the
list and Closure will end up low. Because PHP has lots of irregularities to
check, and Closure doesn't. So it might be Swift is simply a better language
than ObjectiveC?

------
3jckd
My first thought once I saw this was "flutter". It's really getting a lot of
market share in mobile dev and all you need to write is Dart, for better or
worse. Also, whenever you need to do iOS specific duct-tape-plumbing, it seems
that Obj-C is still more capable than Swift because of the accumulated legacy.

However, take it as an educated guess rather than a fact since I have never
been a mobile dev apart from hobby apps.

EDIT: typos.

~~~
seanalltogether
I've recently been stuck with a react native project and I was surprised to
learn that objective-c is still the language of choice for interop.

~~~
dep_b
Well until the next version of Swift it’ll add 10mb of runtime to your app,
not worth it for 100 lines of code

~~~
saagarjha
The _current_ version of Swift, actually. Swift 5 has already been released.

------
jasonhansel
I really wish we could build iOS/Cocoa apps in Rust. Like Swift, we could use
reference counting instead of GC, but Rust has a much nicer type system.

~~~
blub
Swift's type system was designed to make developers happy, Rust's to make the
borrow checker happy.

As it turns out, some people think like a borrow checker and don't have any
issue with Rust's choice. But most don't and we should not make them
miserable.

~~~
jasonhansel
Well, really it was designed for ObjC interop. Hence the limits on (e.g.)
generic protocols.

------
mountaineer
Not much movement for Swift either direction in the job postings shared in the
monthly whoishiring thread, but still consistently beating Objective-C

[https://www.hntrends.com/2019/mar-postgresql-vs-mysql-no-
lon...](https://www.hntrends.com/2019/mar-postgresql-vs-mysql-no-longer-
close.html?compare=Swift&compare=Objective-C)

------
cageface
To the extent that this is even meaningful I suspect it reflects a
disenchantment with native apps in general. The app goldrush is long since
over and getting an app on a user’s home screen now is extremely expensive and
difficult.

That said I’ll take Swift over Objective C any day.

------
VectorLock
I'd be curious to hear from iOS devs what they think is going on here. Did
anyone try moving to Swift and what was the specific reason for going back to
Obj-C?

~~~
exelius
I would suspect it’s because even many of the core libraries are still written
in Obj-C. Swift is neat and I really like it, but the ecosystem is such that
even when using it on a new project you end up writing ~25% of your project in
Obj-C.

~~~
kitsunesoba
Depends on the nature of your project but I can count the number of Obj-C
libraries I’d be likely to use in my projects on one hand, and they all play
secondary roles (e.g. analytics). For almost anything else Foundation/UIKit
and third party Swift libraries would be used.

------
baron816
Is there any good reason why Apple couldn't just let us code apps directly in
JS/React and not have to go through React Native with its overhead? React
surely isn't perfect, but it's likely the best way to create large scale UIs.
Far better than Swift.

~~~
millstone
Neither React nor Swift can create UIs alone.

~~~
saagarjha
…they can?

~~~
millstone
React is a set of JS APIs and tools that live on top of a an underlying model
(the browser DOM, litho, etc.) Swift is a programming language. The comparison
doesn't really make any sense.

~~~
saagarjha
Well, yes, but this is a pedantic comment in relation to the post you were
replying to.

~~~
millstone
It wasn't meant to be. OP expressed a desire to "code apps directly in React"
and avoid "React Native with its overhead." But that's meaningless: the React
design is a layer on top of an underlying model, and that layering will always
impose some overhead.

------
tonetheman
Not sure I believe much in what Tiobe has to say about programming languages
but I would happier if Objective C was dead forking last.

