Gerucht: Google overweegt Swift te ondersteunen voor Android

Google, Facebook en Uber zouden overwegen Swift te gaan gebruiken. Google zou erover denken de door Apple ontwikkelde programmeertaal op lange termijn in te zetten, mede door de jarenlange strijd met Oracle over het gebruik van Java in Android.

Aanvankelijk zou Swift Java dan ook nog niet vervangen, heeft The Next Web van bronnen gehoord. Die bronnen spraken er wel van dat Swift een first-class-taal voor Android moet worden. Swift is ontwikkeld als alternatief voor Objective-C en vorig jaar opensource gemaakt door Apple. Uber en Lyft zouden volgens de site waarschijnlijk pas volgen als Google een besluit heeft genomen.

The Next Web tekent aan dat er veel moet gebeuren voordat Google Swift kan gebruiken voor Android. Api's en sdk's moeten compleet herschreven worden en er is een runtime nodig. Als gevolg van de strijd met Oracle is Google bij Android N al afgestapt van zijn implementatie van Java-libraries naar Oracles opensource OpenJDK. Overigens zou Google volgens het gerucht ook Kotlin nog niet afgeschoten hebben. Deze programmeertaal is makkelijker te implementeren voor Google, maar zou volgens het concern niet snel genoeg compilen.

Swift wint in rap tempo aan populariteit. Onder andere IBM maakt het mogelijk om met Swift applicaties voor clouddiensten te ontwikkelen en draaien.

Reacties (97)

[twilex]

Tja, op F# support van Google kan Android wat dat betreft nog lang wachten..
Het blijft triest dat Apple de naam Swift heeft gejat van een reeds bestaande Swift programmeertaal (die verder niets met Apple's Swift heeft te maken): http://dl.acm.org/citation.cfm?id=2286714

[dormamu]

Dit zou wel een klap in het gezicht zijn van Microsoft. Microsoft heeft tot op heden nog geen bridge voor Swift waardoor iOS apps omzetten naar UWP apps nog niet zo makkelijk is dan Microsoft probeert te doen overkomen

[BugBoy]

Dat Android de taal Swift gaat gebruiken zegt nog niets over de eenvoud van het porteren van een applicatie naar Android. De frameworks liggen zo ver uit elkaar dat het waarschijnlijk alsnog op een rewrite uitdraait. Alleen platform onafhankelijke code (bijv. algoritmes) zijn relatief eenvoudig te delen. Ontwikkelen is zoveel meer dan alleen een programmeertaal kennen. Kennis van het framework is minstens net zo belangrijk en duurt vaak een stuk langer om te doorgronden.

[Stoelpoot]

Zijn de meeste app frameworks zoals MVVM, MVP en MVC er niet op ontworpen om juist dit soort problemen te vergemakkelijken, door er interfaces tussen te plaatsen en de weergave los te koppelen van de data?

Uiteraard zou het functionele deel zoals het opslaan van instellingen en bestanden, de UI, en eventuele dialogen moeten worden herschreven, maar zaken als het ophalen en opslaan van data zou platform onafhankelijk moeten zijn (als de app zo is ontworpen).

[mathijs727]

Los van de ui zijn er ook nog stapels andere platform afhankelijke API's zoals storage access, camera access, gps, etc

[Stoelpoot]

Absoluut zeker. Dan nog wordt er bij de meeste frameworks geopperd om deze achter een interface te plaatsen zodat deze vervangen kan worden zonder andere classes erop te hoeven aanpassen. In de praktijk valt dit soms uiteraard tegen, maar vaak zal dat ook niet zo zijn.

[Relief2009]

Microsoft wil uiteindelijk geen bridges, maar C# als de taal neerzetten voor cross-platform ontwikkelen. Dit hebben ze al. Swift in Android gaat zeker nog een paar jaar duren. En dan heb je nog steeds alleen iOS en Android.

[NLxAROSA]

En OSX en Linux (via IBM). Windows platform volgt ongetwijfeld ook.

[twilex]

Ik zag op Github een versie van een Swift language compiler gebouwd in Haskell.
"Taylor is an early-stage, work-in-progress compiler for the Swift programming language. It is written in Haskell and uses LLVM for code generation."
Dat zou dan nu al op Windows moeten kunnen draaien.
Taylor: https://github.com/penberg/taylor

[Martinspire]

En hoe lang denk jij dat het duurt voordat dit (swift naar Android) gerealiseerd is? Tegen die tijd is dat van MS wel up&running.

[Reactie gewijzigd door Martinspire op 25 juli 2024 04:51]

[biteMark]

Aan de andere kant heeft Microsoft wel net Xamarin overgenomen en voor iedereen gratis beschikbaar gemaakt. Toegegeven, het heeft nog wat werk nodig maar het scheelt heel veel werk en is "native" te compilen voor elk ondersteund platform.

[johnbetonschaar]

Zou een uitstekende zet zijn van Google denk ik, vergeleken met Java is Swift In potentie een veel betere taal. Veel pragmatischer, moderner, waarschijnlijk sneller, geen GC nodig (groot voordeel op mobiele platforms), makkeljker porten van/naar iOS en last but zeker niet least is het een veel meer 'sexy' taal dan Java. Nu, en hoogst waarschijnlijk ook in de toekomst. Op die manier trek je meer developers aan die voor je platform willen ontwikkelen. Ik zelf zou bijvoorbeeld onder geen voorwaarde voor mijn lol voor Android gaan programmeren omdat ik Java gewoon een vreselijke, frustrerende, en vastgeroeste onhandige taal vindt, en ik ook niet door hoepeltjes wil springen om alles in bijvoorbeeld c++ te doen. Dus blijf ik bij iOS met objective-c, wat geenszins perfect is maar wat mij betreft een verademing vergeleken met Java. En dus in de toekomst wellicht Swift, als de taal wat gestabiliseerd is en (3.0 release bijvoorbeeld)

[Verwijderd]

Ik snap je laatste zin niet. Al mijn apps (9) zijn volledig in Swift geschreven en heb met Swift geen enkel instabiliteit gehad.

[johnbetonschaar]

Ik doelde niet op stabiliteit van je programma, dat het crasht ofzo, maar op stabiliteit van de taal zelf. Er wordt nog flink aan Swift gesleuteld dus bepaalde features en taalconstructies veranderen nogal eens, de taal is nog niet helemaal 'af' om het zo maar te zeggen. Alle iOS frameworks zijn ook nog gewoon Objective-C, en hoewel je daar natuurlijk gewoon tegenaan kunt programmeren zou het een stuk fijner zijn als die uiteindelijk ook allemaal overgaan op Swift (of C voor de low-level frameworks). Lijkt me een kwestie van tijd...

Ik wil zeker in de nabije toekomst met Swift aan de gang maar dan in de eerste instantie waarschijnlijk op Linux. Op iOS bevalt Objective-C nog prima, eerst moet Apple zelf maar helemaal over vind ik

[Verwijderd]

Ja maar dat wordt toch allemaal door Xcode zelf herschreven>?

Tenminste toen de println() veranderde naar print() om voorbeeld te noemen heeft Xcode dat bij mij allemaal zelf aan lopen passen.

Ik kreeg gister de melding dat de x++ verdwijnt. En dat al in Xcode zelf. Volgens mij heeft Apple dat best wel goed gedaan met Xcode.

[BikkelZ]

De Swift renamification staat nog op stapel voor versie 3, maar dat gaat gewoon met een automatische tool gebeuren aangezien je de zelfde functies aanroept met een andere naam. Ook genereert Xcode nu al warnings voor dingen die in 3 gaan veranderen dus dat is prima.

[AugmentoR]

de taal is nog niet helemaal 'af' om het zo maar te zeggen

Ja, dan kun je wachten tot het eruit ziet als Java. En zelfs dán is het nog niet 'af'

Maar goed, ben het met je eens hoor, Swift is niet perfect maar best goed te pruimen.

[Reactie gewijzigd door AugmentoR op 25 juli 2024 04:51]

[BikkelZ]

Er zijn een aantal mensen getraumatiseerd geraakt door het 1.x traject en alle wijzigingen tussen 1 en 2, maar ik werk ook exclusief met Swift 2 sinds de laatste betas van Xcode 7.0 vorig jaar en het was gewoon echt prima, af en toe wat lichte tweaks aan je code, altijd een verbetering.

[johnbetonschaar]

Maar hoeveel gaat er bij 3.0 weer veranderen . Wat ik zo lees best wel wat volgens mij...

Ben het er verder wel mee eens dat je gewoon al in Swift kunt programmeren hoor, en wat Granata al zegt doet XCode het meeste werk voor je (werkt net als bij de overgang naar ARC waarschijnlijk?). Maar ik vind het gewoon leuker om vanaf het begin de taal te leren zoals ie uiteindelijk bedoeld was, met de kinks eruit, zonder dat mijn code door tooltjes moet om het te laten compileren, of ik mezelf een of ander idioom aanleer dat in Swift 3.0 eigenlijk niet de beste oplossing meer is . Plus dat ik stiekem (call me crazy) best wel een Objective-C fan ben, en dus geen reden heb om dat nu al achter me te laten. Lekker C, C++ en Objective-C mixen, elk stuk in de meest geschikte taal, zonder bridges of wat dan ook

[BikkelZ]

De wijzigingen voor 3.0 zijn nu al warnings in 2.x. Dus tegen de tijd dat 3.0 uit is is mijn code al min of meer klaar. De enige grote wijziging is The Great Cocoa Renamification waar een hoop dingen in de iOS en OS X SDK's een meer Swift-achtige naam gaan krijgen. Aangezien het om de zelfde functies gaat maar dan met een andere naam krijg je daar een tool voor.

[Verwijderd]

Ja ik begreep johnbeton verkeerd. Maar ik heb die veranderingen juist heel snel opgepakt. Ben ook best wel benieuwd waarom mensen dit zn trauma vinden

[BikkelZ]

Je kunt ook nu al ontwikkelen in talen zoals Kotlin. De JVM is zeer flexibel. Maar native code is gewoon beter voor mobiel, geen GC is beter en Swift is natuurlijk sterk *ahem* geïnspireerd door Kotlin (en nog tien andere talen) dus een duidelijk voordeel heeft Kotlin ook niet.

Swift is al lang stabiel genoeg om gewoon mee te werken, alleen het 1.x en 1.x naar 2.x traject was gewoon slecht. Je werkt gewoon bij iedere Xcode versie een paar simpele warnings weg, meestal al geautomatiseerd vanuit de IDE.

[Reactie gewijzigd door BikkelZ op 25 juli 2024 04:51]

[Jeanpaul145]

Als dat je reden is om niet voor Android te ontwikkelen heb je niet eens een klein beetje moeite gedaan om te kijken naar productiegeschikte alternatieve talen voor het platform. Kijk bijvoorbeeld eens naar kotlin, ontwikkeld door JetBrains van IntelliJ faam, dat heeft net als alle andere JVM talen perfecte Java integratie (en werkt dus ook prima met de Android Java APIs).

[Verwijderd]

Hoe minder java hoe beter als je het mij vraagt. Swift vind ik alleen een vreemde keuze, ik zou dan eerder voor bv C# (.NET/Mono) gaan.

[Dennis Smurf]

Waarom niet hun eigen taal golang? Snel, klein en wordt steeds populairder, zie bijvoorbeeld docker.

[OrangeTux]

Hoewel Google Engineers beginnen zijn met Go heeft Google verder geen relatie met Go.

[Martinspire]

Mja ik vind het ook raar dat ze die negeren, want ik had juist het idee dat die populairder werd. Plus dat ze daar dan de volledige controle over kunnen pakken en niet alsnog afhankelijk zijn van anderen

[xoniq]

Swift heeft een wat lagere leer curve, en mensen die voorheen Objective C gebruiken die gaan sneller Swift gebruiken omdat dit door Xcode heel gemakkelijk wordt gemaakt om om te zetten, waardoor je de syntax heel vlot aan leert.

[Mugiwaraya]

Inderdaad. C# is VELE MALEN beter dan Java. Vroeger was dit andersom, maar tegenwoordig loopt Java achter op technologisch vooruitgang. Bijvoorbeeld; C# ondersteunt anonymous types, LINQ, operator overloading en dit is nog het topje van de ijsberg.

De introductie van Core.NET (cross platform) maakt het ook een sterke kandidaat voor successie van Java.

[Hielke Hoeve]

anonymous types -> eh? dit kan al jaren
LINQ -> streams anyone?
operator overloading -> dit is het enige wat ik ook mis

[PPie]

Swift vind ik alleen een vreemde keuze, ik zou dan eerder voor bv C# (.NET/Mono) gaan.

Eenvoudig. Swift is de nieuwe taal voor iOS.
En laat dat nu net een platform zijn met een enorm interessante App Store... En dat houdt in dat veel mobiele developers met Swift bezig zullen (gaan) zijn.

[Wolfos]

Maar dat regelt Microsoft zelf al (Mono is overgenomen en zit standaard met Android en iOS support in Visual Studio). Ik had liever gewoon C gezien voor de standaard API's, dat is veel makkelijker om naar te linken vanuit bijna iedere andere taal. Java is echt een slechte keuze geweest.

[Reactie gewijzigd door Wolfos op 25 juli 2024 04:51]

[JozyDaPozy]

Als Swift echt een first-class-taal zal worden voor Android dan is dit wel een revolutie! Programmeren in één taal voor de 2 grote platformen is een erg waardevolle ontwikkeling voor app-developers!

[KeesAlderlieste]

Dat kan nu al voor 4 platformen: C# op Android, iOS, WP en UWP (xamarin)
Dus zo revolutionair is dat niet..

[Reactie gewijzigd door KeesAlderlieste op 25 juli 2024 04:51]

[Verwijderd]

Dat is iets anders. Je hebt xamarin nodig om zo criss platform te programmeren. Als swift idd door Android zal worden ondersteunt dan kan je dus met iedere swift ondersteunende editor apps bouwen. Zonder tussenkomst van xamarin

[BugBoy]

Met de nieuwe CoreCLR en CoreFX is er voor .NET ook een volledig open-source alternatief. Zowel de IDE (VSCode), compiler (Roslyn) en de frameworks (CoreFX, ASP.NET MVC, Entity Framework, ...) is volledig open-source gegaan. Hiermee is het nu ook mogelijk om volledig native applicaties te bouwen, zodat je geen runtime meer nodig hebt. Ook is er een compiler die naar LLVM compileert (LLILC).

Je bent dus niet meer afhankelijk van Xamarin (dat tegenwoordig is overgenomen door Microsoft) en ook het Mono project zal denk ik langzaam overgaan naar CoreCLR. Het nadeel is dat het op dit moment allemaal nogal beta aanvoelt (ondanks dat het RC1 al heeft bereikt).

Het grote voordeel van C# vind ik dat het ook erg goed geschikt is voor de back-end. De taal Swift zal dat wellicht ook zijn, maar voor .NET is er veel meer server-side beschikbaar. Ook de async support in C# is sinds v4.5 redelijk goed geregeld. Dat vind ik een must voor schaalbare backends, maar ook aan de client is het erg welkom (vooral bij langdurige netwerk I/O). Bij Swift gaat het, bij mijn weten, vooral via Grand Central Dispatch, maar dat lijkt me net wat minder lekker werken.

Java lijkt wel een beetje een langzame dood te sterven. Er zal nog steeds ontzettend veel in ontwikkeld worden, maar ik heb het gevoel dat de taal over zijn hoogtepunt heen is. Ik ben benieuwd wat het gaat worden. Microsoft gaat sowieso erg de open-source kant op en krijgt een steeds grotere adoptie bij de meer Unix-aanhangers. Time will tell...

[Verwijderd]

Ik hou me totaal niet bezig met Windows of MS gerelateerde onderwerpen zoals ASP.net om heel eerlijk te zijn. En heb er weinig verstand van. Maar voordeel van de Swift taal is dat je het gewoon in je objective c of C taal kan schrijven zonder aanpassingen. dat is het hele punt van Swift juist.
En ik heb nog geen native C# bestanden gezien in bijv IOS of OSX applicaties. Daarom zou Swift als het cross platform is dus wel interessant zijn.

Nadeel van Java vind ik persoonlijk alle rompslomp van de taal zelf.

Je moet het verschil eens zien tussen een hello world op Java en op Swift. Swift maximaal 1 hele regel. Java 6 a 7 regels.
Nu is Hello World een slecht voorbeeld, maar je begrijpt mn punt wel denk ik.

[BugBoy]

Het punt van iOS applicaties is dat ze client-side only zijn. Daardoor is er relatief weinig server-side support in Swift beschikbaar (althans in de libraries die beschikbaar zijn voor Swift). Bij veel applicaties hoort al gauw een backend, website en apps. Swift is prima te gebruiken voor dat laatste, maar voor die andere twee is er nog maar weinig ondersteuning.

Een interop met C/C++ is leuk, maar vooral interessant tijdens de transitie fase waarin iOS zich nog steeds een beetje bevind. Op den duur zal het toch steeds meer Swift-only worden, waarbij alleen de onderkant tegen de Objective-C/C libraries aanpraat. Dat zie je ook in .NET. Als programmeur zie je eigenlijk de Win32 API niet meer.

Java is een erg nuttige taal geweest. Het was de eerste taal die zaken als garbage collection, intermediate language/bytecode, ... tot een succes wist te maken. Maar de evolutie van de taal ging erg traag vond ik en is ondertussen ingehaald door alternatieven.

Wat ik een erg onderschatte functie van een taal vind is de onderhoudbaarheid en refactorability van de taal. Een strikte taal, als C#, is daar erg sterk in. In tegenstelling tot bijvoorbeeld Javascript, die je vol moet stoppen met unit-tests, omdat het anders Russisch roulette is. Typescript vind ik dan ook een goede ontwikkeling. Sowieso ben ik fan van Anders Hejlsberg (al vanaf zijn Borland tijd). Die gast weet hoe je een taal moet opbouwen...

[Reactie gewijzigd door BugBoy op 25 juli 2024 04:51]

[84hannes]

Een strikte taal, als C#, is daar erg sterk in. In tegenstelling tot bijvoorbeeld Javascript, die je vol moet stoppen met unit-tests, omdat het anders Russisch roulette is.

offtopic:
Die ervaring heb ik ook. Ik vind spelen met Python leuk, maar als je een variabele van naam wilt veranderen dan durft de IDE wel wat te gokken, maar veel zekerheid heeft deze ook niet. Ik wil dat mijn compiler verteld of mijn class aan een interface voldoet, en niet zelf een unit test hoeven schrijven om dit te verifieren, of er middels een exception achter komen.

[KeesAlderlieste]

Het systeem is anders, maar JozyDaPozy vond programmeren in een taal voor twee platformen revolutionair. Nou, dat is het dus niet.

[Verwijderd]

Herbis wel degelijk gaaf hoor. Misschien niet revolutionair maar wel gaaf. Hij heeft wel degelijk gelijk dat je nu dus met 1 programmeertaal voor meerdere platformen kan programmeren. En dat zonder tussenkomt van een derde partij zoals xamarin. C# zal zinder xamarin op geen enkele manier werken op iOS of Android. En dat is juist het hele punt

[Earry]

Al van CoreCLR gehoord? Zie ook https://github.com/dotnet/coreCLR
Dat draait op windows, linux, mac, ... :-)

[Verwijderd]

Dus weer iets ertussen. Dat is mijn hele punt dus. Je hebt weer iets nodig om semi native c# te schrijven voor Android of OSX of linux.
Het hele idee van Swift opensource maken is dus dat je NATIVE Swift apps kan schrijven en kan compilen op bijv Android.

Dus dat je project uit .Swift files bestaat. En niet om moet worden geschreven door bijv Xamarin en dergelijke.

[Verwijderd]

Wat mis ik hier dan? Ik kan ook in C schrijven voor vrijwel alle OSen, maar dat is niet telkens dezelfde code. Zo zal dat met Swift ook zo zijn: code voor Android en code voor iOS. Dan is het dus inferieur aan een Xamarin waar je werkelijk een codebase hebt voor zelfs meer platformen.

Dus wat is het voordeel dat je een taal (Swift) kan gebruiken voor zowel iOS als Android? Waarom gebruikt niet iedereen dan C++ voor Linux en Windows bijvoorbeeld (is ook dezelfde taal)? Het is veel fijner dat je een keer iets maakt wat op alles hetzelfde werkt, dus CoreCLR/Xamarin/[vul in].

Trouwens, Microsoft heeft Xamarin overgenomen, dus je kan stellen dat het gewoon onderdeel is van het pakket, net zoals .NET/CoreCLR.

[Jeanpaul145]

Waarom gebruikt niet iedereen dan C++ voor Linux en Windows bijvoorbeeld (is ook dezelfde taal)?

Om een paar redenen:

• Het is notoir lastig om code te schrijven in C++ die echt cross-platform is. Vaker gebeurt het dat de programmeur dénkt dat de code cross-platform is, en dat anderen voor nare verrassingen komen wanneer ze de code proberen te porten. Er is een reden dat er nauwelijks grote FOSS projecten zijn die geschreven zijn in C++; de enige voorbeelden die ik nu zo snel kan bedenken zijn de browsers,en dat is wss alleen zo omdat er toen nog geen goede alternatieven waren (zoals Mozilla Rust of Swift)
• C++ is op vooral syntactisch niveau onnodig complex, wat komt door historische redenen gecombineerd met het feit dat C++ ontwikkeld wordt door een gesloten comité. Bijna elke taal waar dat zo is is heel lang in limbo blijven hangen qua development, en werden toen qua features ingehaald destijds door scripttalen zoals Python en Ruby.
  
  Een gevolg van de syntactische complexiteit bij C++ is dat compilen extreem lang duurt (vooral vergeleken bij bijvoorbeeld C, wat C++ zonder success probeerde te vervangen), hoewel ik dat een beetje moet nuanceren door te zeggen dat self-hosted C++ compilers extreem complexe beesten zijn; een functioneel equivalente compiler geschreven in bijvoorbeeld Haskell is er niets bij. Zulke complexiteit kan Compile times ook niet ten goede komen.
• Tegenwoordig moeten we voor software die niet low level is geen manual management willen. Mensen zijn er over het algemeen slecht in, hetgeen buffer overflows en andere security bugs niet alleen mogelijk maar zelfs extreem waarschijnlijk naarmate de grootte van het code base toeneemt. Onderschat het belang van security niet in een Programming Language: als die er geen support voor heeft kan en zal je security issues in de vorm van incorrect manual memory management introduceren in je code.
  
  De oplossing van een paar decennia geleden was Garbage Collection op runtime. Zoals verwacht introduceert dat nogal hoge penalties aan de performance van je code en dus zijn GC talen ongeschikt voor veeleisende (maar nog steeds geen low level) code. Maar Rust en ObjC en dus Swift doen het beter: Swift dmv reference counting (wat ook een runtime penalty heeft, maar een stuk kleiner dan GC) en Rust dmv checks op compile time die GARANDEREN dat je geen memory safety bugs introduceert. Dit heeft het voordeel van native performance + memory safety, zonder de runtime memory en CPU overhead van GC.
• Tegenwoordig hebben we betere alternatieve talen: Rust, Swift, Julia. Alle 3 compilen naar native code mbv een LLVM-based compiler tool chain (JIT compilation voor Julia en AOT voor Swift en Rust), en in elk geval Rust en Swift bieden naast een compiler ook build tools van t caliber gradle, waarmee je kan compilen, unit- en integration testen, docs genereren, en nog veel meer. Allemaal zonder gekloot met makefiles of CMake.

Ik kan eigenlijk niet anders dan concluderen dat greenfield projecten NIET in C++ geschreven dienen te worden anno 2016; de enige reden die écht te rechtvaardigen is is als je een ouder project aan t maintainen bent, en zelfs dan is het een goed idee om een kosten/batenanalyse te doen op het porten van de code base naar een moderne PL.

EDIT: informatie toegevoegd.

[Reactie gewijzigd door Jeanpaul145 op 25 juli 2024 04:51]

[The Zep Man]

Er is een reden dat er nauwelijks grote FOSS projecten zijn die geschreven zijn in C++; de enige voorbeelden die ik nu zo snel kan bedenken zijn de browsers,

Kodi is een ander voorbeeld.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 04:51]

[Superstoned]

Alles van KDE en Qt, waarbij Qt steeds populairder wordt - veel projecten zijn bezig van C en GTK naar C++ en Qt te porten, zoals wireshark. De auto industrie zet ook zwaar in op Qt. C# onder Linux - ik zie het niet, en er is gewoon veel weerstand tegen wegens de geschiedenis. Plus dat de UI kant van C# onder Linux GTK gebaseerd is en alleen een gek schrijft daar een nieuw project in...

Daarbij bied C# gewoon niets wat mensen nodig hebben en niet beter door andere talen wordt gedaan - inclusief Qt waarmee je ook voor win/mac/lin/android/iOS kunt schrijven.

[Verwijderd]

Dank voor deze uitgebreide informatie, ik haf het zelf niet beter kunnen verwoorden! Echter ga je helemaal los enkel op C++, waar dat in mijn geval enkel een voorbeeld is, want het had ook C of Assembly kunnen zijn.

Ik zie nog steeds het voordeel van een nieuwe taal niet als enkel "cross platform" aangehaald wordt, want in principe is elke taal "cross platform", alleen moet er een compiler zijn voor dat betreffende platform. Dat men direct dergelijke compilers maakt is een geheel ander verhaal.

Daarbij zal de codebase hoogst waarschijnlijk anders zijn voor ieder platform, want anders zit er een laag tussen waar CoreCLR juist op afgeschoten wordt! Het enige argument dat ik nog voorbij heb zien komen om geen CoreCLR te gebruiken is het gebruik van GTK, maar wie zegt dat Swift niet ook een dergelijke "beperking" heeft? Daarbij zou je C# ook gewoon native kunnen compilen: gebruik gewoon geen .NET.

Het gaat hier dus volledig om emotie en niet om rationeel denken, althans zo voelt dat voor mij aan. Wellicht mis ik informatie waarom je absoluut geen ".NET-taal" op bijvoorbeeld Linux zou willen.

[Jeanpaul145]

C is inderdaad ook een taal die vatbaar is voor manual memory management bugs en ze worden daarin zeker ook gemaakt. En hoewel C op het punt staat overbodig te worden naarmate met name Rust volwassener wordt is het nog niet zo ver: je kan nog niet helemaal in enkel Rust een OS schrijven bijvoorbeeld. Dit vereist een aantal dingen die buiten de scope van onze discussie zijn; het punt is dat er voor C nog geldige use cases te bedenken zijn, al krimpt die lijst sterk. Ook is C in tegenstelling tot C++ nog steeds een simpele taal: het is anno 2016 nog steeds mogelijk om alle regels van de taal tegelijk in je hoofd te houden.

Assembly heb ik niet genoemd omdat ik me niet kan inbeelden dat buiten kernel developers überhaupt nog mensen zijn die in ASM werken voor serieuze software (itt. een hobbyprojectje oid).

[BonzO]

Ze gaan ook native compilatie ondersteunen, echter is coreclr/dotnet cli nog steeds in ontwikkeling, dus nog niet perfect. Zie ook een post van Scott Hanselman.

[Robby517]

CoreCLR is net zo veel "iets ertussen" als de huidige runtimes die meegeleverd worden of als Alphabet straks een runtime voor Swift meelevert.

[sjongenelen]

Is dat niet het enige voordeel van java? Ja het is cross platform

Maar ik snap je. Met c# en Roslyn is het meer cross platform compileren.
Iets wat beter is dan alleen twee platformen bereiken met eenzelfde programmeertaal, waar Xamarin (nu Microsoft) dus echt wel voordelen heeft

[twilex]

En je hebt behalve de taal Swift geen runtime omgeving nodig, geen iOS of OSX platform specifieke API's?

[xoniq]

Swift heeft een iets minder stijlen leer curve dan C#.

[Martinspire]

Wat denk je van HTML, CSS en Javascript voor alle denkbare platformen? En dan heb ik het niet zozeer over websites, maar wel dat je er nu ook gewoon apps mee kunt maken.

Beetje offtopic, maar een populair framework genaamd Ionic heeft sinds kort ook Windows 10 ondersteuning, waardoor je daar nu ook eindelijk de grote 3 mee kunt ondersteunen.

[BugBoy]

Het probleem van Javascript is dat ik het niet erg geschikt vind om er grote applicaties mee te bouwen. Het kan wel, maar qua onderhoudbaarheid is een meer gestructureerde en strikte taal toch prettiger. Met Typescript wordt het al wat beter, maar talen als Swift, C# zijn toch wat prettiger op dat gebied. Ook de performance van die talen is vaak net een tandje beter, waardoor het meer native aanvoelt.

[Coolstart]

De bestaansreden voor Ionic is een puur financieel omdat uw app in een soort browser draait en al interne en externe api's aangepast kunnen worden aan het smartphone OS. Zonder veel kosten kan je dus voor meerdere platformen een App bouwen. De keerzijde van de medaille is dat de app niet snappy werkt.

Ik was zelf betrokken bij een Swift App op Ios en die app is waanzinnig snel, zelfs op oudere Iphones is er geen delay te bespeuren in de user interface. Dit in tegenstelling tot cross platform apps zoals Airbnb die duidelijk trager reageren op uw vinger.

Swift is performanter en kan ook als backend gebruikt worden. Als zowel Server side als Client side (app) Swift gebruikt kan het niet anders dat je met een klein team Swifters bergen werk kan verzetten omdat het hele team allemaal dezelfde core competence heeft. Api's en clients worden op één lijn.

Android zal niet vandaag op morgen naar swift migreren, daarvoor is hun platform al te groot geworden, maar om te vermijden dat ze zich ooit uit de markt prijzen door ouderwetse partners moeten ze imo wel een andere koers varen.

Swift is open source, even goed als C++, beter dan objective C, snel te leren, makkelijker leesbaar, server side + client side. Alles wijst er momenteel op dat swift de toekomst is en stilletjes zal groeien, ook omdat jonge ontwikkelaars graag starten met een modern alternatief t.o.v. de gevestigde waarde.

Google’s onboarding for Swift would be long; it essentially has to rewrite every Android service, app and API. Google would also have to spearhead Swift support for Android — which is still only being poked and prodded at by clever developers in the Swift community.

In a way, Google has already begun moving away from bits of Oracle-flavored Java. It’s now using the Open JDK for Android rather than the proprietary Java API, and may be considering a post-Java life altogether. Talks in London were said to be exploratory; Google is not yet pushing to move on from Java. While it would be a big undertaking, Swift is meant for speed and safety, and Swift’s roadmap suggests it won’t be quite as difficult to use it for other platforms in the future, specifically when it comes to C++. http://thenextweb.com/dd/...facebook-uber-swift/#gref

[Reactie gewijzigd door Coolstart op 25 juli 2024 04:51]

[alienfruit]

Ik code anders al in Swift voor iOS, Android, Windows en Linux

[Verwijderd]

Van alle tech bedrijven waar ik mee te maken heb, direct danwel indirect, is Oracle wel het meest misselijkmakende bedrijf ooit. Alles wat ze aanraken, vernielen ze en reduceren ze tot een uitmelkstrategie via de juridische weg.

[Martinspire]

En toch bestaan ze anno 2016 nog steeds en zijn ze nog steeds gezond. Met een omzet van 10 miljard en een net income van 2,8 miljard doen ze het niet verkeerd. Kortom: die zijn we voorlopig nog niet kwijt. En ook al gaat Google/Android weg, dan zal dat nog niet helpen.

[Verwijderd]

Helaas waar, onethisch zakendoen kan zeer lucratief zijn.

[Verwijderd]

Ja, helemaal mee eens. Ik heb er dagelijks (gelukkig steeds minder) mee te maken, en het altijd gedoe. Stelselmatig proberen over het randje van de contracten te gaan, incorrecte invoices sturen. Dat soort dingen. Uiteindelijk komt het weer goed, maar het is heel frustrerend om iedere keer weer de bedrijfsjurist erbij te moeten halen als je gewoon je werk wilt doen.

[BugBoy]

Het is bijna knap hoe snel ze alle zaken die ze van Sun hebben overgenomen de nek hebben omgedraaid. Gelukkig blijft VirtualBox voorlopig nog steeds buiten schot.

Helaas heeft het voor Apple gebruikers ook gevolgen gehad. Apple was druk bezig met ZFS, maar toen dat in handen van Oracle kwam hebben ze hun handen eraf getrokken. Officieel is er nooit iets over bekend gemaakt, maar het verhaal gaat dat er toen licentietechnisch een probleem ontstond.

[LaTiNo156]

En hun producten zijn ruk. De db is wel krachtig, maar hun ontwikkeltools en webapplicaties zijn afgrijselijk.

[- peter -]

Zou liever hebben dat ze C# overwegen. Lijkt me ook nogal een nadeel dat Swift geen C++ kan bridgen.

[StefanJanssen]

C# is van Microsoft, Google doet echt alles om Microsoft neer te halen. Het 'per ongeluk' blokkeren van youtube op de browser van windows phones bijvoorbeeld. Gelukkig had MS binnen 2 weken de browser agent aangepast naar die van de mobiele versie van chrome...

Ik heb zelf ook liever C# dan Swift.

[BikkelZ]

Swift is beter dan C# naar mijn mening. Betere handling van null-pointers. Hele mooie enums. Heb met beiden veel gewerkt, met C# vooral. Jammer dat F# wat weinig liefde krijgt van Microsoft zelf. Krachtige taal maar wat een achteruitgang qua IDE support ten opzicht van C#

[Reactie gewijzigd door BikkelZ op 25 juli 2024 04:51]

[BikkelZ]

Je propt al je C/C++/Objective-C/Objective-C++ references in je Bridging-Header.h file. Vervolgens wordt er door de LLVM gewoon één binary van gemaakt. Dat is zelfs beter dan dan wat je in C# krijgt.

[Reactie gewijzigd door BikkelZ op 25 juli 2024 04:51]

[Azerox]

Heerlijk!

[Martinspire]

Waarom niet beiden? Als ze toch bezig zijn, lijkt het me dat ze toch een bepaalde inventarisatie moeten doen die ook andere talen mogelijk maken. Ik zie het eigenlijk wel gebeuren, en dat zou het erg interessant maken wie wat gaat gebruiken.

[johnkeates]

Liever Swift dan C#... Niet dat C# is of .NET niks kan, maar na een project in C# is het toch altijd wel een verademing om iets als Swift op te pakken.

[Qws]

Slecht nieuws voor Microsoft en C#/VB. Tenzij Microsoft natuurlijk ook Swift gaat ondersteunen voor .NET

[Lethalis]

Waarom Swift voor .NET?

Doe gewoon native Swift voor Windows.

Toch zonde om er weer een hele runtime tussen te plaatsen als dat niet nodig is. WinRT (sinds Windows 8 ) is een objectgeoriënteerde API voor Windows in C++ die door velen destijds als de dood van .NET werd gezien.

Guess what, it's alive and kicking in Windows 10. Zorg dat Swift ermee kan praten en je hebt geen .NET meer nodig.

Bovendien is Microsoft al een heel eind met Linux ELF binaries draaien op Windows. Dus die route kunnen ze ook nog kiezen als ze geen zin hebben in een volledige port van Swift. Dan hoeft alleen Visual Studio de ontwikkeling ervan te ondersteunen en voor de rest zijn het gewoon de Linux binaries.

[Reactie gewijzigd door Lethalis op 25 juli 2024 04:51]

[xoniq]

Ach als Microsoft dan ook even Swift gaat ondersteunen zullen een hoop ontwikkelaars hier blij mee zijn.

[Lethalis]

Echt heel gaaf als het zo is.

Het zou voor mij wel een goede reden zijn om de taal te gaan leren Ik zag daar tot nu toe geen reden voor en sinds Xamarin gratis is geworden, overweeg ik alles in C# te doen.

Dit zou die beslissing nog weleens kunnen doen veranderen.

En Microsoft, tsja.. Swift is open source. Dus die zullen wel reageren en Swift gaan ondersteunen. Ze moeten wel.

Het mooie daarvan zou zijn dat je straks alles met Swift kunt doen

[Reactie gewijzigd door Lethalis op 25 juli 2024 04:51]

[KeesAlderlieste]

.NET is ook opensource.. https://github.com/Microsoft/dotnet

[Lethalis]

I know, ik ben een .NET developer die het nieuws behoorlijk volgt

Ik lees de blogs van Scott Hanselman en zijn baas, Scott Guthrie. Ik heb de BUILD conference gevolgd. Ik weet zelfs welke libraries in CoreFX zitten en welke (nog) niet.

De reden dat ik meld dat Swift open source is, is dat het beschikken over de broncode het eenvoudiger maakt voor Microsoft om het te gaan ondersteunen.

Microsoft is allang niet meer .NET only. Met Windows 8 hadden ze de "go native" beweging die de nadruk op modern C++ programmeren legt. En sinds Visual Studio 2015 kun je gewoon out of the box met Python programmeren.

C# en .NET wordt ondersteund door ze, maar het is niet zoals vroeger "the one and only Microsoft way".

[Reactie gewijzigd door Lethalis op 25 juli 2024 04:51]

[Verwijderd]

Ik lees de blogs van Scott Hanselman en zijn baas, Scott Guthrie.

Kleine side node: Sinds begin dit jaar is ASP.NET weggehaald bij webtooling, Azure, etc. Het is ondergebracht bij het .NET team. Scott Hunter is de baas van asp.net en nu van het gehele .net. "The Guh" heeft niks meer met ASP.NET te maken.
Bron: https://channel9.msdn.com/Events/Build/2016/B891

[Reactie gewijzigd door Verwijderd op 25 juli 2024 04:51]

[Verwijderd]

Ms kennende komen ze eerder met een swift tegenhanger

[Lethalis]

Het Microsoft van nu is heel anders dan 10 jaar geleden.

Ze zien inmiddels in dat het ze alleen maar geld zou kosten, terwijl ze anderzijds ook gewoon open source kunnen steunen voor een fractie van het geld en daarmee bovendien ook nog eens hun image kunnen verbeteren.

[xoniq]

Zou super zijn. Vind Swift heel fijn om in te programmeren.