34 ms·

It might be useful to look at Microsoft and their history with C#. C# was announced in 2000, the first really useful version C# 2.0 came out in 2005 and even to

by npalli 11y ago

It might be useful to look at Microsoft and their history with C#. C# was announced in 2000, the first really useful version C# 2.0 came out in 2005 and even today Microsoft apps written in pure C# are few and far in between (just UIs for visual studio, sql server etc.). So, I wouldn't be surprised if the Apple to transition to Swift doesn't happen for five years or more. There is absolutely no point for Microsoft or Apple to use C# or Swift when 95% of their legacy code is another language like C/C++/Objective-C. These guys have so much money they can pay people to hyper specialize in old technologies, I'm sure MS has some guys who work exclusively in COM/C++ or Apple with some guys who work exclusively in C89/BSD. Having said that, pretty much everyone developing for the Microsoft ecosystem (native) uses C#. That has been true for almost a decade now. I suspect the same will happen with Swift and Apple and rather rapidly because the Apple ecosystem doesn't have enterprise customers holding it back. Most of people commenting here seem to already know Objective-C. However, consider someone new to the platform. Would you spend 1 year learning iOS programming using Obj-C or learn it via Swift? Apart from Swift being a nicer language to learn, the reality is almost all tutorials/books etc have shifted to Swift. Good luck to the poor sap learning iOS programming via iOS 6 tutorials and Obj-C and migrating to iOS 9. I think the Swift 1.0 to 2.0 journey was quite painful, pretty surprised that Apple made so many breaking changes with poor tools support, but I feel 2.0 is where it feels just about solid to build all new apps. Sure there will be changes, I mean Obj-C had ARC and blocks twenty years later! but that's the nature of software nowadays.

rikkus 11y ago
I'd like to know how much .NET code is in Microsoft's products now. I would have expected plenty in Office, Windows 10 and Edge, but I don't know how to actually check.
- kevin_thibedeau 11y ago
  > Dumpbin /clrheader <binary file> This will report the .NET runtime version for any CLR binary.
kensai 11y ago
Until there is some stabilization of the language and its main libraries/ABI (coming in v3.0 or so), I don't think the language can really take off. The changes can possibly break it, is it really worth it to invest in something that next year will change breaking your code? From Swift v3 on we should start seeing things going!
- webjprgm 11y ago
  They provide tools to port. So I think it depends more on how large your app is. For a small app running the tool and making a few misc fixes will probably be fairly easy. At least if it is like the 1.0 -> 2.0 change. For larger apps, well, I have a Swift app that isn't really very big, probably still small but significantly bigger than a tutorial, and it keeps freezing Xcode. (Edit something in Interface Builder, switch to the ViewController class with IBOutlets in it, then switch back and forth between ViewControllers making edits. Each time it takes longer and longer until I just force-quit Xcode to avoid twiddling my thumbs for 5 minutes.) So I don't think Swift is ready for any app that isn't pretty small anyway.
pmilot 11y ago
I think the difference here is that C# (and the .NET platform) was never meant to completely replace C/C++ Win32 development; it was a higher-level solution for a certain class of Windows applications. I might be wrong, but I thought Swift was designed as an eventual replacement for Objective-C (with its seamless interoperability, and the fact that it uses the same runtime as Objective-C, it doesn't seem that far-fetched). If it is meant to be Objective-C's successor, then Apple should really be preaching by example at this point.
- TazeTSchnitzel 11y ago
  > I think the difference here is that C# (and the .NET platform) was never meant to completely replace C/C++ Win32 development Oh no, it was meant to replace them. Win32 was going to be deprecated, all new stuff would be on native .NET APIs, there'd be a Windows Presentation Foundation and a Windows Filesystem and it'd all be great. The thing is that Longhorn fell apart, and with it the dream of replacing Win32 died forever. Now we have WinRT, but unlike the plans for Longhorn, WinRT actually sits on top of Win32.
  - pmilot 11y ago
    Right! Longhorn; totally forgot about that and WinFS. Talk about a failed endeavour... WinRT however is definitely not a replacement for Win32. It's way too sandboxy (last time I checked, you couldn't even pull up a list of fonts installed on the host system using the WinRT APIs only).
jameshart 11y ago
Most of the new software MS has been developing over the past few years - the Azure platform, office 365, etc. - is server side. I suspect a significant quantity of that code is managed.

by npalli 11y ago

rikkus 11y ago

I'd like to know how much .NET code is in Microsoft's products now. I would have expected plenty in Office, Windows 10 and Edge, but I don't know how to actually check.

kevin_thibedeau 11y ago
> Dumpbin /clrheader <binary file> This will report the .NET runtime version for any CLR binary.

kensai 11y ago

Until there is some stabilization of the language and its main libraries/ABI (coming in v3.0 or so), I don't think the language can really take off. The changes can possibly break it, is it really worth it to invest in something that next year will change breaking your code? From Swift v3 on we should start seeing things going!

webjprgm 11y ago
They provide tools to port. So I think it depends more on how large your app is. For a small app running the tool and making a few misc fixes will probably be fairly easy. At least if it is like the 1.0 -> 2.0 change. For larger apps, well, I have a Swift app that isn't really very big, probably still small but significantly bigger than a tutorial, and it keeps freezing Xcode. (Edit something in Interface Builder, switch to the ViewController class with IBOutlets in it, then switch back and forth between ViewControllers making edits. Each time it takes longer and longer until I just force-quit Xcode to avoid twiddling my thumbs for 5 minutes.) So I don't think Swift is ready for any app that isn't pretty small anyway.

pmilot 11y ago

I think the difference here is that C# (and the .NET platform) was never meant to completely replace C/C++ Win32 development; it was a higher-level solution for a certain class of Windows applications. I might be wrong, but I thought Swift was designed as an eventual replacement for Objective-C (with its seamless interoperability, and the fact that it uses the same runtime as Objective-C, it doesn't seem that far-fetched). If it is meant to be Objective-C's successor, then Apple should really be preaching by example at this point.

TazeTSchnitzel 11y ago
> I think the difference here is that C# (and the .NET platform) was never meant to completely replace C/C++ Win32 development Oh no, it was meant to replace them. Win32 was going to be deprecated, all new stuff would be on native .NET APIs, there'd be a Windows Presentation Foundation and a Windows Filesystem and it'd all be great. The thing is that Longhorn fell apart, and with it the dream of replacing Win32 died forever. Now we have WinRT, but unlike the plans for Longhorn, WinRT actually sits on top of Win32.
- pmilot 11y ago
  Right! Longhorn; totally forgot about that and WinFS. Talk about a failed endeavour... WinRT however is definitely not a replacement for Win32. It's way too sandboxy (last time I checked, you couldn't even pull up a list of fonts installed on the host system using the WinRT APIs only).

jameshart 11y ago

Most of the new software MS has been developing over the past few years - the Azure platform, office 365, etc. - is server side. I suspect a significant quantity of that code is managed.