Nyílt forrásúvá vált az Apple Swift-je

Szerszám

Az Apple a nyár elején jelentette be, hogy átdolgozza Swift programozási nyelvét, majd a Swift 2-t az év végéig nyílt forrásúvá teszi. A kódnyitás megtörtént. Elindult a Swift.org, ahol a részletesen lehet tájékozódni a Swift-tel kapcsolatos lehetőségekről. A forráskód elérhető a GitHub-on. A nyílt forrású Swift projekt indulásával egy időben elérhetővé vált a Linux port is. Előre lefordított binárisok elérhetők Ubuntu Linuxra.

( log69 | 2015. 12. 04., p – 09:39 )

Újra írhatnák az egész OS-t és ökoszisztémájukat Swift-ben, talán kicsit biztonságosabb lenne - ha már hasonló sebességet jósolnak neki ;)

Kis bökkenő, hogy a reference counting miatt kb. minden esetben lassabb, mint a C/C++. Esetleg a GUI-s userspace-beli alkalmazásokhoz jobb lehet, mint az ObjC, végülis erre lett kitalálva.
Több biztonságot én nem látok sehol, csak több kényelmet + némi syntax sugar-t (ObjC-hez képest). iOS/OSX-en kívül pedig nem igazán használható, mert hiányzik alóla a UI.

Engem nem igazán érdekel jelenleg a Swift, de egyrészt sebességnél C/C++-hoz hasonlítod, biztonság kérdésénél meg ObjC-hez.

Kérdés szerintem hogy milyen fejlesztői környezet és eszköz választék fog köré épülni, mert ha Apple tényleg csak az OSX GUI alá hegyezi ki a támogatást legnagyobb mértékben, akkor lehet igazad lesz.

Vegigolvastam a cikket, de nem talatam infot arrol, hogy az appcode megy-e mar xcode nelkul, vagy ha nem csak egy konzolos programot szeretnel osszedobni elobb utobb meg kell nyitni az xcodeot is parhuzamosan.

-
Konténerezett Hadoop és Cassandra cluster konfigurálása - harmadik rész

"Több biztonságot én nem látok sehol, csak több kényelmet + némi syntax sugar-t (ObjC-hez képest)"

Pointerezned pl nem kell az esetek 99.9%-aban, de ha megis megtenned, elegge figyelmeztet a nyelv: 


Type * const *           UnsafePointer<Type>
Type * __strong *        UnsafeMutablePointer<Type>
Type **                  AutoreleasingUnsafeMutablePointer<Type>

En ezt biztonsagosabbnak erzem, hogy amit legtobbszor C/C++-ban pointereznel, azt itt leforditjak helyetted biztonsagosan.

Forras: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/…

( uid_194 | 2015. 12. 04., p – 09:53 )

* Apache licensz
* Nincs CLA
* Code of Conduct
* Community Guidelines

Szimpi.

--
|8]

- A CLA nyug a contributoroknak, meg akkor is, ha digitalisan is ala lehet irni. Ennel fogva az egyszeri contributor hozza se fog szagolni. (Nyelvnel ez kevesbe relevans, de barmely project ahol elofordul drive-by contributor, a CLA azt kb megoli.)

- A CLA arrol szol, hogy megtartjak a kontrollt a project felett, ami bar egyreszrol talan ertheto, masreszrol nagyon szembe megy a szabad szoftveres gondolkodassal.

... es meg sorolhatnam, de: https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

Mas mar leirta jobban.

--
|8]

( therion | 2015. 12. 05., szo – 02:46 )

Hát ez még ocsmányabb, mint a JavaScript.

( wachag | 2015. 12. 05., szo – 10:02 )

Ezen az oldalon: https://swift.org/getting-started/
Ennél a kódnál: 


let answer = "forty"-"two"

A hibát mutató ^ hova jelez? Miért nem a hibára, hanem egy változónév közepére? 


error: binary operator '-' cannot be applied to two 'String' operands
let answer = "forty"-"two"
~~~~~~~^~~~~~

Azert, mert a Swift compiler az elso olyan, fejlett compiler, mely mesterseges intelligenciat hasznal. Ahogy tobbet es tobbet forditanak vele az emberek, egyre pontosabbak lesznek a hibauzenetei, mert a kozponti AI megtanulja.

Mivel viszonylag friss az open source verzio - melyben debutalt ez a feature -, ezert a hibauzenetek itt-ott meg nem teljesen pontosak.

De nyugalom, idovel jobb lesz!

--
|8]