Sunucu Yok, Bekleme Yok

MiniSwift güncellemeleri hakkında

Daha önce de defalarca dile getirdim ama tekrar edeyim: MiniSwift, 3 senelik bir geliştirme sonucunda 2026 senesinin Nisan ayında yayına aldığım bir proje. Yayına aldıktan sonra çok fazla yol aldım. (Gerçekten, bir noktada artık local'de çalışmayı bırakıp gerçek dünya ile yüzleşmek gerektiğini bir kez daha anladım.) Gelen olumlu ve olumsuz eleştiriler beni çok geliştirdi. Bunun için herkese çok teşekkür ederim.

Bugün (7 Eylül 2026) internette Swift REPL ya da playground'lara biraz bakınmak istedim. Maalesef karşıma çıkanların hepsi sunucu taraflı derleme yapıyordu. Bu gerçekten kullanım açısından hem çok maliyetli hem de dürüstçe söylemek gerekirse kullanışlı değil.

Sadece print yazıp Run'a bastığımda, bu basit kodun derlenmesi için yaklaşık 60 saniye bekledim.

MiniSwift burada 5 noktada, muadillerinden çok güzel ayrışıyor.

1. Sunucu maliyeti sıfır. Sizin yazdığınız kodların hepsi sizin istemcinizde derleniyor ve çalışıyor. Hiçbirisi MiniSwift sunucusuna uğramıyor. Dilerseniz internetinizi kapatıp test edebilirsiniz.

2. Bekleme zamanı. Yani Swift öğrenen birine ya da hızlıca bir kodunu test etmek isteyen birine "gel kardeşim, her satır değişikliğin için 1 dakika bekle" demek, ne bileyim, 2026 için çok kabul edilebilir gelmiyor bana.

3. STDLib. Bu playground'ların hepsi Swift STDLib'i destekliyor; belki bu eleştirilemez. Ama MiniSwift, Apple ekosisteminden hatrı sayılır miktarda kütüphaneyi destekliyor. Foundation gibi (evet, Foundation'ı destekliyor).

4. Debugger. MiniSwift kendi içerisinde, Asyncify ve JSPI kullanmadan size kodlarınızı debug etme şansı veriyor. Canlı olarak. Hiçbir online Swift REPL'inin bunu yaptığını görmedim.

5. Ve tabii ki SwiftUI. Buna ileride fazlasıyla değineceğim.

Tabii burada eleştirinin yanında, o tarz programların şöyle bir rahatlığı var: hepsi gerçekten Swift dili ne sunuyorsa koşulsuz size aktarabiliyor. Burada MiniSwift biraz ayrışıyor. Çünkü Swift dilinde olan ve bazı edge-case'lerde gözden kaçan durumları belki çalıştırmayabilir. Her ne kadar resmî test corpus'undan geçse de, native dilin kendisinin kapsadığı ve çözdüğü edge-case bug'lar belki MiniSwift'te de vardır. Bilemiyorum.

Peki MiniSwift bunu nasıl yakalıyor? İşte bu noktada gerçek dünya projeleri devreye giriyor. GitHub'dan rastgele indirdiğim 1500 Xcode projesini sürekli MiniSwift ile derleyip teste tabi tutuyorum ve çıkan boşlukları kapatarak ilerliyorum.

MiniSwift'i yavaşlatan şeyler

Bir proje geliştirirken ilk başta interface tasarlamak ile başlarım. Yani bu kod parçası, modül, kütüphane size ne vaat ediyor? Ve interface'i tamam olan bir projenin — ki bu aynı zamanda kâğıt kalem ile proje üzerinde uzun süre çalışıp düşünmeyi gerektiriyor — bence yarısından fazlası tamamlanmıştır. Hatta uç noktaları kestirebilirseniz, ki burada gerçekten yazılımcının tecrübesi ve işe hâkimiyeti ortaya çıkıyor, artık o saatten sonra kodunuzun nasıl yazıldığı, iç implementasyonu gerçekten detay olarak kalıyor.

MiniSwift'e de aynı mantıkla başladım. Dışarıya sunduğum MSF'de ve iç implementasyonlarda her zaman önce kendim interface tasarladım. Fakat bu bir süre sonra kontrolüm dışına çıkmaya başladı. Sebebi ise MiniSwift'in sadece Swift dilini değil, Apple ekosistemini handle etmeye çalışmasından kaynaklandı.

Tüm Apple platformunu tek bir wasm dosyasında eritmeye çalışmak gerçekten çılgınca bir düşünceymiş. Bu işi yapacak olanlara tavsiyemdir, bunu yapmayın :D

Tabii bunun da sebepleri var. Eğer yazı uzamazsa ona da ayrıca gireriz.

İlk başta Swift dilinin front-end kodunu yazdıktan sonra (parser, lexer, AST, semantik analiz) tüm .swiftinterface dosyalarını sistemden taradım ve Apple'ın sunduğu resmî kütüphanelerin sözleşmelerini aldım; bunları ayrı ayrı klasörlere hem .swift ve .h olarak hem de doküman olarak koydum.

Bu noktadan sonra hepsi için ayrı ayrı gaps.md ve feature-matrix.md dosyaları oluşturdum. Yani ben bu interface'lerin ne kadarını destekliyorum? Eksiklerimi görebilmenin en makul yolu olarak bunu bulabildim.

Daha sonra ilk başta STDLib kütüphanesini tamamlamam gerektiğinin farkındaydım. Fakat 3 senelik geliştirmede parça parça gitmiştim. Bunun sebebi de mühendislik sabırsızlığı diyebileceğim şeydi: SwiftUI kodunu web'de çalıştırabildiğimi görmek. Fakat SwiftUI'ın değdiği bir kodun olmaması çok can sıkıyordu. O yüzden kendime bir disiplin belirledim ve ilk başta STDLib kütüphanesindeki gap'lerin hepsini kapatmam gerektiğini fark ettim. Canlıya aldıktan belki 4 ay sonra bunu başarabildim.

STDLib kütüphanesinde hiç partial ve missing kalmadığını görünce artık içim rahatlamıştı. Çünkü MiniSwift'i kullanan insanlar haliyle STDLib'de olan bir kodu test ettiklerinde çalışmadığını görünce, kimisi dalga geçerek kimisi gerçekten samimiyetle geri dönüş yapıyordu.

Ve bu riski en azından minimize ettiğimi fark ettim; artık bu tarz geri dönüşler kesildi. Artık insanların sıradan bir console app açıp istedikleri kodu yazıp test ettiklerini fark ettim. Bunu nasıl anladım sorusu gelebilir akla: sunucu trafiğinden. Sunucuya gelen trafiğe baktığımda günlük yaklaşık 10-20 bin istek geldiğini gördüm ve sadık bir kullanıcı kitlesi olduğunu sw.js dosyasından fark ettim ;-)

Yoldan sapmalar

Maalesef, artık bizim işin büyüsü mü yoksa belası mı dersiniz, bir süre sonra kendini tekrar eden işleri fark ettiğinizde, onun bir hayli gereksiz olduğunu görüp "bu böyle mi yapılmalı?" sorusunu soruyorsunuz.

O sorunun peşine düştüğünüz an, projede ciddi anlamda sapmalar meydana geliyor. Benim de MiniSwift'te yaşadığım sapmaların bir kısmı buradan kaynaklandı. Çünkü Apple framework'lerinde yaptığım geliştirmelerin birçoğunun aynı zamanda diğer işletim sistemlerinde çalışan Kotlin (Android) ve C# (Windows) için de benzer olduğunu fark ettim. Hatta bir ara bunun bir grafiğini de sosyal medyadan paylaştım.

Bu noktada işler benim için çatallaşmaya başladı. Çünkü artık Swift'in STDLib'i yanında diğer Apple framework'lerinde yapılan işlerin çok benzerlerinin Android ve Windows'ta da olduğunu fark ettim. Neden bunları ortak bir platforma çıkarmamalıydım ki :D

Klişeler

Her işte olduğu gibi bizim sektörde de bazı klişeler var. Yapılamaz! "Neden?" sorusuna cevap aradığınızda genelde karşınıza çıkan şeyin ortak cevabı aslında şu:

Kocaman ekosistemin (Apple, Android vb.) yapamadığını sen mi yapacaksın? Bir akıllı sensin zaten. Bir tek senin aklına geldi.

Ah, o merak işte böyle bir şey. Ama bu MiniSwift projesinin bu noktalara gelmesinin de sebebi merak değil mi?

"Yapılamaz" cevabı aslında şu: tek başına giremezsin ve seneler harcarsın, sonunda hiçbir şey elde edemezsin. Evet, bu çok daha doğru bir cevap. Haklı bir cevap. Ama bu beni durdurmadı; çünkü MiniSwift'e başlarken hiçbir zaman tüm Apple ekosistemini karşılayacağım diye çıkmadım. Bu, daha sonra yaptıkça "acaba şu kütüphaneyi de yapabilir miyim?" diye açılan kapılar oldu. Ve bugün itibarıyla geldiğim noktada aşağıdaki tüm Apple kütüphaneleri, bazıları partial da olsa MiniSwift'te şu an için destekleniyor:

Accelerate, AlarmKit, AVFAudio, Combine, Compression, CoreData, CoreFoundation, CoreGraphics, CoreImage, CryptoKit, Dispatch, Foundation, GameplayKit, ImageIO, Metal, MetalFX, MetalKit, ModelIO, Observation, QuickLookThumbnailing, SceneKit, simd, Stdlib, SwiftData, SwiftUI, System, UIKit (partial), UniformTypeIdentifiers.

Web ve diğer platformlara export alabilme

MiniSwift dilinin yapısı gereği IR'ye indirebildikten sonra artık elimde muazzam bir güç olduğunu fark ettim. Swift dilini artık bir ara dile çevirebiliyordum ve bu tamamen bana ait bir yapıydı. Yani LLVM ve benzerlerine muhtaç kalmadan, tamamen kendim şekil verebileceğim bir hamur olarak elimdeydi.

Local'de ilk yaptığım iş, bu dili Android'de çalıştırabilir miyim sorusu oldu. Yani MiniSwift'in desteklediği kütüphaneler kullanılarak yazılmış bir Apple projesini Android ve diğer platformlarda çalıştırabilir miyim? Bu soru beni çok heyecanlandırdı. Ve bu o kadar basit oldu ki ben bile çok şaşırdım.

Örnek olarak, Combine ve SwiftData kullanarak geliştirdiğim örnek bir projeyi Android'e çevirmek artık MiniSwift için çocuk oyuncağı gibi oldu. Çünkü Swift → IR → C diline çevirebiliyordum. Çevirdikten sonra da bunu JNI ile Android'e bağladım. Bingo. Swift dilinin ötesinde Apple kütüphanelerinin de Android'de çalıştığını görünce beynim yandı ;-) Artık bu işi bırakmamam gerektiğini anladım.

Peki bir diğer sorun vardı: SwiftUI kodunu ne yapacaktım? İlk başta SwiftUI kodunu Android'de göstermek gibi bir hata yaptım; SwiftUI arayüzünü birebir Android'e göstermeye kalktım ki bundan hızlıca vazgeçtim. Sonra da SwiftUI kodunu Compose layout'a çevirdim.

Bu ikinci çinko oldu benim için; çünkü Compose layout'ta yazılmış kodun içindeki bir reactive variable, Combine artık C koduna döndüğü için Android'e aynı deterministik davranışla geçmiş oldu. Bu cidden benim OHA anım oldu :D

Peki Android'e sadece bir köprü yazarak kurduğum yapı neden diğer işletim sistemlerine geçmesin sorusu geldi aklıma ve hemen bunu Linux (GTK) ve Windows ile denedim. Artık o kadar şaşırmadım çünkü aynı şeyi yapmıştım :D Hem de JNI olmadan, C dilinin muazzam gücüyle.

Apple ile geliştirdiğim bir projenin aynen Windows, Linux ve Android'de çalışması beni hem çok mutlu etti hem korkuttu.

Korkmamın sebebi şu: 2009'du sanırım, iOS 3'tü; o günden beri Apple uygulamaları geliştiriyorum ve bir projenin içinde ne gibi handikaplar ve 3. parti bağlantılar olduğunu biliyorum. İnsanların haliyle ilk yapacakları işin, kendi projelerini MiniSwift ile diğer platformlarda çalışıyor mu diye test etmek olacağını biliyordum.

Fakat mühendislik kabiliyetimiz geliştikçe reklam yönümüz zayıflıyor mu ne. Bunu becerememekten korktum. Yani bunu düzgün anlatamazsam, insanlar bunun bir AI slop olduğunu acımasızca yazacaklardı :D

Belki şu denebilir: insanlardan sana ne, sen işine bak. Keşke her konuda böyle düşünebilsem; ama etten kemiktenim ve bir kalbim var. Yazılanlar haliyle beni de çok etkiliyor.

Araya küçük bir anekdot olarak gireyim: MiniSwift'te yaptığımın benzerini Kotlin dili ile Android ekosisteminde yapabilir miyim sorusunun cevabını ararken MiniKotlin.run projesi çıktı. Ve kendi hâlimde takılırken, benim çok sonra haberim olan bir post gördüm.

Birisi MiniKotlin projesini görmüş ve Hacker News'te paylaşmış. Ve uzun süre HN'de bir numarada kalmış. Gençlik hayalim resmen bana kabus oldu.

"Bu projeyi yapan kişinin iki kelime konuşacak teknik bilgisi yoktur, karşımıza gelse iki kelime teknik konuşamaz" diye başlayıp, bunun bir domuz yemi olacak kadar kötü bir AI slop olduğunu yazanlar olduğunu okuyunca gerçekten üzüldüm. Çünkü projeyi ben HN'de paylaşmadım, haberim bile yoktu; 12 saat sonra eve gelip sunucu loglarına bakarken bir gariplik olduğunu fark edip gördüm. Ve çoktan hakkımda konuşulmuş ve hüküm verilmişti bile.

Demek ki bu âlemde kendi başına bir proje yayınlamak yasak diye düşündüm. Önce HN ahalisine gidip "kardeş, böyle bir projem var, yayınlayacağım ama kızmazsınız değil mi" diye icazetlerini almak gerekiyor. Garip.

Her neyse, konuyu çok uzatıp dağıttım. Bunun için affınızı diliyorum.

Hızlıca toparlarsam: web'e export alma özelliğini koydum ve çok iyi çalışmadığının farkındayım; ama bazı geliştirmelerin canlıya almadan düzelmeyeceğini tecrübe ettiğim için gelen feedback'lere göre kendimi geliştiriyorum.

Şu an MiniSwift'te Android, Linux ve Windows'a export alma hazır ama henüz canlıya almaya güvenemediğim için yayınlamıyorum. Umarım çok yakında yayınlarım.

Sağlıcakla kalın.