Slashdot Mirror
Apple's Swift 4.0 Includes A Compatibility Mode For 'The Majority' Of Swift 3.x Code (infoworld.com)
An anonymous reader quotes InfoWorld:
Swift 4.0 is now available. It's a major upgrade to Apple's Swift, the three-year old successor to the Objective-C language used for MacOS and iOS application development. The Swift 4 upgrade enhances the Swift Package Manager and provides new compatibility modes for developers. Apple said Swift 4 also makes Swift more stable and improves its standard library. Swift 4 is largely source-compatible with Swift 3 and ships as part of Apple's Xcode 9 IDE...
Swift 4's new compatibility modes could save you from having to modify code to be able to use the new version of the compiler. Two modes are supported, including the Swift 3.2 mode, which accepts most source files built with Swift 3.x compilers, and the Swift 4.0 mode, which includes Swift 4 and API changes. Apple said that some source migration will be needed for many projects, but the number of source changes are "quite modest" compared to many previous major changes between Swift releases.
Apple calls Swift 4.0 "a major language release" that also includes new language changes and updates that came through the Swift Evolution process.
Swift 4's new compatibility modes could save you from having to modify code to be able to use the new version of the compiler. Two modes are supported, including the Swift 3.2 mode, which accepts most source files built with Swift 3.x compilers, and the Swift 4.0 mode, which includes Swift 4 and API changes. Apple said that some source migration will be needed for many projects, but the number of source changes are "quite modest" compared to many previous major changes between Swift releases.
Apple calls Swift 4.0 "a major language release" that also includes new language changes and updates that came through the Swift Evolution process.
Don't you just love things that nearly always work?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Over the last 5 years there have been three main rising stars within the world of programming languages: Swift, Go and Rust.
This summary shows that Swift is doing great. The language is evolving, and it's being used to write a lot of great mobile apps and other software. Swift is clearly becoming a mature language that's usable for large, important projects. It has the backing of Apple, one of the most successful companies that has ever existed.
We're seeing the same thing happening with Go. Each release is bringing up some great new functionality, and some great software is being written using Go. It has the backing of Google, another major player in a variety of technology-oriented fields.
Then there's Rust. It was perhaps the most hyped of the three, getting a huge amount of attention despite being perhaps the least developer-friendly of the three. It took a long time to finally get to the 1.0 release, and once that happened it's like the language has fizzled out. There's not as much hype about it. Major projects written in it, including Servo and the Rust implementation itself, haven't really gone anywhere. It probably doesn't help that moz://a is involved with it, as some people see moz://a as a somewhat misguided organization these days.
Why have Swift and Go been such roaring successes, while Rust has been stagnating?
Is Rust too impractical of a language to use? Is Rust's community too focused on their Code of Conduct, rather than technological achievement? Is there just no reason to use a language like Rust when we have C++17, Swift and Go available to us?
Why haven't we seen Rust succeed where contemporary languages like Swift and Go have been wildly successful?
Says the Rubyist who can't comprehend Swift or Python.
Comprehend Python? I can't even see it!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
What benefit does Swift have over Modern C++ (C++14 & C++17)? Why should I choose Swift instead of Modern C++?
You know, ReactOS runs the majority of the Win32 programs. So, who's ditching Win10 and heading to ReactOS?! ;)
Anons need not reply. Questions end with a question mark.
This is why I jumped off the Apple treadmill and stopped using their proprietary languages (yeah, I know the languages are technically open, but for practical purposes the languages change at their whim). When I need to write for iPhone, the meat of the code gets written in C or C++, which is stable (and has the added benefit of being portable to Android or anywhere else).
For the code which I write in Apple's languages, I use a simple subset of the language, trying to avoid features that are likely to be changed in the future. It makes me sad because there are some nice features, but I don't want to use them because the pain of rewriting code (for no reason) is worse than the benefit I get from those features.
"First they came for the slanderers and i said nothing."
...there's way too much information to decode the Python. You get used to it, though. Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead. Hey uh, you want a drink?
#DeleteFacebook
Fact: Everyone on /. hates Rust and derides it at every opportunity.
I wouldn't say Swift or Go are wildly successful. C and C++ are wildly successful. Python, as much as I hate it, is wildly successful. Perl was wildly successful until they tried to completely start over with the abortion known as Perl 6. PHP and Javascript are wildly successful despite both being not that great (Javascript is downright terrible).
Swift and Go haven't even reached the market that Lua has and I wouldn't consider Lua wildly successful at all (Lua is awesome by the way). Both Swift and Go suffer from design and integration issues. I mean Go still uses statically linked binaries, the fuck!
Because Rust is backed by a dying company.
There are plenty of good niche languages like Elixir, but people only have so much free time. They want SDK support, they want a wealth of Stack Overflow support, they want upper management to say yes to it. This is why niche languages stay niche.
Rust is dead unless a major player backs it.
Claiming backwards compatibility is easy when your reference point was standardized 15 years after the creation of the language.
(Note: this metric still leaves Python3 as fair game.)
And the problem with statically linked binaries is...what exactly? Dynamic libraries served their purpose well when operating memory was expensive and compilers were simple enough. But now that RAM is cheap and compilers strive for interprocedural optimization, native dynamic libraries kind of seem to defeat the purpose of such optimizations across modules.
Ezekiel 23:20
It makes no sense to to keep a new language tied to features introduced at start, because you find slightly better ways or syntax to do what you were trying to do before - especially when you heavily factor in community feedback, as Swift does far better than almost any language I have seen (Java actually did a decent job of this earlier).
In practice Swift has been great to use - you have a large timeframe to migrate code to newer versions (hence the backwards compatibility mode), and so far even on very large projects (100-600 Swift files) conversion has been no more than a few days at worst (Swift 3 conversion was harder than most). The converter can help quite a lot automatically migrate over a number of things, but even if you do it all manually it's just a bit tedious and does not take that long to adapt syntax.
Swift is the first language I've seen that I think has a real shot at displacing C/C++, but that's a little while off... eventually it will reach the point of stability and mostly backwards compatibility you seek, but along the way they will have made the language as good as it possibly could be. I think it's really nice to gain a lot of experience now in a language that I think will pay off really well later, and in the meantime is something I really enjoy working in.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I have a whole bunch of apps, going back years (ObjC). I have also been programming Swift since announcements.
I don't need no steenkin' compatibility modes; mostly because I tend to keep in my lane, and don't use too may shiny "tricks."
It took about five minutes apiece for me to fully (and buglessly) convert all my apps. More than 40,000 lines of Swift.
Several of the apps have already passed App Review, and are in the wild.
However, all you Apple haters can have all the fun you want, slagging Apple. I've been hearing the same lame shit since the mid-'80s. You ain't exactly blazing a new trail, here.
This doesn't exactly sound like a stable platform to develop on if they can't even manage full backwards compatibility at compile time, never mind run time. Unix C programs I wrote back in the 90s I can still compile today on modern compilers - Swift will probably just be another language footnote in 20 years time but even if it isn't, I suspect the chances of being able to compile a program written in Swift 4.0 unchanged in 2037 I suspect will be near zero.
Seems like Apple is following MS in the rush to make changes for changes sake. "We need to do something to maintain momentum, this is something , lets do it!"
That's why most apps suck.
I don't hate Rust. I am completely indifferent to it, though.
#DeleteChrome
But we will keep looking. Soon with Apple's PR people I suppose...
Compiler errors, dude. Lots and lots of compiler errors.
Is this sort of like the whole community of Delphi Pascal users who have cut themselves of from whatever Embarcadero is selling and are still using Delphi 7?
Shake your head and wake up man, you're in the Apple bubble. Swift will never be used much on non-Apple platforms
I'm afraid it is you who seem to be very much asleep.
just like Objective-C before it
That is why I know I'm right on this, because I fully agree with you about ObjC - I could tell that was not going to be of use outside of Apple's platforms (though I liked working in it anyway).
But having done a wide range of programming in the past, from Java to C and C++ and Javascript and Lisp and various flavors of assembly, sometimes all server, sometimes all client, sometimes dedicated hardware... because of the broad range of past experience I have the ability to tell now when a language will be a good fit for a project. And Swift is a VERY good fit for both client and server work, and after some time, even low level work.
Swift is not just controlled by Apple, at all - it has a thriving community driving development, and not just from Apple devs at all. It's just a really good mix of ides from many different modern languages, with a very well thought out syntax and pragmatic approach to development.
But it's way more than that, it's one of the few languages (maybe the only one?) that really embraces what LLVM can do and takes full advantage of it...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Every new version of Swift shifts some things around slightly, mostly those changes result in error messages - usually clear enough the fix is obvious right away.
Also though, with each new release of Swift they add new compiler warnings, so usually you end up with a number of new warnings across your codebase. However these have generally been really helpful warnings, that were pointing out potential problems and really did require a fix. That has been a very useful component of each new version of Swift.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It's a completely non-Apple platform; in general Swift server side development has been advancing fairly well and is not just tied to IBM.
You truly cannot see the value of using Swift server-side, as well as on the client?
I wonder if you even knew that Swift has been running on Linux for quite some time now...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I write a lot of to the metal system code including drivers. What will this âoeModern programmerâ be using? Swift? Python? Please...
Could is not the same as will.
Security, dynamic libs allow distros to deliver new versions of libs like openssl whch have security fixes, staticaly linked libs make that very hard.
It also opens up ways to decrease security (by replacing a library module). In most other ways I think statically linked code is the best choice at this point given good infrastructure support.
But it isn't like a combination of static and dynamic linking isn't possible today, mix and match to suit the program under development. Or even ship the main code as pre-compiled code and link at installation time -> possible to replace with a new openssl library if needed. Or even better allow installation time static linking with optimization making the result as efficient as a globally optimized static linked code can be - however that's something not generally possible today.
If all you are doing is writing drivers or embedded stuff, then C will serve you fine. But be clear about the fact that your preference is suitable for your niche, and most people are not in that niche.
C is not a good general purpose programming language any more.
Uh, these aren't even arguments.
They are, I'm sorry you cannot see them, but to paraphrase an old saying, you can't lead a horse to think...
Plainly you are being obtuse, and cannot see the larger picture here. I'll let you have the last response so you can firmly cement your position in history for me to look back on and laugh ten years hence.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
> Most compilers will still compile K&R style C without a fuss
Most is not the same as all.