Apple brengt Swift 5.5 met concurrencyverbeteringen uit

Apple heeft versie 5.5 van Swift uitgebracht. Bij deze laatste versie van de open-sourceprogrammeertaal heeft het bedrijf een groot aantal wijzigingen en verbeteringen doorgevoerd, waaronder op het gebied van concurrency.

Het Swift Core Team van Apple noemt Swift 5.5 zelf een massive release en de ontwikkelaars lichten onder andere de concurrency-eigenschappen zoals async/await uit. Andere verbeteringen betreffen concurrency-interoperabiliteit met Apples oudere programmeertaal Objective-C en structured concurrency. De concurrencyprogrammeerstijl werd als eerste geïntroduceerd in C# en later geïmplementeerd in onder andere Python en JavaScript. Het betreft een mechanisme om efficiënte asynchrone code te schrijven.

Chris Lattner, de van oorsprong drijvende kracht achter het Swift-project, stelde al in 2017 de problemen bij de omgang met asynchrone api's bij de programmeertaal aan de kaart, in zijn Swift Concurrency Manifesto. Hij sprak onder andere van een pyramid of doom om de problemen die ontstaan bij veel asynchrone afhandelingen, te omschrijven.

Nieuw in Swift 5.5 is verder de ondersteuning van package collections voor de Swift Package Manager. De collecties bestaan uit bestanden met Swift-broncode en een manifest. De bedoeling is dat er een gecureerde lijst van collecties komt, die het gebruikers makkelijker maakt bestaande packages voor bepaalde gebruikersscenario's te ontdekken.

Apple kondigde de komst van Swift 5.5 in juni aan tijdens zijn virtuele WWDC-evenement. Het bedrijf introduceerde Swift in 2014 als opvolger van Objective-C voor het programmeren van apps voor zijn besturingssystemen.

Reacties (60)

[Carbon]

Een paar aanvullingen

1. Actors zijn een onderdeel van de taal
2. async/await en Actors zijn alleen te gebruiken onder iOS15, macOS12!
Er wordt op dit moment gewerkt aan het backporten van de benodigde runtime wijzigingen
Zie: https://forums.swift.org/...ncy-back-deployment/51908


Hier een overzicht met voorbeelden van wat er is gewijzigd in Swift 5.5
https://www.hackingwithsw...33/whats-new-in-swift-5-5

[Reactie gewijzigd door Carbon op 24 juli 2024 01:26]

[Bigs]

Die Actor implementatie is zo te zien heel makkelijk te implementeren. Alleen kan ik nergens terug vinden er ook zaken als pools en supervisors zijn geïmplementeerd die je in andere Actor omgevingen (zoals Akka en, OTP) wel tegen komt. Daarmee lijkt het weer een beetje in de kinderschoenen te staan, of het onderstreept hoe Swift puur en alleen richt op client-side development waar dat soort zaken niet nodig zijn.

[Snowfall]

of het onderstreept hoe Swift puur en alleen richt op client-side development waar dat soort zaken niet nodig zijn

Swift wordt ook voor serverside toepassingen gebruikt zoals Vapor en voorheen kitura. ING gebruikt voor gedeeltes van hun backend ook server side swift.

https://www.nodesagency.com/going-to-serverside-swift-2018/

Gebruik swift zelf ook sinds 2017 als taal voor t schrijven van restapis. Heb ook paar grote klanten waar hun gehele backend van bijvoorbeeld nodejs of php is overgestapt naar Vapor .

[supersnathan94]

Heb ook paar grote klanten waar hun gehele backend van bijvoorbeeld nodejs of php is overgestapt naar Vapor

Van generieke talen waar je heel makkelijk devs voor kunt vinden naar een taal die er eigenlijk niet voor bedoeld is en die niet heel veel mensen goed kunnen (in verhouding tot die andere twee). Hoe heeft dit zich uitgepakt?

[Snowfall]

Opzich heel goed omdat ze geen backend teams meer hebben en ik als hun freelance iOS Developer zowel hun iOS projecten als backend projecten onderhoud. Mag binnenkort een nieuw lahmest api gaan bouwen in Vapor voor 1 van mijn Klanten.

En vooral besparingen op kosten bij cloud Providers zoals Google cloud. Zowel systeem gebruik als kosten besparen ze rond de 30 procent. Dit komt vooral omdat swift heel zuinig met ram en processing power omgaat . (Mits goed geprogrammeerd natuurlijk)

Is verder ook beetje mijn hele business model tegenwoordig. iOS en backend applicaties in 1 pakket. Heb nu ook 4 extra mensen op payroll om werk een beetje bij te houden.

[Reactie gewijzigd door Snowfall op 24 juli 2024 01:26]

[BikkelZ]

Ik ben persoonlijk wel redelijk makkelijk in het omschakelen van programmeertalen, ook omdat ik met name relatief meer moeite heb met het leren van nieuwe frameworks als die niet echt al een bekende filosofie hebben. Dus in mijn geval vanwege mijn achtergrond zou ASP.net MVC met C# of F# makkelijker zijn dan Vapor met Swift. Maar goed je kunt met alles wel binnen een paar weken een back-endje bouwen, maar vaak heb je pas echt degelijke code nadat je 2-3 projecten gedaan hebt.

[Reactie gewijzigd door BikkelZ op 24 juli 2024 01:26]

[Snowfall]

Vapor is eigenlijk heel logisch. Als je C# of F# kent dan is swift en Vapor zeker een eitje. Ik kwam zelf van objective c af toen ik met swift begon. Backend wise php. Maar Vapor is voor mij persoonlijk echt een verademing.

Ik gebruik zelf voor Vapor MVVM of VIPER en soms eigen VIPER implementatie.

[pclin]

'Opzich heel goed omdat ze geen backend teams meer hebben' is een beetje eenzijdig. Bij veel bedrijven heb ik juist het omgekeerde gezien. Het is eigenlijk zo dat ze geen backend/frontend teams meer hebben, maar feature teams die alle beide doen. En dus 1 taal wel handiger is. Veel backend developers zijn de afgelopen jaren omgeschakeld naar frontend, omdat het daar vaak dynamischer is en ook sneller feedback van gebruikers komt. Dus je zou ook kunnen stellen dat er geen pure frontend teams meer zijn.

[Carbon]

Van generieke talen waar je heel makkelijk devs voor kunt vinden

NodeJS is Javascript met een eventdriven runtime.
maw vergelijkbaar met het aangehaalde Vapor, het enige verschil is de gebruikte programmeertaal

waar je heel makkelijk devs voor kunt vinden

Een Javascript/Typescript developer is niet automatisch een NodeJS developer!
Veel belangrijker is de ervaring met NodeJS als platform.

naar een taal die er eigenlijk niet voor bedoeld is

Als er één taal is die niet ontwikkeld is voor server toepassingen dan is dat wel Javascript

[Reactie gewijzigd door Carbon op 24 juli 2024 01:26]

[supersnathan94]

Ja en nu laat je dus PHP kompleet links liggen. Een taal die wel degelijk bedoelt is als serverside taal.

NodeJS valt wel meer hoe erg dat een specifiek platform is. Overigens denk ik dat iedere frontender wel degelijk ervaring heeft met NodeJS ook als deze nu angular of react doet.

[Carbon]

Ja en nu laat je dus PHP kompleet links liggen. Een taal die wel degelijk bedoelt is als serverside taal.

Mee eens, maar ik reageerde op de comment over NodeJS!

NodeJS valt wel meer hoe erg dat een specifiek platform is.

NodeJS maar dan met Typescript ipv Javascript is een zeer prettige omgeving (gebruik het dagelijks) voort backend development!

[supersnathan94]

NodeJS maar dan met Typescript ipv Javascript is een zeer prettige omgeving (gebruik het dagelijks) voort backend development!

Oh dat geloof ik maar al te graag. Ikzelf ben helemaal niet zo thuis in JS en TS, maar TypeScript's typesafety maakt het wel degelijk erg geschikt voor back end toepassingen. Zeker als het event driven is, Kun je leuke dingen mee doen.

[JoannisO]

@Bigs grappig dat je dit aan haalt! Zoals @Snowfall ook al aan gaf werken wij vanuit het Vapor project nauw samen met Apple aan Server-Side Swift. Apple heeft diverse projecten opgezet die zich primair of zelfs alleen richten op de server.

Waar jij volgens mij naar refereert is een concept wat nu gepitcht wordt als "Distributed Actors".
https://forums.swift.org/t/pitch-distributed-actors/51669 Dit is iets waar bij als backend Swift community veel baat bij zien.

Er zijn al veel libraries beschikbaar zijn met kwalitatief goede implementaties. Ook hierin ondersteund Apple door opensource libraries samen met, of voor de Server community te implementeren. Zo heb ik onder andere NIOSSH met Apple's iCloud (Server) team ontwikkeld. Apple is zelf ook sterk aan de weg aan het timmeren door deze Server-Side tooling intern in iCloud toe te passen.

Apple's Server Projecten:
- https://github.com/apple/swift-nio-ssh
- https://github.com/apple/swift-cluster-membership

[Bigs]

Gaaf om te zien! Ik had in m’n hoofd dat server-side Swift niet aansloeg, maar dat kwam doordat IBM zich terug trok. Mooi dat het binnen Apple en de community zo leeft.

[- peter -]

Ik lees dat ze qua Actors nog een hoop nieuwe dingen in de planning hebben rond versie 6.0

[Carbon]

Dit is ook slechts het fundament!

Volgende stappen zijn distributied actors en high level add-ons als pools en supervisors

[Carbon]

of het onderstreept hoe Swift puur en alleen richt op client-side development waar dat soort zaken niet nodig zijn.

Swift wordt ook server-side gebruikt!
Zie: b.v. Vapor

[Miuccia]

Kan iemand voor de leek uitleggen wat de concurencyprogrammeerstijl is?

[bzzzt]

Concurrency is het uitvoeren van meerdere taken tegelijkertijd. Er zijn, afhankelijk van je programmeertaal en framework of bibliotheken, verschillende manieren om te zorgen dat taken naast elkaar worden uitgevoerd en toegang tot gedeelde data geregeld wordt zodat deze niet door twee verschillende taken tegelijk wordt gemanipuleerd met mogelijk foute data als gevolg.

[The Zep Man]

Concurrency is het uitvoeren van meerdere taken tegelijkertijd.

Ja en nee. In deze context:

Het Swift Core Team van Apple noemt Swift 5.5 zelf een massive release en de ontwikkelaars lichten onder andere de concurrency-eigenschappen zoals async/await uit.

Gaat het over asynchroon programmeren. Met asynchroon programmeren kan een taak neergelegd worden om te werken aan iets anders als er bijvoorbeeld gewacht moet worden (bijvoorbeeld op een netwerkbericht), en wordt het weer opgepakt zodra eraan gewerkt kan worden. Asynchroon programmeren houdt strikt genomen niet in dat aan meerdere taken tegelijkertijd gewerkt wordt, enkel dat de CPU efficiënter is in het schakelen tussen taken binnen een thread. Multi-threading is een vorm van het daadwerkelijk uitvoeren van meerdere taken tegelijkertijd.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 01:26]

[bzzzt]

Begrijp ik. De vraag was alleen 'leg het een leek uit'

[The Zep Man]

Het was daarom ook een aanvulling op je uitleg ('ja en nee'), die zo bedoeld voor een leek niet verkeerd is.

[johnbetonschaar]

Asynchroon programmeren houdt strikt genomen niet in dat aan meerdere taken tegelijkertijd gewerkt wordt, enkel dat de CPU efficiënter is in het schakelen tussen taken binnen een thread

Ik zou het anders omschrijven. Asynchroon programmeren wil eigenlijk niet heel veel meer zeggen dan dat je de code opschrijft op een manier die veel beter aansluit bij het feit dat je programma asynchrone taken moet kunnen afhandelen. Dus bijvoorbeeld reageren op user events, I/O operaties die de rest van het programma niet moeten blokkeren, achtergrond taken die een actie moeten triggeren als ze afgerond zijn, etc. Al deze dingen kun je op verschillende manieren opschrijven, met threads, queues en callbacks, of met co-routines, bijvoorbeeld. Zaken als async/await, of zoiets als futures/promises worden bovenop dit soort low-level infrastructuur gebouwd.

In feite heeft dit niet direct met efficientie te maken, maar veel meer met het structureren van je code zodat het veel makkelijker wordt om asynchrone code te schrijven en debuggen.

[Luminair]

Er wordt hier verwezen naar het gebruik van async/await, in tegenstelling tot het gebruik van callbacks. In veel programmeertalen kun je een functie allerlei parameters meegeven, waaronder andere functies. Functie A kan dan de meegegeven functie B oproepen wanneer nodig.
Dit is nodig in gevallen waarbij een functie een eigen ding gaat doen, en de rest van het programma door gaat. Zo'n functie is eigenlijk al asynchroon.

function httpGetRequest(callbackFunction) {
// Code om een http get request te doen
callbackFunction(httpGetRespons)
}

function hallo(httpGetRespons) {
print("Hallo, het respons is " + httpGetRespons)
}

httpGetRequest(hallo)

Zo ziet het er uit met callbacks. Met async/await kan het zo geschreven worden:

async function httpGetRequest() {
// Code om een http get request te doen
return httpGetRespons
}

function hallo(httpGetRespons) {
print("Hallo, de respons is " + httpGetRespons)
}

var response = await httpGetRequest()
hallo(response)

Dit is even wat gesimplificeerd, maar bij grote codebases kan het een enorm verschil opleveren in leesbaarheid. Als je allerlei callbacks in elkaar stops kan het snel onoverzichtelijk worden.

[Reactie gewijzigd door Luminair op 24 juli 2024 01:26]

[SoloH]

Je laat een async nu awaiten. Dus maak je het weer synchroon.

Beter dus in swift:

func httpGetRequest() async -> Response {
// Code om een http get request te doen
return httpGetRespons
}

func hallo(_ httpGetRespons: Response) {
print("Hallo, de respons is " + httpGetRespons)
}

httpGetRequest() { response in
hallo(response)
}

Een leuk stukje code is dit:

async let firstPhoto = downloadPhoto(named: photoNames[0])
async let secondPhoto = downloadPhoto(named: photoNames[1])
async let thirdPhoto = downloadPhoto(named: photoNames[2])

let photos = await [firstPhoto, secondPhoto, thirdPhoto]
show(photos)

Leest asynchroon 3 foto’s in en laat ze pas zien als ze allemaal geladen zijn.

[david-v]

Het is geen enkel probleem om een async call "synchroon" te maken door direct een await te gebruiken. Je maakt de call niet synchroon maar je code wordt dan wel liniair uitgevoerd. Het grote verschil is dat je de thread waar je een await asyncCall doet niet blokkeert. Kan best handig zijn in een UI Thread zodat de UI Thread andere dingen kan doen.

[SoloH]

Ja als dat het enige zou zijn wat nog moet gebeuren, maar je kan ook alvast nog die andere functies doen. Zeker in het geval van een http request waar je op gaat wachten.
Dus ben het niet eens met geen enkel probleem.

[Reactie gewijzigd door SoloH op 24 juli 2024 01:26]

[david-v]

Ik wou alleen maar aangeven dat het niet verkeerd is om direct een await te doen bij een async call. Zeker als de thread meerdere taken moet uitvoeren zoals een UI Thread. Het uitvoeren van meerdere async calls die je later await is uiteraard waar het voor het meest gebruikt wordt, maar het is niet de enige reden om async en await te gebruiken.

[SoloH]

Ja zeker goede tip. Viel alleen over het geen enkel probleem zijnde 🤓

[Luminair]

Je laat een async nu awaiten. Dus maak je het weer synchroon.

Ja, dat is het punt. Dat kan met een callback patroon niet. Zoals ik al zei was het gesimplificeerd. Maar blijkbaar zat ik fout genoeg om off-topic gemod te worden, dus ik zal het hele punt wel missen.

[Reactie gewijzigd door Luminair op 24 juli 2024 01:26]

[SoloH]

Je zegt goed dat je met een callback het ook asynchroon kan doen. Daarom doe je die constructie als je geen async functie hebt. Maar om nu zo’n callback te gaan herschrijven naar een async await, dan doe je het hele asynchroon te niet. Dat lijkt me incorrect en daar krijg je waarschijnlijk die min mod van.

[n8n]

Taken verdelen over meerdere threads/processen om zo de workload te verdelen. Zie het als een snelweg met meerdere banen en het is nu makkelijker geworden om te ‘ritsen’.

[david-v]

Mooi uitgelegd. Complimenten . Ik weet niet hoe het in Swift is geïmplementeerd maar in C# is een taak een abstractie van een proces en wordt deze standaard in de huidige thread uitgevoerd. Bij cpu intensieve taken wil je juist wel gebruik maken van een nieuwe thread en roep je expliciet Task.Run aan.

"It’s important to reason about tasks as abstractions of work happening asynchronously, and not an abstraction over threading. By default, tasks execute on the current thread and delegate work to the Operating System, as appropriate. Optionally, tasks can be explicitly requested to run on a separate thread via the Task.Run API."

Bron

[Wolfos]

Normaal gesproken word code lineair uitgevoerd, van boven naar beneden, nooit tegelijk.

Swift introduceert hier 'async', ofwel asynchrone code, die niet meteen uitgevoerd hoeft te worden. Deze kan er een paar seconde over doen, terwijl de rest van de code met andere dingen bezig kan. Dit is niet persé ook concurrent. Je kunt namelijk gewoon wachten tot het klaar is.

Denk hier bijvoorbeeld aan een taak uitvoeren, en tegelijkertijd een laadbalk weergeven die constant geüpdatet word. Zonder asynchrone code zou de applicatie volledig vastlopen.

Er worden ook 'tasks' geïntroduceerd, waarmee je een stuk asynchrone code pakt, zegt "voer dit uit, en als het klaar is, doe dit".
Hierdoor kan deze code lekker op een andere CPU-core draaien, en heb je verder geen last van de performance gevolgen van een functie die eventueel meerdere seconden kan duren.

Verder word de term pyramid of doom gebruikt. Volgens mij word hiermee bedoelt dat het soms lastig is om asynchrone code vanuit normale code te gebruiken. Eén stukje asynchrone code kan dus een pyramide-effect tot gevolg hebben waarbij de hele applicatie ineens asynchroon moet.

[Reactie gewijzigd door Wolfos op 24 juli 2024 01:26]

[scholtnp]

Ik zie het grafisch net iets anders voor me....

[Wolfos]

Oh nee waarom

[sys64738]

Computers en telefoons hebben meerder CPU cores. Hierdoor kun je meerdere taken naast elkaar uitvoeren. Maar je programmertaal/platform moet hier wel mee om kunnen gaan.

In deze versie van Swift zijn deze mogelijkheden dus verbeterd.

[pofsok]

Ik kan het in ieder geval proberen. Bij een 'traditionele' programmeerstijl, wordt er een lijst afgelopen van commando's/instructies die worden uitgevoerd. De volgende instructie wordt pas uitgevoerd wanneer eerdere instructies zijn afgerond. Bij concurrencyprogrammeerstijl (concurrency staat voor gelijktijdig), kan je er voor kiezen dat een volgende instructie al wordt opgepakt wanneer een eerdere nog moet worden afgerond (dit werkt alleen als de volgende instructie onafhankelijk is van de uitkomst van de voorgaande instructie)

Als je dat goed implementeert, krijg je veel efficientere code, omdat er veel minder gewacht hoeft te worden, de applicatie heeft altijd wel een taak om uit te voeren.

[Digital-DNA]

Als je app bijvoorbeeld informatie opvraagt van internet, dan wil je niet dat je app ondertussen op slot gaat totdat die informatie binnen is. Je doet dit dan op een andere thread zodat je ondertussen de app kan blijven gebruiken. Probleem is wel dat je rekening moet houden met dat de state van de app ondertussen veranderd kan zijn, wat voor problemen kan zorgen.

Zoek ook eens op race condition

[j0bro]

Concurrency is 'veel hooi op je vork'
Parallellisme is 'veel vorken'

Meer hierover achter deze link

[Wolfos]

Super programmeertaal. Het is alleen jammer dat er zo weinig cross-platform mogelijkheden zijn. Ja, je kan de taal compileren, maar UI ga je helemaal zelf moeten regelen.

[xoniq]

Zou mooi zijn als SwiftUI een ding was op andere platformen. Super fijn om mee te werken.

[Fraaank]

Zonder vingers te wijzen, maar aan wie ligt dat? Eerlijke vraag van mijn kant, omdat ik het echt niet weet.

[YopY]

Geen commerciële partij die er geld aan uitgeeft. Voor Mac is Apple degene die de ontwikkeling sponsort, maar voor bijv. Windows, wie doet het? Mensen willen niet betalen voor een UI toolkit, ik bedoel, noem een paar succesvolle commerciële UI toolkits, of open source toolkits die geen commerciële sponsor hebben.

QT is misschien wel de enige grote cross-platform UI toolkit. Electron (dwz: web technologie) is de andere.

[Wolfos]

Microsoft werkt momenteel aan zoiets voor .NET. "Multi Platform App UI" ofwel, MAUI

Maar ik zie Swift als potentiele vervanger voor het extreem gedateerde C++. Een cross-platform ecosysteem zou daarvoor heel waardevol zijn.

[Laurens-R]

Waarom zie jij swift als een vervanger voor C++? Waarom niet Rust bijvoorbeeld? De laatste jaren is er overigens veel werk in de C++ standaard gestopt. Ik zeg niet perse dat dit nou C++ helemaal hip heeft gemaakt (op sommige vlakken vind ik zelf dat je door de bomen het bos niet meer ziet)... maar de taal is wel in beweging. Daarnaast zitten we ook nog met het feit dat op de PC desktop de meeste API's in C/C++ zijn geschreven (Win32 wil maar niet dood gaan en linux heeft by definition een C api)

Gewoon een oprechte vraag naar jouw mening Ik zit zelf niet in een specifiek kamp, maar ik zie wel dat 'iedereen' heel erg druk is met nieuwe talen etc, maar dat de tractie niet altijd even hard gaat.

[Carbon]

Waarom zie jij swift als een vervanger voor C++? Waarom niet Rust bijvoorbeeld?

Swift is op dit moment geen vervanger voor C++
Daar is pas sprake van als het ownership manifesto is geïmplementeerd (Rust like memory management )

[Wolfos]

Los daarvan moet ook het ecosysteem rondom de taal enorm verbeteren, en het is de vraag of dat gaat gebeuren. Vandaar ook "potentieel" in mijn oorspronkelijke bericht.

[Wolfos]

C++ blijft wat mij betreft geen fijne taal om mee te werken. Wat ze er ook mee doen, het blijft een taal uit de jaren '80 met veel vreemde kronkelingen, limitaties en valkuilen. Ik ben van mening dat dit ons (game industrie) enorm veel productiviteit kost, en veel bugs veroorzaakt. Daar ben ik overigens lang niet de enige in.
Swift is goed op weg om Apple's gedateerde Objective-C te vervangen, en laat zien dat een native taal ook gewoon fijn kan zijn om mee te werken. Zelfs als API's in C geschreven zijn kan Swift ermee overweg.

Ik denk niet dat het uiteindelijk gaat lukken om C++ te vervangen. De hoeveelheid werk die daarvoor moet gebeuren is erg groot, maar ik zou het graag zien gebeuren.

Rust kan ik verder niet veel over zeggen. Het lijkt in ieder geval dat ze daarmee wat verder op weg zijn.

[ari3]

Swing is cross-platform UI toolkit en is open-source sinds de Java Development Kit open-source gemaakt is. Voordeel daarbij is dat er naast Java ook andere programmeertalen zijn die op de Java Runtime kunnen kunnen draaien en dus ook Swing kunnen gebruiken, bijvoorbeeld Kotlin, Clojure, Scala, enz.

Daarnaast wordt JavaFX steeds volwassener. Daarmee kun je één applicatie schrijven die zonder aanpassingen op alle gangbare telefoon-, tablet- en desktopplatformen werkt. Helaas werkt Apple het gebruik van JavaFX op iOS actief tegen...

[Carbon]

Al die write-once run anywhere oplossingen zijn een compromis.

Prima voor apps die geen kritische eisen stellen aan de gangbare platform UI/UX en/of geen gebruik maken van platform specifieke features.

En dan is er de toegenomen complexiteit en resource gebruik door een abstractie laag bovenop het OS

[Reactie gewijzigd door Carbon op 24 juli 2024 01:26]

[SilentLucidity]

Electron dekt de lading niet. Hierdoor kan je webapps draaien op Mac, Windows en Linux, maar niet op mobiele platforms. Daarvoor moet je het weer in iets anders verpakken die gebruik maken webview zoals Cordova of Capacitor. En wat maakt het een UI kit? Dat het HTML elementen beschikbaar stelt? Met CSS styling? Niet dat ik het oneens met je bent, maar ben gewoon benieuwd.
Overigens zou ik Flutter aan je lijst willen toevoegen, dat lijkt me wel aan de definitie voldoen

[Lord Anubis]

IBM werkt er ook mee.
Zou willen dat het op Raspberry PI serieus komt.

[Wolfos]

De bal ligt bij Apple, om het zo te zeggen.

[Jan Onderwater]

Nee, het is open source, de bal ligt bij iedereen die hem op wil pakken.

Swift voor Windows
Swift for Linux

[Reactie gewijzigd door Jan Onderwater op 24 juli 2024 01:26]

[- peter -]

Je hebt Compose op Android, waarvan android devs dat natuurlijk andersom ook willen

En dan heb je Flutter natuurlijk ook, dat al cross platform is, maar goed dan zit je met Dart als taal.

[Reactie gewijzigd door - peter - op 24 juli 2024 01:26]

[Jan Onderwater]

Het is Open Source,
Swift voor Windows
Swift for Linux

[Reactie gewijzigd door Jan Onderwater op 24 juli 2024 01:26]

[alienfruit]

Het probleem is ook dat SwiftUI en Swift slecht gedocumenteerd is dus je kan ook niet makkelijk wat cross-platform kan maken. Het zou mooi zijn als je Swift libraries/frameworks zou kunnen hergebruiken maar helaas is dat niet mogelijk omdat de Swift (compiler)ontwikkelaars vinden dat dit niet hoeft te worden gedocumenteerd en dat je het gewoon in de code kan lezen.

Zelf gebruik ik Swift om een Android, en iOS/iPadOS applicatie te bouwen als sales demo op mijn werk. Ik zou graag SwiftUI achtige iets willen gebruiken om mijn UIs voor iOS of Android te beschrijven maar helaas. Tot nu lekker aan klungelen in Xcode voor iOS en Android Studio voor Android.

Gelukkig is alles behalve the UI te hergebruiken.

Maar goed mijn mening is dat je die toch 1-op-1 kan overnemen van elkaar. Een app dat de Android Design language gebruikt op iOS werkt toch minder makkelijk dan één die gebruik maakt van de iOS HIG

[Reactie gewijzigd door alienfruit op 24 juli 2024 01:26]

[Lord Anubis]

Swift slecht gedocumenteerd

Klopt, jammer dat ze daar geen tijd in steken, ik denk altijd maar één Documentatie uurtje scheelt voor duizend developers honderden uren.

Het irriteert me ook dat de samples soms nog in obj-C begin fase zitten. Zag vorige maand zelfs nog een obj-C / C sample dat zelfs nooit meer gecompileerd zou kunnen worden.

[Verwijderd]

@Miuccia
"het zich in dezelfde tijdsperiode afspelen van verschillende processen of activiteiten, die dan gelijktijdig worden genoemd."

Aangezien CPU's tegenwoordig meerdere cores hebben, en daarop zelfs nog meerdere threads kunnen ze verschillende dingen tegelijk doen. Daar moet je als programmeur rekening mee houden en dat is niet eenvoudig. Daarom zijn/worden er in programmeertalen constructies toegevoegd om daar makkelijker mee om te kunnen gaan.

edit: dit was dus als reactie bedoel op @Miuccia
edit2: wikipedia heeft een redelijike uitleg in het Nederlands : https://nl.wikipedia.org/wiki/Gelijktijdigheid_(informatica)

[Reactie gewijzigd door Verwijderd op 24 juli 2024 01:26]