Slashdot Mirror
Swift Vs. Objective-C: Why the Future Favors Swift
snydeq writes: InfoWorld's Paul Solt argues that It's high time to make the switch to the more approachable, full-featured Swift for iOS and OS X app dev. He writes in Infoworld: "Programming languages don't die easily, but development shops that cling to fading paradigms do. If you're developing apps for mobile devices and you haven't investigated Swift, take note: Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms. Thanks to several key features, Swift has the potential to become the de-facto programming language for creating immersive, responsive, consumer-facing applications for years to come."
Since when is embedded programming associated with "immersive, responsive, consumer-facing applications"? I don't think Swift is going to replace C anytime soon in that department.
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
It is highly unlikely that Apple is going to rewrite all that GPL and BSD code at the heart of iOS with Swift. As long as those core projects are based on 'C', they'll stay in 'C'.
I do not fail; I succeed at finding out what does not work.
The future favors Swift only because Apple is going to phase out use of ObjC. That's it. Arguing about languages is silliness when Apple will likely force you into using Swift for iOS9 compatibility in the next 12 months.
The only reason anyone cared about Objective-C was for Apple development. Otherwise it would be as popular today as Delphi or Eiffel, for instance. Nothing wrong those object-oriented languages, just no particular business need for them.
Now Apple wants to replace Objective-C with Swift. Apple is probably going to get what it wants with its own developer base, just like MS managed to "convince" its developer base to abandon VB-6 in favor of C#.
I donno. "development shops that cling to fading paradigms do [die]." Obj-C is a perfectly good tool. Fortran and COBAL as still used all over the place. The only way Obj-C dev shops are going to die is if Apple makes it so (and I have no doubt they will). But I think this fundamental argument is flawed if not downright wrong.
It's nice that there's a programming language debate where the future has been entirely settled. Thanks infoworld!
"There's no way to catch it!" cried Tom, with exceptional angst.
You do not need a more approachable language for iOS core components. Sure, that may be good for people creating end-user applications. But people who won't learn C because it's too hard are not quite the kind of people you want working at the heart of your operating system.
"I decided I could write something better than everything out there in two weeks. And I was right." - Linus Torvalds
The important thing to remember here is that Swift is absolutely destroying Rust.
Rust has been nothing but hype so far. Many Ruby on Rails hipsters have rallied around it, but they haven't actually managed to produce anything useful with it.
Anything that can be done using Rust can be done better by using C++.
C, C++ and Go are the dominant languages on Linux. Rust has made no inroads here.
C++ and C# are the dominant languages on Windows. Rust has made no inroads here.
Now that Swift is seeing tremendous uptake within the iOS and OS X sphere of influence, Rust has even less of a chance than it had before.
I think that Swift will be seen as the final nail in Rust's coffin. Swift has provided developers with productivity, while Rust has provided them with false hopes.
We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.
According to the TIOBE Index, Java has more usage than all three of them put together. I'd hardly call it a "minor player".
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
Objective-C was ahead of its time. It uses messaging for communication between Objective-C, and using "the runtime" (a tiny virtual machine that is embedded into each executable) messages are resolved to a function pointer. Other compiled languages use static dispatch, vtable dispatch (allows overriding) or in-lining. However, messaging gives an advantage in that it affords features that are available in higher-level 'interpreted' or 'managed' languages:
The above features allow all kinds of useful things like Aspect Oriented Programming, instrumented objects at runtime (eg for object-relational-mapping), Cocoa's elegant property observers, etc. Another advantage is that Objective-C is close to the bare-metal so its very easy to take advantage of the above, while dropping back to raw C (or C++) as needed for performance tuning, which given the 95-5 rule is not too often.
Contrast these dynamic features, with C++ which fills another niche. Now the industry has had 30 years to forget how useful these features are, so Swift uses static and vtable dispatch. Given a virtual machine, with just-in-time compilation this is no problem, but as a compiled language it means forfeiting the above. Swift allows the above if a class extends a Cocoa Foundation class, but this problems are:
I'm surprised more people didn't raise concerns about this.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
What is Swift written in?
It is built with the LLVM compiler framework included in Xcode 6, and uses the Objective-C runtime...
So... C. Ok, we're done here.
No wait. One more thing. It's the Objective-C runtime. Which means Objective-C programs will just keep running, as they ever have.
Swift and Objective-C code can be used in a single program, and by extension, C and C++ as well.
The new language can't supplant the old one while the old one exists in the same environment. More to the point, compatibility with Objective-C, C, and C++ was an explicit design goal. So you can just pack up all the bullshit about taking over the world.
I don't know how this idea started, but only a non-programmer could think Swift is more approachable than Objective-C. Swift is way more complicated and has more fundamentals that must be understood.
let versus var
optionals, including implicit and explicit binding
differences between structs and classes (value versus reference)
generics
different ways of specifying parameters, including named and unnamed parameters
property declarations, including a multitude of shortcuts
The problem is, if you don't learn most of the syntax in all its variety, you'll have a hard time understanding any random code you come across. Learning by example helps make a language approachable.
We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.
Baghdad Bob, is that you?
lucm, indeed.
> 8. Swift supports dynamic libraries
The swift runtime is a static library (written in C++11) and linked in every executable, everytime there's an update to swift (runtime) you need to recompile all your code (see Apple's swift blog, first entry). This is why swift cannot be used for system API / libraries, at least until they have a stable runtime that can made a dynamic lib (like Obj-C is). But it being C++, I don't know if that ever gonna happen.
I've done Objective-C since before the release of the iOS App Store, and Swift almost full time since Apple released it last year...
Some of the things you mention beginners do not have to use (generics, and struts for example). To keep things simple to start with, they could just use classes instead.
I will agree that optionals might be a bit rough on the beginner - but perhaps not as starting from nothing, the concept of a bucket that holds a value instead of just using the value directly, would not be so foreign...
You also mention different ways to specify params, and shortcuts - but I see those as a major plus. You can just pick a level of detail that makes sense to you and work with that, until you feel comfortable with reducing further the syntax you use.
I think the function syntax is one of the cleanest and easiest styles to understand... I believe a few other languages have this form also, but in swift you just say something like "a function named takes in these params, and outputs those params" So it looks like:
func myFunc (a:String, b:Int) -> (a:String, b:Int)
it's just so balanced that you can have any number of things in or out.
There are a few things I think make Objective-C less approachable.
The separate header files, and the heavy modern use of private categories to define most internal properties confuse people as to where they need to define things.
Simply more verbose syntax all over. I like verbosity myself, I love named parameters... you get that with Swift though with a lot fewer characters typing.
Part of that extra syntax in ObjC is the shorthand to make arrays like @[] and @(value) to make NSNumbers... but in Swift Integer is treated the same as String, both are first class objects that you can do things with so it's more consistent. That in particular is I think a large benefit for newcomers.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I suppose it depends on what you want to do with it, and what you see Java's future as a wholly-owned subsidiary of Oracle is.
I was studying programming in college when the hype for Java began. We were using C and C++. What was true then still holds true today, in that in C/C++ you can write operating systems and conventional programs, but in Java you are limited to conventional programs. Java has the theoretical interoperability feature between OSes and hardware platforms, but in practice there's a lot of customization to make programs actually do this, and if one has to write versions for several platforms, it's not a whole lot more burden to compile those and distribute binaries instead of Java runtimes.
As for servers, I've always liked the mindset of putting as little as possible on the production server beyond what its job is. Hell, the idea of statically-compiling everything to allow one to eliminate libraries, let alone compilers on the production box, appeals in that if someone does break in there's a lot less they can do once on there. Java for server-side applications flies in the face of that, there are more general-purpose tools on the server rather than less.
I'm aware that I'm not in the majority for this stuff, and I didn't make programming my profession anyway so perhaps even I should be taken with a grain of salt, but it seems like in this speed to push features we've taken steps backward in real system security, and we're being bitten in the ass by it with ever increasing frequency. The very choice of programming language appears to be fundamental to that.
Do not look into laser with remaining eye.
I'll start adopting Swift as soon as it has an active community on most commercially interesting platforms. E.g. all UNIX derivatives, Windows, z/OS and Mac of course. When I have ample choice of programmers to hire. Not interested in technologies exclusively centered around one supplier.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
"Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms."
Not if you want to write something that compiles on other platforms. With Android/iOS being based on Linux/BSD it could very well make sense to write the back end of your app in C/C++ and only then branch into a different language as required by the GUI framework and other required proprietary APIs you'll be using.
Any study can be turned to favor whatever you want it to say.
Want to see real number check out http://langpop.com/
The funny thing is that in most every case C beats out C++, C#, and Swift (Which is so low it doesn't even show up.) So, I really have to wonder if your estimations really have any real world bearing. To make matters worse every single argument made for Swift by OP's linked article was made for Java, and C# once upon a time in fact every managed language seems to get that label until security experts beat it to death. (Also please note that security holes that are reported are often just a fraction of the actual security holes that exist. many are left unreported so that various companies can spy on each other and you while thinking they are the sole company with this ability. For many of these companies unpatched security holes are more valuable than 10lb gold bars.)
man, what are you smoking? ... Now, if you're going to argue C that was compiled with a C++ compiler,
You better pass some of that.... C++ compiled with a C compiler after going through a transformation, sure.
The cesspool just got a check and balance.
You know, if RoR was ever more than a splash in the history of time, maybe someone would have cared more about Rust. Somehow, being "rusty" just doesn't seem to go with hipster, geek, ninja, or rockstar.
The cesspool just got a check and balance.
FYI, I'm an iOS developer who uses a mix of languages, including Ob-C, every day. My coworkers and I met Swift with a mildly positive reaction - it's a decent, if imperfect, effort. It's not the second coming of Christ, but it definitely isn't a bad thing to try to modernize some of Ob-C's age-related shortcomings. The notion that we'd re-write code just to use it is utterly laughable, but we could certainly see ourselves using it to start a new app, or maybe at our next jobs.
The OP, though, sounds like a marketing intern wrote it. To add a little historical perspective: our apps are a riotous mix of C and C++ (for Android portability) and Ob-C. We chose to do it this way, within the last 3 years, so this is not a legacy issue. Both C++ and Ob-C were, at one time, meant as "replacements" for C, and we know how that turned out.
Swift may very well become the preferred language over Ob-C within, say, 5 years, for Apple-specific development. But the breathless "it'll replace C!" rhetoric is just silly. Over the coming decades, C will surely fade, but it will be replaced by other, newer, even more amazing tech, not just Swift.
So, mature, third-party, solid, stable, best-in-class, tried-and-true libraries that are the standard foolproof way to do "X" (choose from many "X"s) will all re-write themselves from C or C++ to Swift, and then keep themselves in sync with the mainline library, right?
C and C++ will continue to be used in iOS apps for the same reasons that so many (of the better...) Android apps color outside of the approved Java lines and use C/C++ using the NDK.
Speaking of C++... I'm currently learning Objective-C rather than Swift. Why? Because all I want is a thin interop layer between my cross-platform C++ code (the bulk of my game engine and game code) and the operating system APIs. Objective-C can iterop with C or C++ fairly easily, while Swift can only interop with Objective-C.
Frankly, I wish I could use Swift instead of Objective-C, whose syntax takes some real getting used to.
Irony: Agile development has too much intertia to be abandoned now.
And we know from experience that WHENEVER somebody uses terms like "language <XYZ> is the future", it is inevitably baseless speculation, and often rests on the false belief that some single programming language, or any single technology for that matter, can actually be the "best" one.
Brooks said it best, There is No Silver Bullet
File under 'M' for 'Manic ranting'
There's a shit load more "conventional programs" than there are operation systems
Java also solves your libraries and compile problem.
Last project I worked on the build server was Windows 2008, my dev PC was Windows 8.1 and test and production ran Linux. I don't even think prod was x86.
No cross-platform issues at all with ~ 100,000 lines of code.
Predictions are like assholes; everybody has one.
Table-ized A.I.
Swift can also interop with C, but it's ugly.
We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.
Wait, what? Swift is basically statistical noise at this point. "Dead" languages like ML and Pascal are higher in the tiobe index than swift is. It may become a force in the future but it's nowhere near that now.
I'm a minority race. Save your vitriol for white people.
Really? Everything I dug up during research said you pretty much had to interop with Objective-C, since Swift classes are exported as Objective-C classes. I'm not doubting you, as I'm sure there's some horribly ugly way to do it, given that we're talking about C here.
Still, for my purposes, it doesn't really matter that much. I'd still prefer a "clean" interop, since I'll be doing a lot of that.
Irony: Agile development has too much intertia to be abandoned now.
I just can't decide on which loosing horse I should all my money!
Jokes aside, anyone who knows a little bit about the history of Apple should be careful not to put too much efforts in one of their 'projects'. At least develop the core of your applications in C or C++ and use the proprietary technology just for GUI glue code. Unless we're talking about another fart app that requires zero know-how and programming effort anyway.
The NSA does not code in SWIFT, they go straight for barebone assembly because that is the only way to address the secret built-in backdoors in the baseband processor of all those devices...
I'm not sure how they're aggregating the data, but some of their source data is very surprising. Apparently Objective-C is the most popular language on GitHub projects, yet way down the list for projects tracked by Ohloh (which, as I recall, has been called OpenHub for a while now, so I don't know how old their data is). I'd have expected GitHub to be fairly representative of open source projects in general, though I wonder how good both the GitHub and Ohloh results are at deduplication - I have several copies of exactly the same code on GitHub...
I am TheRaven on Soylent News
Hello 1990. Great to meet you again! Fun times when search-engines were called Lycos, Yahoo and Astavista, and granted nothing beyond basic weighted keyword search. The time of MUDs, not MMORPGS, "social media" and distributed grid computing.
Fortunately, 25 years later the world moved on. While I applaud out-of-the-box thinking, you need to _first_ understand why companies ditched C and C++ from a value-based perspective. It's not that difficult: Java just don't provide a platform-agnostic runtime environment, but also pretty much the same development environment as well. If you do it correctly, you can be pretty sure what you've developed on is much the same as on production, at least in theory. This, even though the OS might be different! Sometimes it is, sometimes not. It's about the flexibility and the part where it "just works" (when you do it right).
Remember DLL-hell? Incompatible dynamic libraries conflicting with your application, 3rd party libraries and even sometimes the OS itself? Lots of "fun" there, but not if you depend on developers to bring value-add to your portfolio. Static libraries might also work, but Java versioning solves most of these problems, at least when it's gotten as far as production. Simply, there's been enough investment in creating good general-purpose Java-libraries for the common good, that it has out-competed most everything else in the Enterprise-world. Often for simply lack of robust and scalable alternatives.
Java has JEE, something that was sorely missing before Y2K. Now, you might argue it and its implementations has gotten fat, bloated and ugly over the years, but for Enterprise with lots of wads, it's _working_. One-off scripts and myriads of different programs doesn't work over the longer run (after years you learn this). There is a framework in place which makes deployment, scalability, monitoring, upgrade and support standardized, and not bastardized (requiring lots more folks and provides more flaws and re-work).
Java has gardbage collection, the JVM should never crash, should secure certain hardware-based security attacks, can do dynamic optimization using the JIT, the list goes on and on.
In 2015, C/C++ is great for OSes and unconventional programs requiring special access to the underlying hardware. For most everything else, there are simpler solutions and Java is the best for Enterprise.
Pro tip: What do you, or the business/organization, actually need? Do you really "need" C/C++, or is there some underlying value that is really required? :-)
When you've found the value, what's the lowest cost to provide this value?
Start to think business, instead of fancying technology.
Or just have fun! (But do remember that's what you're doing
Java has the theoretical interoperability feature between OSes and hardware platforms, but in practice there's a lot of customization to make programs actually do this, and if one has to write versions for several platforms, it's not a whole lot more burden to compile those and distribute binaries instead of Java runtimes.
Lol. You clearly never used Java. Our team develops large enterprise applications on Windows machines. All we have to do is export a WAR, deploy it on a Linux cluster running Tomcat/JBoss/Glassfish, and it works without further modifications.
According to the TIOBE Index [tiobe.com], Java has more usage than all three of them put together. I'd hardly call it a "minor player".
As with all language comparisons, this one vastly undercounts C and to a lesser extent C++. Embedded systems design is almost exclusively done in C or C++ (so much so that almost all embedded design toolchains support C / C++ only ). As a result, jobs that are available for embedded system designers all require C / C++, but never explicitly state that fact because either you know C / C++ or you dont know embedded systems design.
On a cycle by cycle basis, there are more lines of C code executed every second than all of the other languages put together.
To demonstrate: your PC has about a half dozen processors in it for handling all kinds of complex tasks like disk drive read head alignment, GPU, Even some higher end peripherals like fancy keyboards will have a processor in them. All of those peripheral processors (and I mean ALL) are running C code. Your car has another half dozen processors, all of which are running C code. Your Cell phone has another two or three processors, all of them except the CPU are running C code exclusively. Unless its a windows phone, the majority of the CPU time is spent executing C code.
I wish I had a good sig, but all the good ones are copyrighted
Pascal's not dead. Delphi targets every major hardware platform using Object Pascal and up to 64 bit code too.
In the tiobe list Pascal is listed separately from Delphi. Delphi is higher in ranking than pascal, which itself is higher in ranking than swift.
I'm a minority race. Save your vitriol for white people.
People keep bringing up the Swift in context of system programming, but so far I haven't seen any concrete info about features of the language which make it even suitable for the system programming.
The thing is, even C++ was/is used for system programming, but its C++-ness is so castrated that it is hardly can be called C++ anymore.
I personally do not see any reason to replace C with another language, which I can't use to its fullest. On top of it, lots of C extensions are needed to make the system development efficient: code/data section assignment, untyped/unchecked memory access, memory/IO barriers, assembler intrinsic. None of that is part of C standard - all of it are vendor/compiler extensions. While Swift documentation is devoid of the similar features.
P.S. If Apple folks want to push the Swift into the embedded area... Good luck. Even C++ still struggles. Higher-end embedded system require proof of validity and literally all of the solver software is C-only. Most static/dynamic code analyzers - C-only too.
All hope abandon ye who enter here.
We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.
..."Dead" languages like ML and Pascal...
Has Netcraft confirmed that?
Even when running Java you're executing more C++, because that's what the JVM is written in.
Since when does Java not suffer from DLL hell? Maven tries to mitigate this, but does so about as elegantly as RPM....
"We do not know what the language of the future will look like, but it will be called FORTRAN"
Heh. I keep forgetting that people use Python for web development.
Even setting asside that use, in scientific computing, you pretty much either use Python, Matlab, R, or FORTRAN, depending on the complexity of your non-equation needs.
Pascal was never alive in the first place.
I doubt we'll ever get away from language wars. Beyond touching on people's egos and world views, language wars are heavily linked to very real world concerns like industry direction, priority/visibility, and employability. They are a proxy for the anxiousness people have over their own professional futures.
Bah! Real programmers don't need fancy crap like assemblers! They program directly in machine language ;-)
Lets not forget microcode - which is pretty much needed to make assembly work.
The numbers a langpop.com may be "real", but they're also old - the page was last updated on October 2013. Swift's failure to show up isn't because it's "so low", it's because Swift wasn't unveiled until June of 2014.
Well don't forget to set the character encoding to UTF-8 on the JVM while in windows or else your URL parameters will only accept ANSI characters when using servlets. By default the JVM uses the system character encoding if you do not set it (which in windows is ISO something) so you either have to manually set the JVM to UTF-8 or configure your application to handle that.
That is just one thing that made my life annoying as a dev that needs to deploy to windows and linux. There are many more.
"The huge memory leaks that a programmer can have in Objective-C are impossible in Swift". He clearly hasn't actually worked with Automatic Reference Counting (ARC) environments. What this really means is that the Apple shills promoting Swift don't see the need to create tools for finding memory leaks while simultaneously making memory management a black-box operation that is hard for the engineer to debug.
You only have to look at Obj-C code snippets for trivial things like string concatenation to realise what a horrible experience it is. So it's no wonder that Swift is so popular given that it resembles more high level languages like Typescript, Ruby or Python. That said, it's still as proprietary as its predecessor. Nobody but OS X devs will want to touch it unless it becomes a cross platform tool.
Any study can be turned to favor whatever you want it to say. Want to see real number check out http://langpop.com/ The funny thing is that in most every case C beats out C++, C#, and Swift (Which is so low it doesn't even show up.)
Gee, could there be a reason for that? "Last data update: Fri Oct 25 17:17:19 -0400 2013" - Maybe that?
Of course news about a fake are Fake News.
Java has more usage than all three of them put together.
Might want to double check your spelling or your math there.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
The future favours cross-platform apps
Korma: Good
Blaise Pascal was alive from 19 June 1623 to 19 August 1662.
http://en.wikipedia.org/wiki/Blaise_Pascal/
Comment removed based on user account deletion
Swift....yeah. Never actually met anyone who programs in it as their primary language.
Well, considering it isn't even a year old yet, I'm not really that surprised.
Lets not forget microcode - which is pretty much needed to make assembly work.
Depends on the processor. Not all of them use Microcode. One example is the Motorola 6809. And I don't believe the 6502 is Microcoded, either.
Wait what? How long have I been away? Nobody told me that Go is a dominant language on Linux, or anywhere for that matter.
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
You can solve this by hosting your own maven repo and targeting specific versions for your dependencies instead of "anything newer than x".
Or you can move into the present and use Gradle instead. Or go back to ANT, or use GANT for a more pleasant experience... The list goes on forever.
Point is: Yes, Maven sucks. But we have better alternatives now. Find another reason to dislike Java.
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
The JVM is written in Java. As it is the javac compiler and every other tool bundled within the JDK.
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
My point is that the problem still exists in Java, and just like other languages there are solutions, but none are complete and all fail if not used.
We are now correcting the errors of the past.
Make way for "FOURTRAN".
Now with proper spelling.
If scripture has any bearing, time and chance happeneth to them all!
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
You forgot python
Leslie Satenstein Montreal Quebec Canada
I suppose it depends on what you want to do with it, and what you see Java's future as a wholly-owned subsidiary of Oracle is.
I was studying programming in college when the hype for Java began. We were using C and C++. What was true then still holds true today, in that in C/C++ you can write operating systems and conventional programs, but in Java you are limited to conventional programs. Java has the theoretical interoperability feature between OSes and hardware platforms, but in practice there's a lot of customization to make programs actually do this, and if one has to write versions for several platforms, it's not a whole lot more burden to compile those and distribute binaries instead of Java runtimes.
I second your opinion. When we had 1.44meg floppies, it was extremely important to have shared libraries. By now, 20 years later, we can have 8 terrabyte disks on our desktops, and 32gigs of ram. Yes, for shared system libraries (I/O, system calls, etc.) but statically bound libraries for the rest. If I upload a package and it is defective, I want to only remove that package, and retain the rest. I also want to isolate that package to certain directories. I suppose, that's what containers is about.
As for servers, I've always liked the mindset of putting as little as possible on the production server beyond what its job is. Hell, the idea of statically-compiling everything to allow one to eliminate libraries, let alone compilers on the production box, appeals in that if someone does break in there's a lot less they can do once on there. Java for server-side applications flies in the face of that, there are more general-purpose tools on the server rather than less.
I'm aware that I'm not in the majority for this stuff, and I didn't make programming my profession anyway so perhaps even I should be taken with a grain of salt, but it seems like in this speed to push features we've taken steps backward in real system security, and we're being bitten in the ass by it with ever increasing frequency. The very choice of programming language appears to be fundamental to that.
Leslie Satenstein Montreal Quebec Canada
Why would I learn objective-c (which I already learned and loath) or Swift, when I can code in C#.
Sure objective-C will be nice for a fast thin layer between a big game and the OS.
Many consumer apps already exists.
The big white space now is enterprise apps. You watch, C# is going to own the enterprise app market thanks to Visual Studio 2015, open source .NET, and Xamarin.