[throwaway2037]

One of the most complex apps that Microsoft produces is Visual Studio. It is currently a hybrid of C++ and C#. I suppose that almost all new features are written in C# where possible. Why won't Apply follow the same path? The developer productivity in Swift must be 10x compared to Objective C. To be clear: I write this post as someone who has infinite love for optimization of native code. However, in many situtations, it is simply more "dev efficient" to write code in a managed (VM) langauge. Thoughts?

[mckn1ght]

Apple does use Swift in their IDE, Xcode. Several years ago they rewrote the text editor component in Swift. It’s taken them a while to get all the features back that the old one had, and has had a fair amount of bugs as well. I often wonder why they didn’t just leave it in ObjC and add the new features they wanted to add, like the minimap or sticky declaration heaters.

I definitely wouldn’t call Swift a 10x improvement in efficiency, and I like coding in Swift. I do advent of code in it each year, but spend a fair amount of time just fighting with the compiler–after all these years, it still emits strange or just flat out incorrect diagnostics.

[internetter]

I concur. I'm 10k LOC deep into a SwiftUI app (Absolutely no clue how much that works out to be in Objective C + UIKit equivalent code), and one of the most frustrating things (after all the stuff you can't do without a PhD in apple internals) is how piss poor Swift errors are. I've changed a line of code in one file, and then another, completely unrelated one stopped compiling. Most frequently, it's something about how checking the file took too long and it should be broken up (which you will learn, really means you have a small error somewhere in said file and swift isn't in a sharing mood)

[jimbokun]

> The developer productivity in Swift must be 10x compared to Objective C.

Why do you say that? Do you have experience backing up that estimate?

[throwaway2037]

When I switch between C or C++ and a (non-deterministic) VM-based language like Java or C#, it feels like 10x. The IDEs are way more advanced, including (for me) the #1 all-important: debugging. For me (a mere mortal, average programmer), the fact that null pointer exceptions are clear in Java/C# is a huge gain compared "core dump" in C or C++. Going further, I am sure many would say the same kind of productivity speed-up for C or C++ to Python or Ruby.

[Gibbon1]

I have a bit of code I use for ARM Cortex devices where I can trap bus errors. Most of the time I can recover the program counter where that happened. And use addr2line to get the file and line number. I've heard game developers talk about doing that sort of thing as well.

I would think if the C/C++ developers didn't have their head up their **[1] that could be a standard out of the box feature. There isn't any reason a program couldn't spit to stderr, 'seg_fault: file boots.c, line 1043'

In C++ I'm dubious you couldn't throw an exception instead of dumping.

[1] Got rid of frame pointers because they were sure that would make their dog slow C++ compilers run faster. Voice over. But it didn't make them faster. It made programs impossible to profile.