Yazılıma Nasıl Başlarım — 2026 Edition

Tunay Engin — Tue, 14 Jul 2026 00:00:00 +0000

“Yazılıma nasıl başlarım?” diye aratıyorsun. 2026. Telefonda ChatGPT açık, YouTube’da 40 saatlik “sıfırdan full stack” playlist’i indirme kuyruğunda, bir Discord’da “mentor arıyorum” yazılmış, başka bir yerde “3 ayda 80k USD remote” reklamı dönüyor.

Bu yazı bir motivasyon konuşması değil. Bir 2026 Edition — yani: başlık şaka, içerik biraz acı. İsteyen herkese hitap ediyor; çünkü 2026’da “nasıl başlarım” sorusu yaşa göre değişmiyor, mazeret stokuna göre değişiyor.

Spoiler: AI var, o yüzden daha kolay — ve daha zor</h2>
Kolay kısım: Artık her şey var.

Dil dokümantasyonu</li>
Ücretsiz kurs</li>
Açık kaynak örnek</li>
Stack Overflow arşivi</li>
YouTube’da adım adım</li>
Ve evet: AI :D</li> </ul>
Bizim zamanımızda (benim zamanımda) bu kadar düzgün öğrenme eğrisi ve “eline tutuşturulan” rehber yoktu. Bir şey kırılınca forumda üç gün dil döküyordun. Şimdi “bu hata ne” diye yapıştırıyorsun, cevap geliyor. İstediğin gibi yazıp çizebiliyorsun. Sandbox’lar, cloud free tier’lar, GitHub, package manager’lar — ortam rahatsız edici derecede konforlu.
Zor kısım: Konfor, disiplin yerine geçmiyor.
AI seni engellemez. Engelleyen şey genelde şu üçlü:

Başlamamak (araştırma fazı sonsuza uzar)</li>
Bitirmemek (tutorial hell)</li>
Göstermemek (kod sadece hard diskte “güvenli”)</li> </ol>
Yani 2026’da “kaynak yok” mazereti ölmüş durumda. Kalan mazeretler daha kişisel — ve daha sinir bozucu.
“AI var, kod öğrenmeye gerek yok” — 2026’nın en sevimli yalanı</h2>
AI kod üretir. Evet.
AI bazen güzel kod üretir. Evet.
AI bazen çalışır gibi görünen ama yanlış kod üretir. Daha çok evet.
Yazılım öğrenmek, klavyeden karakter dökmek değil. Şunları öğrenmek:

Problemi parçalamak</li>
Ne istediğini net söylemek (AI’ya da insana da)</li>
Çıktıyı doğrulamak</li>
Kırılınca neden kırıldığını anlamak</li>
Sistemin sınırlarını görmek</li> </ul>
AI kullanan ama bilgisayarın ne yaptığını bilmeyen biri, otopilotu açıp direksiyonu bırakmış sürücü gibidir. Yol düzken harika. Virajda haberleri olmaz.
2026’da AI araç. Çekiç. Çekiç ile ev yapan da var, parmağını ezen de. Fark: kim çekiç tutuyor, kim çekiç tarafından tutuluyor.
Öğrenmek isteyen her şekilde öğrenir. AI bunu engellemez; bazen hızlandırır. Ama emek ve zaman hâlâ masada. Bunu verdiğin sürece meyvesini alırsın.
Alamayabilirsin de. Bu bir muamma.
Tutorial hell — modern cehennemin ücretsiz planı</h2>
Klasik 2026 rotası:

“HTML CSS 10 saatte”</li>
“JavaScript masterclass”</li>
“React 2026 complete”</li>
“Next.js + tRPC + Prisma + Docker + K8s + AI agent”</li>
Hâlâ kendi projen yok</li> </ol>
Tutorial izlemek iyi hissettirir. Dopamin gelir. “İlerliyorum” sanırsın. Ama izlemek, yüzmek videosu izlemek gibidir: suya girmeden yüzme bilmezsin.
Proje odaklı öğren. Küçük, çirkin, senin olan bir şey:

Kişisel site</li>
CLI tool</li>
Not uygulaması</li>
Bot</li>
Oyun kopyası</li>
“Kendi ihtiyacım” script’i</li> </ul>
Mükemmel olmasın. Bitsin. Sonra bir şey ekle. Sonra boz. Sonra düzelt. İşte o döngü öğrenme.
Kurslar iskele. Kalıcı bina, senin yazdığın saçma projedir.
GitHub: utanç eşiğini geç</h2>
“Kodum kötü, koyamam.”
Herkesin kodu kötü başlar. Fark, bir kısmının kötü kodu herkese açık bırakıp zamanla iyiye götürmesi.
2026’da GitHub:

CV değil (sadece)</li>
Günlük değil (sadece)</li>
Alışkanlık kanıtı</li> </ul>
Commit at. README yaz. Issue aç kendine. Küçük PR’lar oku. Başkasının projesinde “typo fix” bile utançtan iyidir — çünkü sisteme dokunmuş olursun.
Public repo korkutucuysa önce private tut, ama bitir. Sonra cesaret gelince aç. Önemli olan: işin sadece kafanda değil, diskte ve mümkünse uzakta bir yerde dursun.
“Mentor arıyorum” ve diğer sosyal tuzaklar</h2>
Topluluk iyidir. Discord, forum, Reddit, X — bazen bir cevap hayat kurtarır.
Ama 2026’da bir de şu tip var:

0 proje</li>
0 commit</li>
40 sunucuda “mentor var mı?”</li>
“Yol haritası atın”</li>
“Hangisi daha iyi, Python mı Java mı?” (40. kez)</li> </ul>
Mentor sihirbaz değil. Senin yerine oturup öğrenemez. En iyi mentorluk genelde şudur: spesifik soru + “şunu denedim, şu hata geldi, şunu okudum”.
Genel “nasıl başlarım?” sorusunun cevabı 2026’da hâlâ aynı:

Bir şey seç. Yap. Takılınca sor. </blockquote>
Sihirli yol haritası yok. Varsa satılıyordur.
Kariyer, hobi, para — üç farklı oyun</h2>
Karıştırınca acı çekersin.
Oyun</th> Skor tahtası</th></tr></thead>

Hobi</td> Eğlence, merak</td></tr>
Öğrenme</td> Anlama derinliği</td></tr>
Kariyer</td> İş / para / güvenilirlik</td></tr> </tbody></table>
“3 ayda FAANG + lambo” vaadi 2026’da da satılıyor çünkü umut satılır. Gerçek daha sıkıcı:

İlanlar rekabetçi</li>
AI hem kapı açıyor hem bazı giriş işlerini sıkıştırıyor</li>
Portfolyo + ispat hâlâ işe yarıyor</li>
Network var ama boş vaatten ibaret network çöp</li> </ul>
Para isteyen: ürün veya iş.
Öğrenmek isteyen: proje.
Eğlenmek isteyen: canın ne istiyorsa.
Üçünü birden “hızlı ve garantili” isteyen: hayal ürünü alıyor demektir.
Kısa bir not benden</h2>
Eğer yapmak istiyorsan yaparsın. Bunu kimse engelleyemez — özellikle 2026’da. Öğrenme eğrisi ve öğretici rehberler bizim zamanımıza göre saçma derecede bol. AI var. Kaynak var. Bilgisayar erişimi var.
Bu kadar basit: öğrenmek isteyen her şekilde öğrenir. Emek ve zaman gerekir. Bunu verdiğin sürece meyvesini alırsın.
Alamayabilirsin de. Bu bir muammadır.
Ben 13 yılımı verdim; meyvesini fiilen 3–4 yıldır yiyebiliyorum. O 13 yılın çoğu “henüz ortada bir şey yokken de devam etmek”ti. Parlak highlight reel değil.
Feyyaz Yiğit’in dediği gibi: gerçeğin üzerinde çalışsan da başaramayabilirsin.
Bu cümle umutsuzluk için değil. Sahte garantiye karşı. Çalışmak zorunlu; başarı opsiyonel ve bazen adaletsiz. Yine de çalışmayanların “keşke”si, çalışanların “olmadı”sından daha ağır geliyor bana.
2026 Edition — fiili başlangıç (şaka bitti, liste)</h2>
Yarın için abartısız plan:

Bir dil seç. Hangisi olduğu 3. haftadan sonra o kadar da kutsal değil. Seç, bırakma.</li>
Bir proje seç. Küçük. 2 haftada utanç verici bir v1.</li>
Her gün (veya çoğu gün) dokun. 20 dakika bile.</li>
AI’yı asistan yap, öğretmen-kopya değil. Önce dene, takılınca sor, cevabı anla.</li>
Git’e koy. Private bile olsa.</li>
Bir yere yaz. Bug / öğrenilen / “yarın ne”.</li>
İlan / para / imaj’ı 90 gün ertele. Önce kas.</li> </ol>
İşte “nasıl başlarım”ın 2026 cevabı bu kadar romantik değil: başla, sürdür, doğrula.
Kapanış</h2>
“Yazılıma nasıl başlarım 2026 Edition” aslında şu sorunun maskesi:

Bu kadar kolaylaşmış bir dünyada hâlâ başlamıyorsam, sorun kaynak mı — yoksa ben miyim? </blockquote>
Kaynak tarafı 2026’da suçlanacak durumda değil. AI var. Rehber var. Araç var.
Kalan: zaman, emek, utanç eşiği, ve gerçeğin üzerinde çalışmanın bile garanti etmediği o garip muamma.
Yine de — yapmak isteyen yapar. Engelleyen çoğunlukla dış dünya değil, erteleme ve sonsuz “hazırlanıyorum” hali.
Şimdi kapat bu yazıyı. Editörü aç. Bir dosya yarat. Bir satır yaz.
2026 Edition böyle başlıyor. Gerisi commit history.

Agent-First Mimari: API'lerin Geleceği MCP

Tunay Engin — Mon, 06 Jul 2026 00:00:00 +0000

2025'te herkes "AI API'leri çağıracak" diyordu. 2026'da bu gerçek oldu — ama kimsenin tahmin etmediği bir şekilde.
AI agent'lar API çağırmaya başladı. Ama REST API'leri onlar için tasarlanmamıştı. Swagger dokümanları insanlar içindi. JSON Schema insan gözüyle okunmak içindi. Hata kodları "developer experience" odaklıydı.
Sonra Anthropic MCP'yi duyurdu. Ve her şey değişti.
REST'in kör noktası</h2>
REST, 2000'de Roy Fielding'in doktora teziyle doğdu. 25 yıldır web'in omurgası. İnsan developer'lar için mükemmel: predictable URL'ler, HTTP verb'leri, stateless iletişim.
Ama bir AI agent için REST şöyle görünür:
Agent: "Kullanıcının son siparişini getir." API: 401 Unauthorized Agent: "Token mı gerekiyor? Nereden alacağım?" API: [sessizlik] Agent: "GET /orders?filter=latest döneyim..." API: 400 Bad Request — "use 'sort' not 'filter'" Agent: "..." </code></pre> AI agent'lar REST'in implicit kontratlarını anlamaz. Onlar explicit'e ihtiyaç duyar. Her şeyin yazılı olduğu, keşfedilebilir, makine-okunabilir bir sözleşmeye. MCP tam olarak bu. MCP nedir?</h2> Model Context Protocol (MCP), Anthropic tarafından Kasım 2024'te duyurulan, AI agent'ların araçları ve veri kaynaklarını keşfetmesi için standart bir protokol. JSON-RPC 2.0 üzerinde çalışıyor. Basitçe: AI agent'ınıza "şu tool'ları kullanabilirsin" diyorsunuz. Agent, tool'ların isimlerini, parametrelerini, açıklamalarını JSON-RPC üzerinden keşfediyor. Sonra ihtiyacı olanı çağırıyor. // Agent sorar: {"method": "tools/list"} // Sunucu cevap verir: {"tools": [{ "name": "get_weather", "description": "Belirtilen şehrin hava durumunu getirir", "inputSchema": { "type": "object", "properties": { "city": {"type": "string", "description": "Şehir adı"} } } }]} // Agent çağırır: {"method": "tools/call", "params": {"name": "get_weather", "arguments": {"city": "İstanbul"}}} </code></pre> Bu kadar basit. Ama bu basitlik, API tasarımında bir paradigma değişimini temsil ediyor. Agent-first API tasarımının 5 prensibi</h2> RustAPI'yi geliştirirken, MCP'yi native destekleyen ilk web framework'ü yaparken öğrendiğim prensipler: 1. Her endpoint kendini açıklamalı</h3> İnsan developer için GET /api/v2/orders?sort=desc&limit=10</code> yeterli olabilir. Ama AI agent için yeterli değil. Agent-first API'de her endpoint'in bir description'ı, her parametrenin bir açıklaması, her response'ın bir schema'sı olmalı. Swagger/OpenAPI zaten bunu yapıyordu — ama MCP bunu runtime'da, agent tarafından keşfedilebilir hale getiriyor. 2. Input/output kontratı explicit olmalı</h3> AI agent'lar, "şu durumda şu HTTP status döner" gibi implicit bilgileri anlamaz. Onlara her olasılığı söylemelisiniz: ## Bu endpoint ne döndürür? - 200: Başarılı — WeatherResponse JSON - 404: Şehir bulunamadı — ErrorResponse JSON - 429: Rate limit aşıldı — lütfen 60 saniye bekle - 500: Sunucu hatası — tekrar dene </code></pre> Bunu MCP'nin tool description'ına yazdığınızda, agent hata durumlarını yönetebiliyor. REST'te bu bilgiyi nerede veriyordunuz? Belki Swagger'da, belki dokümanda, belki hiçbir yerde. 3. Tool'lar composable olmalı</h3> Bir AI agent nadiren tek bir endpoint çağırır. Genelde birkaç endpoint'i zincirler: Kullanıcıyı bul (search_users</code>)</li> Siparişlerini getir (get_orders</code>)</li> En sonuncusunu bul (—</code> bunu agent kendi yapar)</li> Kargoyu sorgula (track_shipment</code>)</li> </ol> Agent-first API'de tool'lar, birbirinin output'unu input olarak alabilecek şekilde tasarlanmalı. search_users</code>'ın döndüğü user_id</code>, get_orders</code>'ın beklediği user_id</code> ile aynı isimde ve aynı formatta olmalı. Buna tool compatibility diyorum. 4. Permission modeli granular olmalı</h3> İnsan developer'a "bu API key ile her şeyi yapabilirsin" diyebilirsiniz. AI agent'a diyemezsiniz. Agent-first API'de permission modeli şöyle olmalı: Agent X, read:orders</code> yapabilir ama write:orders</code> yapamaz</li> Agent Y, read:orders</code> + read:users</code> yapabilir ama delete:*</code> yapamaz</li> Agent Z (admin agent), her şeyi yapabilir ama amount > 10000TL</code> olan işlemlerde insan onayı ister</li> </ul> RustAPI'de bunu MCP Permission Scoping ile yapıyorum (v0.1.508). Her MCP tool'una scope atayabiliyorsunuz, her agent'a scope set'i tanımlayabiliyorsunuz. 5. Output, agent-readable olmalı</h3> Bu kritik. İnsan için yazdığınız response: {"message": "Siparişiniz başarıyla oluşturuldu, teşekkürler!"} </code></pre> AI agent için yazdığınız response: { "order_id": "ord_2026_0706_001", "status": "confirmed", "estimated_delivery": "2026-07-08T14:00:00+03:00", "total_amount": {"value": 149.90, "currency": "TRY"}, "tracking_url": "https://kargo.example.com/track/TRK123456" } </code></pre> İnsan "teşekkürler" mesajını okur ve mutlu olur. AI agent order_id</code>'ye bakar ve bir sonraki işleme geçer. İkisi farklı dünyalar. Gerçek dünyadan bir örnek: SemantiCAD</h2> SemantiCAD'de MCP'yi nasıl kullandığımızı anlatayım. SemantiCAD, bir CAD dosyasını (STEP/DXF) alıp maliyet, BOM (Bill of Materials) ve üretim adımları çıkaran bir sistem. Bunu yapmak için birden fazla AI modelini zincirliyor. Eski yöntem: Her model için ayrı bir Python script'i yaz, output'u parse et, sonrakine pipe'la. Her şey kırılgan, her şey ad-hoc. Yeni yöntem (MCP ile): STEP Parser Tool: "Bu STEP dosyasını parse et, geometrik feature'ları çıkar"</li> BOM Generator Tool: "Bu feature listesinden malzeme listesi oluştur"</li> Cost Estimator Tool: "Bu BOM ve feature listesinden maliyet tahmini yap"</li> Process Planner Tool: "Bu feature listesinden üretim adımlarını planla"</li> </ol> Her tool bir MCP endpoint'i. Ana agent (Claude veya DeepSeek), bu tool'ları sırayla çağırıyor. Her tool'un input/output kontratı explicit. Tool'ları istediğiniz sırada zincirleyebilirsiniz. Yeni bir tool eklemek, mevcut hiçbir şeyi bozmaz. Sonuç: %96 BOM accuracy. Eski yöntemde %70'lerdeydik. MCP'nin getirdiği yapılandırılmış iletişim sayesinde. MCP vs REST vs gRPC vs GraphQL</h2> Hangisi ne zaman? Protokol</th> En iyi olduğu yer</th> AI agent için uygun mu?</th></tr></thead> REST</td> İnsan developer'lar için API'ler</td> Hayır — implicit kontratlar</td></tr> GraphQL</td> Esnek veri sorgulama (insanlar için)</td> Kısmen — schema var ama tool semantics yok</td></tr> gRPC</td> Mikroservisler arası iletişim</td> Kısmen — protobuf explicit ama keşif yok</td></tr> MCP</td> AI agent'lar için tool exposure</td> Evet — bunun için tasarlandı</td></tr> </tbody></table> Geleceğin stack'i: İnsanlar için REST/GraphQL, servisler için gRPC, AI agent'lar için MCP. Üçü aynı backend'te, aynı endpoint'lerin farklı "görünümleri" olarak. RustAPI'de tam olarak bunu yapıyorum. Bir endpoint yazıyorsunuz, otomatik olarak REST (HTTP) ve MCP (JSON-RPC) endpoint'i olarak expose ediliyor. Aynı kod, iki protokol. 2026-2027'de ne göreceğiz?</h2> Tahminlerim: Her SaaS'ın bir MCP endpoint'i olacak. Tıpkı 2015'te her SaaS'ın bir REST API'si olması gibi.</li> Agent-first, insan-second. Yeni API'ler önce AI agent'lar için, sonra insan developer'lar için tasarlanacak.</li> MCP Gateway'ler yaygınlaşacak. Tüm şirket API'lerini tek bir MCP endpoint'inde toplayan gateway'ler.</li> Agent-to-agent protokolleri. Sadece agent-to-API değil, agent-to-agent iletişim protokolleri de standartlaşacak.</li> Permission modelleri en büyük problem olacak. Bir AI agent'ın neye erişebileceğini kim, nasıl kontrol edecek?</li> </ol> Sonuncusu özellikle kritik. Security community'nin henüz yeterince konuşmadığı bir konu. Ama yakında patlayacak. Şimdi ne yapmalısınız?</h2> Eğer bir API geliştiriyorsanız, bugün başlayın: Mevcut API'nize bir MCP endpoint'i ekleyin. 3-5 tool ile başlayın.</li> Her endpoint için explicit description ve input/output schema yazın. Sadece tip değil, gerçekten açıklayıcı metin.</li> Bir AI agent ile test edin. Claude Desktop'a MCP sunucunuzu bağlayın ve "kullanıcının son siparişini getir" deyin. Ne oluyor? Nerede takılıyor?</li> Permission modelini düşünün. Agent'ların neye erişebileceğini, neyi değiştirebileceğini belirleyin.</li> </ol> Gelecek agent-first. Şimdiden hazırlananlar, 2027'de bir adım önde olacak. Bu yazı RustAPI'nin MCP mimarisinden ve SemantiCAD'deki MCP kullanımından öğrendiklerimle yazıldı. Bir sonraki yazıda Hyperembed ve embedding inference motorunun nasıl çalıştığını anlatacağım. BareEngine: C++ ile Sıfırdan Oyun Motoru Yazmak Tunay Engin — Mon, 06 Jul 2026 00:00:00 +0000 Her şey 10 yıl önce başladı. Metin2 private server'lar, Knight Online emülatörleri, oyun sunucu toplulukları... 11 yaşında bir çocuk, bir oyunun nasıl çalıştığını anlamaya çalışıyordu. Packet'ları sniff ediyor, server emülatörleri yazıyor, C++ öğreniyordu. O çocuk bendim. Ve şimdi, 21 yaşında, aynı çocuğun hayalini gerçekleştiriyorum: BareEngine — kendi oyun motorum. Neden kendi oyun motorun?</h2> Hazır motorlar var: Unity, Unreal, Godot. Neden sıfırdan bir tane daha? Çünkü benim istediğim şeyi yapmıyorlar. Benim istediğim şey şu: bir editör açayım, birkaç model yerleştireyim, birkaç script yazayım, ve oyun sunucusu da otomatik oluşsun. Editör ve sunucu aynı toolchain'in parçası olsun. Unity'de bunu yapmak için Mirror, FishNet, Netcode for GameObjects gibi üçüncü parti kütüphaneler gerek. Ben bunu native istiyorum. Ayrıca, Metin2 ve Knight Online gibi oyunların kendine has bir "hissi" var. Kamera açısı, karakter kontrolü, combat sistemi, UI — bunların hepsi belli bir tarzda. Bu tarzı modern engine'lerde yakalamak zor. Çünkü onlar FPS veya açık dünya RPG'leri için optimize edilmiş. Ben Metin2 tarzı MMORPG'ler için optimize edilmiş bir motor istiyorum. O yüzden kendim yazıyorum. Mimari</h2> BareEngine üç ana bileşenden oluşuyor: ┌──────────────────────────────────────────┐ │ BareEditor (GUI) │ │ ┌─────────┐ ┌──────────┐ ┌──────────┐ │ │ │ World │ │ Asset │ │ Script │ │ │ │ Editor │ │ Browser │ │ Editor │ │ │ └─────────┘ └──────────┘ └──────────┘ │ ├──────────────────────────────────────────┤ │ BareEngine (Core) │ │ ┌─────────┐ ┌──────────┐ ┌──────────┐ │ │ │Renderer │ │ Physics │ │ Audio │ │ │ │(OpenGL) │ │(Bullet) │ │(OpenAL) │ │ │ └─────────┘ └──────────┘ └──────────┘ │ ├──────────────────────────────────────────┤ │ BareServer (Sunucu) │ │ ┌─────────┐ ┌──────────┐ ┌──────────┐ │ │ │Network │ │ Game │ │ DB │ │ │ │(ENet) │ │ Logic │ │(SQLite) │ │ │ └─────────┘ └──────────┘ └──────────┘ │ └──────────────────────────────────────────┘ </code></pre> BareEditor: ImGui tabanlı masaüstü editör. World editörü (terrain, obje yerleştirme), asset browser (model, texture, ses), script editörü (Lua entegrasyonu). Editörün kendisi editör öncelikli — yani ürün editör, oyun çıktısı yan ürün. BareEngine (Core): Renderer (OpenGL), fizik motoru (Bullet Physics), ses (OpenAL). Hepsi C++ ile, hepsi native. BareServer: Oyuncuların bağlandığı sunucu. ENet (reliable UDP), game logic (C++), veritabanı (SQLite). Sunucu, editörden export edilen dünya dosyasını okuyor. Editör-first felsefesi</h2> Çoğu oyun motoru "engine-first"tir. Önce motoru yazarsın, sonra editörü eklersin. Ben tersini yapıyorum. BareEngine'de editör, motorun bir arayüzü değil — editör ürünün kendisi. Oyun yapımcısı editörü açar, dünyasını inşa eder, "Build"e basar, oyun çıkar. Tıpkı RPG Maker gibi. Ama RPG Maker'dan farklı olarak: Multiplayer native (MMORPG'ler için)</li> Performans odaklı (C++, OpenGL)</li> Script edilebilir (Lua)</li> Açık kaynak</li> </ul> Hedef kitle: Metin2, Knight Online, Silkroad tarzı oyunların private server toplulukları. Bu topluluklar yıllardır emülatörlerle, reverse-engine edilmiş server dosyalarıyla uğraşıyor. Onlara "kendi oyununu yap" diyen bir araç vermek istiyorum. Teknik kararlar</h2> Neden ImGui?</h3> Editör için ImGui (Dear ImGui) kullanıyorum. Qt değil, wxWidgets değil, ImGui. Sebebi: ImGui immediate mode. Her frame GUI'yi sıfırdan çiziyorsun. Bu, oyun motoru editörleri için mükemmel çünkü: Render state ile GUI state aynı yerde</li> Debugging kolay (her şey o an hesaplanıyor)</li> Performanslı (gereksiz state yok)</li> Portable (OpenGL, Vulkan, DirectX hepsinde çalışıyor)</li> </ul> Dezavantajı: "güzel" görünmüyor. Varsayılan ImGui teması... işlevsel diyelim. Ama bunu dert etmiyorum. Editör güzel görünmek zorunda değil, işlevsel olmak zorunda. Neden Bullet Physics?</h3> PhysX değil, Havok değil, Bullet. Sebebi: açık kaynak ve MMORPG'ler için yeterli. MMORPG fiziği, FPS fiziği gibi değildir. Ragdoll yok, destrucible environment yok. Sadece collision detection, basit rigid body, karakter kontrolü. Bullet bunların hepsini fazlasıyla yapıyor. Neden ENet?</h3> MMORPG sunucuları için TCP değil, UDP tabanlı bir protokol lazım. Hareket input'ları, combat event'leri — bunların hepsi düşük latency gerektiriyor. TCP'nin head-of-line blocking'i burada ölümcül. ENet, reliable UDP üzerine inşa edilmiş hafif bir kütüphane. Sıralı paket teslimatı, fragmentation, throttling — hepsi var. Ve en önemlisi: basit. Sadece bir .c</code> dosyası. Bağımlılık yok. Neden Lua?</h3> C++ ile oyun mantığı yazmak... mümkün ama pratik değil. Her değişiklikte recompile. Lua ile yazınca: Hot-reload (sunucuyu kapatmadan script güncelle)</li> Mod yapımcıları için erişilebilir</li> C++'tan daha güvenli (crash yapsa bile sunucu çökmez)</li> </ul> Lua bindings için Sol3 kullanıyorum. C++ ve Lua arasındaki köprüyü birkaç satırda kuruyor. Zorluklar</h2> 1. Editor-state senkronizasyonu. Editörde bir objeyi sürüklediğinizde, bu değişikliğin renderer'a, physics engine'e, network layer'a yansıması gerekiyor. Undo/redo yapınca hepsi geri alınmalı. Bu, command pattern ile çözülüyor ama implementasyonu detaylı. 2. Multiplayer senkronizasyonu. Bir oyuncu hareket ettiğinde, bu hareketin diğer oyunculara iletilmesi gerekiyor. Ama her hareketi gönderirseniz bant genişliği patlar. Client-side prediction + server reconciliation yapmanız gerek. Bu, FPS oyunlar için çözülmüş bir problem ama MMORPG'lerde ölçek farklı: yüzlerce oyuncu, binlerce entity. 3. Metin2 format uyumluluğu. Metin2'nin dosya formatları (.gr2</code> modeller, .dds</code> texture'lar, .msm</code> animasyonlar) dokümante edilmemiş. Reverse-engineering gerekiyor. Bu, zamanımın büyük kısmını alan kısım. 4. Cross-platform. Windows'ta geliştiriyorum ama Linux sunucularda çalışacak. OpenGL, ENet, Bullet — hepsi cross-platform. Ama build sistemi (CMake), dependency yönetimi (vcpkg), CI/CD — bunların hepsi platform başına özel konfigürasyon istiyor. Şu anki durum</h2> Proje çok erken aşamada. Şu an çalışanlar: OpenGL renderer (basic meshes, texture'lar)</li> ImGui editör arayüzü (world outliner, property editor)</li> ENet networking (bağlantı, mesajlaşma)</li> Temel Lua scripting (onPlayerJoin</code>, onChatMessage</code>)</li> </ul> Henüz çalışmayanlar (bir sonraki milestone): Asset import pipeline (.fbx</code>, .gltf</code>)</li> Physics (collision detection)</li> Animation system</li> Database persistence (karakter kaydetme)</li> Metin2 format parser'ları</li> </ul> Bu proje neden önemli?</h2> BareEngine ticari bir ürün değil. Bir tutku projesi. 11 yaşındaki halime bir mektup gibi. O çocuk, oyunların nasıl çalıştığını anlamak için packet'ları sniff ediyordu. Şimdi o çocuğa "işte böyle çalışıyor" diyebilecek bir şey inşa ediyorum. Açık kaynak. Herkes görsün, öğrensin diye. Ayrıca, Türkiye'de oyun geliştirme büyüyor. Ama çoğu stüdyo Unity/Unreal kullanıyor. Düşük seviyede, "motor nasıl çalışır"ı anlayan az. BareEngine, bu bilgiyi açık kaynakla yaymanın bir yolu. Deneyin</h2> git clone https://github.com/Tuntii/BareEngine cd BareEngine # Build (CMake + vcpkg): cmake -B build -S . --toolchain ... cmake --build build --config Release # Run editor: ./build/Release/BareEditor.exe </code></pre> Henüz "oyun yapılabilir" durumda değil. Ama yolda. Her commit, 11 yaşındaki halime bir adım daha yaklaştırıyor. Bu, serinin son yazısı değil. Sırada alexander-storage (self-hosted S3), IntentScript (LLM task runner) ve daha fazlası var. Takipte kalın. Hyperembed: Rust ile Embedding Inference Motoru Yazmak Tunay Engin — Mon, 06 Jul 2026 00:00:00 +0000 Bir embedding inference motoru yazmaya karar verdiğimde, insanlar "neden? sentence-transformers var zaten" dediler. Haklılardı. sentence-transformers</code> Python'da çalışıyor, 5000'den fazla model desteği var, PyTorch ekosistemi olgun. Ama benim derdim embedding yapmak değildi. Benim derdim embedding'i her yerde yapmaktı. Bir sunucuda değil, bir telefonda değil, gömülü bir cihazda değil — hepsinde. Tek bir binary ile. Sıfır Python bağımlılığıyla. Sıfır PyTorch bağımlılığıyla. Sıfır ONNX runtime ile. Pure Rust. Sadece Rust. İşte Hyperembed böyle doğdu. Problem: Embedding inference nerede?</h2> Bugün embedding inference şu yerlerde yapılıyor: Cloud API (OpenAI, Cohere, vb.): En kolayı. Ama network latency, API maliyeti, veri gizliliği sorunları var.</li> Sunucu tarafı (sentence-transformers + GPU): Daha iyi. Ama GPU lazım, Python runtime lazım, bellek yönetimi lazım.</li> Edge / On-device: Neredeyse imkansız. PyTorch mobile büyük, ONNX runtime ağır, model optimizasyonu karmaşık.</li> </ol> Hyperembed bu üçüncü kategoriyi hedefliyor: edge'de, on-device, gömülü sistemlerde embedding inference. Rust sayesinde. Nasıl çalışıyor?</h2> Bir embedding inference motoru şunları yapmalı: Tokenizer: Metni token'lara çevir (BERT tokenizer, WordPiece)</li> Model yükleme: BERT modelini yükle (ağırlıklar, config)</li> Forward pass: Token'ları modelden geçir, hidden states'i al</li> Pooling: Hidden states'ten tek bir embedding vektörü üret (mean pooling, cls token, vs.)</li> </ol> Hyperembed bunların hepsini sıfırdan, Rust ile implemente ediyor. Tokenizer (WordPiece)</h3> BERT tokenizer'ı implemente etmek, beklediğimden daha eğlenceliydi. WordPiece algoritması: Metni whitespace'lerden böl</li> Her kelimeyi, vocabulary'deki en uzun eşleşen subtoken'a böl</li> Bulunan subtoken'ları ID'lere çevir</li> Özel token'ları ekle ([CLS], [SEP])</li> </ol> Bunu Rust'ta yapmak için bir trie (prefix tree) kullandım. 30,000 token'lık bir vocabulary'de, subword tokenization mikrosaniyeler mertebesinde çalışıyor. Python'dan yaklaşık 50x daha hızlı — çünkü Python her token için string slicing yapıyor. Model yükleme</h3> BERT modelleri genelde iki formatta gelir: PyTorch (.bin): Saf — pickle + tensor'lar</li> ONNX (.onnx): Portable ama büyük</li> </ul> Hyperembed, PyTorch formatını doğrudan okuyor. torch.save()</code> ile kaydedilmiş tensor'ları Rust'ta parse edebilmek için pickle formatını implemente ettim. Python'daki pickle</code> modülünün yaptığını, Rust'ta sıfırdan yazdım. Bu ne kadar zordu? Oldukça. Pickle formatı, Python objelerini serileştirmek için tasarlanmış. Stack tabanlı bir VM gibi çalışıyor. OPCODE'lar var, memoization var, referans çözümleme var. Rust'ta bunu implemente etmek yaklaşık 2000 satır kod aldı. Ama sonuç: herhangi bir PyTorch BERT modelini, PyTorch olmadan yükleyebiliyorum. Forward pass</h3> İşin en kritik kısmı. Transformer forward pass: Input → Embedding → [Attention → FFN] × 12 → Pooling → Output </code></pre> Her katman matris çarpımı. Çok fazla matris çarpımı. 12 katmanlı BERT-base için: Her attention head: Q, K, V projeksiyonları (3 matris çarpımı)</li> Attention: Q @ K^T, softmax, sonra V ile çarp</li> FFN: 2 büyük matris çarpımı (768→3072, 3072→768)</li> </ul> Toplamda yaklaşık 110M parametre. Her forward pass milyarlarca floating-point işlemi. Bunu hızlı yapmak için: SIMD optimizasyonları: Rust'ın std::simd</code> modülünü kullanarak AVX2/NEON instruction'larıyla matris çarpımı</li> Cache-friendly bellek düzeni: Ağırlıkları row-major yerine column-major saklayarak cache locality'yi iyileştirme</li> Fused operations: LayerNorm + residual bağlantıyı tek geçişte yapma</li> Weight quantization: FP32 yerine INT8 quantization (isteğe bağlı, model boyutunu 4x küçültüyor)</li> </ol> Sonuç: sentence-transformers'tan (CPU modunda) yaklaşık 3-5x daha hızlı. GPU modunda değil tabii — CUDA kernel'leriyle rekabet edemem. Ama CPU'da, hele ki düşük güçlü bir ARM işlemcide, Hyperembed ciddi fark atıyor. Pooling</h3> BERT'in son hidden states'inden embedding vektörü üretmek için: CLS token pooling: [CLS] token'ının hidden state'ini al</li> Mean pooling: Tüm token'ların hidden state'lerinin ortalamasını al (padding token'lar hariç)</li> Max pooling: Maksimum değerleri al</li> </ul> Hyperembed hepsini destekliyor. Varsayılan mean pooling — çoğu kullanım senaryosu için en iyisi. Benchmark'lar</h2> Birkaç benchmark sonucu (MacBook M2, CPU only, batch size=1): Model</th> Framework</th> Latency (ms)</th> Memory (MB)</th></tr></thead> BERT-base</td> sentence-transformers (Python)</td> 45</td> 850</td></tr> BERT-base</td> ONNX Runtime (C++)</td> 28</td> 520</td></tr> BERT-base</td> Hyperembed (Rust)</td> 11</td> 180</td></tr> BERT-tiny</td> sentence-transformers (Python)</td> 12</td> 340</td></tr> BERT-tiny</td> Hyperembed (Rust)</td> 2.3</td> 65</td></tr> </tbody></table> ARM Cortex-A72 (Raspberry Pi 4): Model</th> sentence-transformers</th> Hyperembed</th></tr></thead> BERT-tiny</td> 380ms</td> 45ms</td></tr> </tbody></table> Gömülü cihazlarda fiyat farkı burada ortaya çıkıyor. Python runtime, GIL, garbage collector, dinamik tip kontrolü — hepsi ARM'de çok pahalı. Rust'ın sıfır-maliyetli abstraksiyonları, kaynak kısıtlı cihazlarda gerçek farkı yaratıyor. Semantic search pipeline</h2> Hyperembed'in asıl kullanım alanı: semantic search. Bir döküman koleksiyonunda, kullanıcının sorgusuna anlamsal olarak en yakın dökümanları bulmak. Pipeline: Tüm dökümanları Hyperembed ile vektörleştir</li> Vektörleri bir vector database'e yaz (Qdrant, Milvus, veya basit bir FAISS index)</li> Kullanıcı sorgusunu vektörleştir</li> Cosine similarity ile en yakın k dökümanı bul</li> </ol> Hyperembed'in Rust API'si: use hyperembed::{Embedder, EmbedderConfig}; let config = EmbedderConfig::default() .with_model("sentence-transformers/all-MiniLM-L6-v2")? .with_pooling(PoolingStrategy::Mean); let embedder = Embedder::new(config)?; let documents = vec![ "Rust programlama dili sistem programlama için tasarlanmıştır.", "Python veri bilimi ve makine öğrenmesinde popülerdir.", "JavaScript web tarayıcılarında çalışan bir dildir.", ]; let doc_embeddings = embedder.embed_batch(&documents)?; let query_embedding = embedder.embed("sistem programlama dili")?; let similarities: Vec<f32> = doc_embeddings.iter() .map(|d| cosine_similarity(&query_embedding, d)) .collect(); // → [0.92, 0.45, 0.31] — Rust en yakın, beklendiği gibi </code></pre> Local-first AI'nin geleceği</h2> Hyperembed, daha büyük bir vizyonun parçası: local-first AI. Bugün AI'nin %99'u cloud'da çalışıyor. OpenAI API, Anthropic API, Google Cloud AI. Bu model şu sorunları getiriyor: Gecikme: Her sorgu için network round-trip</li> Maliyet: Token başına ücret, scale ettikçe katlanıyor</li> Gizlilik: Verileriniz başkasının sunucusunda</li> Bağımlılık: API kapandığında uygulamanız çalışmaz</li> Offline: İnternet yoksa AI yok</li> </ol> Local-first AI, bu sorunların hepsini çözüyor. Model cihazınızda çalışıyor. Embedding'ler cihazınızda hesaplanıyor. Vector database cihazınızda çalışıyor (SQLite + sqlite-vec gibi). Hyperembed bu vizyonun embedding katmanı. Diğer katmanlar: Inference: llama.cpp, mistral.rs gibi local LLM runtime'ları</li> Vector storage: LanceDB, sqlite-vec</li> Orchestration: Kendi agent framework'ün</li> </ul> 2026'da, 7B parametreli bir LLM'i bir MacBook'ta çalıştırmak mümkün. 2027'de bir telefonda çalıştırmak mümkün olacak. Hyperembed bu geçişte embedding tarafını hallediyor — ve Rust'ta yazıldığı için, LLM runtime'larıyla aynı process'te, sıfır IPC overhead ile çalışabiliyor. Ne öğrendim?</h2> 1. Pickle formatı karanlık bir sanat. Python objelerini parse etmek için bir VM implemente etmek zorunda kalacağımı tahmin etmezdim. Ama oldu. Ve işe yarıyor. 2. SIMD, Rust'ta sandığınızdan daha erişilebilir. std::simd</code> nightly'de stabilize oluyor. Portable SIMD yazmak artık unsafe</code> ve inline assembly gerektirmiyor. 3. BERT inference, sandığınızdan daha basit. Transformer mimarisi karmaşık görünüyor ama aslında birkaç temel operasyonun tekrarı: matmul, softmax, layer norm, GELU. Bunları implemente ettiğinizde gerisi loop. 4. Rust, ML inference için underrated. Herkes Python + CUDA yazıyor ama CPU inference için Rust çok daha iyi. Bellek yönetimi, SIMD, sıfır-cost abstractions — hepsi inference latency'sini dramatik düşürüyor. Sırada ne var?</h2> v0.3 roadmap: daha fazla model mimarisi: RoBERTa, DistilBERT, MiniLM</li> GGUF format desteği: llama.cpp'nin kullandığı quantization formatı</li> WASM target: Tarayıcıda embedding inference (!)</li> Python binding: pip install hyperembed</code> ile Python'dan kullanılabilir olacak</li> ONNX export: Kendi modelini ONNX olarak dışa aktarma (tersi: ONNX → Hyperembed)</li> </ul> Deneyin</h2> git clone https://github.com/neuralforgeone/hyperembed cd hyperembed cargo build --release cargo run --example semantic_search </code></pre> Henüz crates.io'da değil. Ama yakında cargo add hyperembed</code> yazabileceksiniz. Sonraki yazıda BareEngine'i anlatacağım — Metin2 tarzı MMORPG dünyaları için editor-first oyun motoru. 10 yıl önce başladığım yere, oyun sunucularına, C++ ile geri dönüş. KayaDB: Sıfırdan Dağıtık Veritabanı Yazmak Tunay Engin — Mon, 06 Jul 2026 00:00:00 +0000 Dağıtık sistemler, yazılım mühendisliğinin Everest'i gibidir. Herkes zirveyi görür, çok azı tırmanır. Ben tırmanmaya karar verdim. Sonuç: KayaDB — Rust ile yazılmış, Raft tabanlı, production'a hazırlanan dağıtık bir key-value depolama motoru. Bu yazı, o tırmanışın günlüğü. Neden kendi veritabanımı yazdım?</h2> Dürüst cevap: porque puedo. (Çünkü yapabiliyorum.) Ciddi cevap: Etcd var, Tikv var, FoundationDB var. Ama hiçbiri benim istediğim gibi değildi. İstediğim şey: Sıfır operasyonel yük. Bir binary indir, çalıştır. Config dosyası yok, YAML cehennemi yok.</li> Gömülebilir. Library olarak kullanılabilmeli. kayadb = "0.1"</code> yazıp kendi uygulamana gömebilmelisin.</li> Jepsen-tested. Kyle Kingsbury'nin testlerinden geçmemiş hiçbir dağıtık sistem iddiası ciddiye alınamaz.</li> Rust. Elle bellek yönetimiyle uğraşmadan C++ performansı.</li> </ul> Bunların hepsini aynı anda veren bir şey yoktu. Ben de yaptım. Mimari</h2> KayaDB'nin kalbinde Raft consensus algoritması var. Raft, dağıtık sistemlerde leader election, log replication ve safety garantilerini sağlayan en anlaşılır consensus protokolü — Paxos'un "insan tarafından anlaşılabilir" versiyonu. Üç temel katman: ┌─────────────────────────────────┐ │ Client API (gRPC) │ ├─────────────────────────────────┤ │ Raft Consensus Layer │ │ ┌─────────┐ ┌──────────────┐ │ │ │ Leader │ │ Follower x2 │ │ │ │ Election│ │ Log Repl. │ │ │ └─────────┘ └──────────────┘ │ ├─────────────────────────────────┤ │ Storage Engine (LSM-Tree) │ │ ┌─────────┐ ┌──────────────┐ │ │ │ MemTable│ │ SSTables │ │ │ └─────────┘ └──────────────┘ │ └─────────────────────────────────┘ </code></pre> Storage engine: LSM-tree (Log-Structured Merge-tree). Yazma ağırlıklı iş yükleri için optimize edilmiş. MemTable'da biriktir, belli boyuta ulaşınca SSTable olarak diske flush'la, arkada compaction yap. RocksDB'nin yaptığının daha basit, daha anlaşılır bir versiyonu. Raft katmanı: Leader seçer, log'ları replike eder, commit index'i ilerletir. Standard Raft — hiçbir sürpriz yok, spesifikasyona harfiyen uygun. Client API: Şimdilik gRPC. Gelecekte native TCP protokolü de gelecek. M1'den M13'e: 13 milestone, 6 ay</h2> Projeyi milestone'larla yönetiyorum. Her milestone birkaç hafta sürüyor ve somut bir çıktı veriyor. M1-M3 (Ocak 2026): Temel storage engine. Single-node, memory-only. put(key, value)</code> ve get(key)</code> çalışıyor. Heyecan verici değil ama temel. M4-M6 (Şubat): Persistence. WAL (Write-Ahead Log), MemTable flush, SSTable formatı. İlk defa restart'ta veri kaybetmemeye başladık. Bu hissi tarif edemem — yazdığınız kod, kapattığınız bir programın verisini geri getiriyor. M7-M9 (Mart): Raft implementasyonu. En zor kısım. Raft paper'ını yaklaşık 17 kez okudum. Leader election, log replication, snapshotting — her biri kendi içinde bir dünya. En büyük baş ağrısı: network partition simülasyonu. Test yazmak, implementasyondan daha zordu. M10-M12 (Nisan-Mayıs): Jepsen testleri. Kyle Kingsbury'nin meşhur dağıtık sistem test framework'ü. Linearizability, partition tolerance, clock skew — hepsini test ediyor. Ve ilk çalıştırmada... kırmızı. Her şey kırmızıydı. M13 (Haziran 2026): Production hazırlığı. Ve işte o an: 6/6 Jepsen gate'i yeşil. Jepsen'in yeşil vermesi, dağıtık sistemler dünyasında bir tür şövalyelik unvanı gibidir. "Senin sistemin, ağ bölündüğünde, disk çöktüğünde, saat kaydığında bile veri tutarlılığını koruyor" demektir. Jepsen'le dans</h2> Jepsen testleri yazmak, normal test yazmaya benzemez. Normal testte "şu input'a şu output" dersiniz. Jepsen'de "şu kaotik senaryoda sistemin davranışı linearizable mı?" dersiniz. Aradaki fark, deprem simülasyonuyla bina test etmek gibidir. Bir Jepsen testi şunları yapar: Bir küme başlatır (genelde 5 node)</li> Rastgele işlemler gönderir (append, read, cas)</li> Bu sırada nemesis'leri devreye sokar: partition-random-node: Ağı rastgele böler</li> kill-random-node: Rastgele node'u öldürür</li> clock-skew: Sistem saatini kaydırır</li> pause-random-node: Node'u dondurur (SIGSTOP)</li> </ul> </li> Test sonunda tüm işlem geçmişini analiz eder</li> "Bu geçmiş lineerize edilebilir mi?" sorusunu cevaplar</li> </ol> Eğer cevap "hayır" ise, bir yerde tutarlılık garantisini ihlal etmişsinizdir. Ve inanın, ilk denemede cevap her zaman "hayır"dır. Benim en büyük hatam neydi? fsync'i atlamak. İtiraf ediyorum: WAL yazarken fsync()</code> çağırmayı unutmuştum. Veriyi write()</code> ile yazıyordum, sayfa önbelleğinde duruyordu, diskte değil. Node crash olduğunda... WAL boştu. Jepsen bunu hemen yakaladı: "Senin sistemin durability garantisi yok." Fix: Her WAL yazımından sonra fsync()</code>. Performans düştü mü? Evet, %30. Ama veri kaybetmemeye başladık. Trade-off buydu. Bir diğer hata: Read Index optimizasyonunu yanlış implemente etmek. Raft'ta read'ler için leader'a gitmek gerekir, ama her read için bir log entry yazmak pahalıdır. Read Index tekniği, read'leri log yazmadan güvenli hale getirir. Ama ben lease süresini yanlış hesaplamıştım — partitioned leader hala "ben leader'ım" sanıp stale read dönebiliyordu. Jepsen: kırmızı. Fix: Lease tabanlı leader kontrolü + her read öncesi heartbeat confirmation. Böyle 11 tane Jepsen hatası yakaladım. Her biri ayrı bir ders. Ne öğrendim?</h2> 1. Dağıtık sistemlerde "works on my machine" diye bir şey yoktur. Network partition'da, disk hatasında, clock skew'de çalışmayan kod, çalışmıyordur. Jepsen bunu suratınıza vurur. 2. Raft paper'ını okumak yetmez, implemente etmek gerekir. Leader election'ın ne kadar edge case içerdiğini, paper'ın 5. sayfasındaki bir cümlenin ne anlama geldiğini ancak implemente ederken anlıyorsunuz. 3. fsync her şeydir. Durability = fsync. Başka yolu yok. Ne kadar batch yaparsanız yapın, eninde sonunda o sistem çağrısını yapmak zorundasınız. 4. Test altyapısı, ürün kodundan daha önemlidir. KayaDB'nin test kodu, ürün kodundan daha fazla satır. Network partition simülasyonları, fault injection, chaos engineering — hepsi test tarafında. Sırada ne var?</h2> M14 — Jepsen test suite final + prod deployment. Hedef: kendi makinemde değil, gerçek bir sunucuda, gerçek trafik altında KayaDB çalıştırmak. Sonrası: gRPC API stabilizasyonu</li> Rust client library (kayadb-client</code>)</li> Go client library (belki)</li> Benchmark'ları yayınlamak — etcd, Tikv ile karşılaştırmalı</li> </ul> Deneyin</h2> git clone https://github.com/Tuntii/KayaDB cd KayaDB cargo build --release ./target/release/kayadb --id node1 --peers node2:5001,node3:5001 </code></pre> 3 node, 3 terminal, Raft cluster'ınız hazır. GitHub: github.com/Tuntii/KayaDB</a> Dokümantasyon: tuntii.github.io/KayaDB</a> Dağıtık sistemler zor. Ama yapılabilir. Ve yapınca, bilgisayar biliminin en temel problemlerinden birini kendi ellerinizle çözmüş oluyorsunuz. O his paha biçilemez. Bir sonraki yazıda Hyperembed'i anlatacağım — Pure-Rust BERT embedding inference motoru. Ya da belki SemantiCAD. Bakalım hangisi önce biter. Kendi Kendine Öğrenen Bir Founder'ın El Kitabı Tunay Engin — Mon, 06 Jul 2026 00:00:00 +0000 5 yaşında bilgisayarla tanıştım. İlk kodumu C++ ile yazdım. Oyun sunucu altyapılarıyla başladım — Metin2 private server'lar, Knight Online emülatörleri. 12 yaşında siber güvenlik forumlarında takılıyordum. 15 yaşında ilk şirketimi kurdum. 21 yaşında bu yazıyı yazıyorum. Bu bir başarı hikayesi değil. Bu bir hayatta kalma hikayesi. Okul? Hayır, teşekkürler.</h2> İki üniversite denedim. İkisini de bıraktım. İstanbul Üniversitesi Yönetim Bilişim Sistemleri — sıkıcıydı. Trakya Üniversitesi Bilgisayar Programcılığı — yavaştı. Sorun okulda değildi bende değildi. Sorun tempodaydı. Ben bir şey öğrenmek istediğimde o gece başlarım, sabaha karşı bitiririm. Okul bana "bu konuyu 14 haftada işleyeceğiz" diyordu. 14 hafta? Ben 14 saatte Rust'ın borrow checker'ını çözmüştüm. Formal eğitim almadım diye eksik hissettiğim oldu mu? Hayır. Çünkü öğrenmenin tek bir yolu yok. Benim yolum: problemi bul, çözmek için ne gerekiyorsa öğren, çöz, sonrakine geç. Buna "just-in-time learning" diyorlar. Ben "aç kalınca yemek yapmayı öğrenmek" diyorum. Stack'im: ne işe yararsa</h2> Tek bir stack'e bağlı değilim. Proje ne gerektiriyorsa onu kullanırım. Rust: Performans gerektiren her şey. Web framework'ü mü? RustAPI. Veritabanı mı? KayaDB. Embedding inference mi? Hyperembed.</li> TypeScript: Hızlı prototip gerektiren her şey. Birçok prototip TypeScript ile başladı.</li> Python: AI/ML tarafında. SemantiCAD'in bazı parçaları, qec-playground.</li> Go: Arada ihtiyaç olursa. Alexander-storage mesela — Go ile yazıldı çünkü S3 server için Go'nun ekosistemi daha olgun.</li> C++: Geçmişten gelen. BareEngine oyun motoru C++ ile. Çünkü oyun motoru başka bir şeyle yazılmaz.</li> </ul> "Jack of all trades, master of none" diye bir laf vardır. Tamamı şöyle: "Jack of all trades, master of none, but oftentimes better than master of one." Benim felsefem bu. Tek bir şeyin uzmanı olmaktansa, her şeyi yeterince iyi bilip projeye göre derinleşmek. Projeler: nicelik mi, nitelik mi?</h2> 23 GitHub repom var. 20'si aktif. Her ay 2-3 yeni proje başlıyor, 1-2'si ölüyor. Bu normal. Açık kaynak dünyasında "bir tane büyük projen olsun" diye bir tavsiye var. Ben tersini yapıyorum. Bir sürü projem var, her biri farklı bir şey öğretiyor. RustAPI bana HTTP ve MCP öğretti. KayaDB dağıtık sistemleri. Hyperembed embedding modellerini. BareEngine oyun motoru mimarisini. Hepsi birbirini besliyor. KayaDB'de öğrendiğim fsync</code> optimizasyonunu RustAPI'nin file serving katmanında kullandım. RustAPI'deki MCP implementasyonunu SemantiCAD'e taşıdım. Hyperembed'deki SIMD optimizasyonlarını KayaDB'nin storage engine'ine uyarladım. Buna "cross-pollination" diyorum. Çok proje yapanların gizli silahı. Başarısızlıklar (bunlar önemli)</h2> Kimse başarısızlıklarından bahsetmez. Ben edeyim. Poise Labs (2022-2024): Kendi blockchain'imi yazdım. Diem (eski Libra) blockchain'inden fork'ladım, "Poisechain" dedim. Dubai'den yatırım aldık. 18 ay çalıştık. Battı. Sebep: pazar yoktu. Teknolojisi iyiydi ama kimsenin ihtiyacı yoktu. En pahalı dersim: teknoloji değil, problem çöz. THT dönemi (ergenlik): Siber güvenlik forumlarında tool yazıp dağıtıyordum. Bazıları ciddi araçlardı, bazıları... şey, hacktivist işleriydi. Neyse ki büyüdüm. Ama o dönem bana sistemlerin nasıl kırıldığını öğretti, ki bu da sistemlerin nasıl korunacağını öğrenmenin en iyi yolu. İlk şirket websitesi işi (15 yaş): Ceyhun'la (Ceyhun Kasım Arslan) Bones Interactive'i kurduk. Website satarak para kazanacaktık. İlk müşteriye sattık, parayı aldık, sevindik. Sonra ikinci müşteri gelmedi. Üç ay bekledik. Pivot: ERP yazılımı. O da tutmadı. Pivot: gömülü sistemler. O da tutmadı. Ama her pivot yeni bir şey öğretti. Ve sonunda bir şey tuttu. Para meselesi</h2> Dürüst olayım: para kazanmıyorum. Henüz. RustAPI'nin 55 star'ı var. KayaDB'nin 4. Coverium'un 1. Bunların hiçbiri fatura ödemiyor. Ama plan şu: RustAPI Cloud. Managed hosting. Bedava tier + pro tier. Vercel modeli. Eğer RustAPI'yi 1000 developer kullanıyorsa ve %5'i pro tier'a geçerse, temel ihtiyaçları karşılar. Hedef 2026 sonu. Bu arada? Hayatta kalıyorum. Ailem destek oluyor. Freelance işler alıyorum. Daha önce Solana'da, Aptos'ta, birkaç şirkette çalıştım — kenara biraz para koydum. Şimdi onu yakıyorum. Buna "ramen profitability" diyorlar. Ben "bir tabak makarna + bir proje" diyorum. Günlük rutin (rutin denen şey)</h2> Sabit bir rutinim yok. Bazı günler 04:00'te kalkıp 22:00'ye kadar çalışıyorum. Bazı günler öğlen kalkıp gece 03:00'e kadar çalışıyorum. Enerji neredeyse, oradayım. Kalkar kalkmaz bilgisayar başına geçerim. Kahvaltı? Bazen. Öğle yemeği? Bilgisayar başında. Akşam? Dışarı çıkmadıysam yine bilgisayar başında. Bu sağlıklı değil. Biliyorum. Ama projeler bitmeden, para kazanmaya başlamadan, rahat edemiyorum. Bu bir yarış değil, bu bir hayatta kalma modu. Ve o modda, rutin lükstür. Öğrendiğim 7 şey (şimdiye kadar)</h2> Problemi bul, çözümü değil. Çoğu geliştirici tersini yapar: bir teknoloji seçer, ona problem arar. Önce acıyı bul, sonra ilacı.</li> Ship early, ship often. İlk versiyon berbat olacak. Olsun. Kullanıcı feedback'i olmadan mükemmel ürün yapamazsın.</li> Tek başına olmaz. Ceyhun olmasaydı Bones Interactive olmazdı. Açık kaynak contributor'lar olmasa RustAPI bugünkü haline gelmezdi. İnsanlarla çalış.</li> İngilizce şart. Türkçe kaynaklar sınırlı. RFC'ler, paper'lar, dokümantasyon — hepsi İngilizce. Öğrenmek zorundasın.</li> Derine in. Bir şeyi gerçekten anlamak istiyorsan implemente et. Raft'i anlamak için Raft implemente ettim. HTTP'yi anlamak için HTTP implemente ettim. BERT'i anlamak için BERT implemente ettim.</li> Sağlığını ihmal etme. (Bunu henüz öğrenmedim, teorik olarak biliyorum.)</li> Neden'ini bil. Neden kod yazıyorsun? Para için mi, öğrenmek için mi, dünyayı değiştirmek için mi? Benimki: anlamlı bir şey üretmek. Boş iş yapmaya tahammülüm yok.</li> </ol> Sırada ne var?</h2> Kısa vade: para kazanmak. RustAPI Cloud, belki birkaç danışmanlık işi, belki sponsorluk. Orta vade: yatırım almak. Ama sadece doğru yatırımcıdan. Vizyonumu anlayan, "3 ayda exit" demeyen birinden. Uzun vade: mutlu olmak. Bu kadar. Gerisi detay. Bu yazıyı, benzer yoldan geçenler için yazdım. Kendi kendine öğrenen, okulu bırakan, "acaba yanlış mı yapıyorum" diye düşünen herkes için. Doğru yol yok. Sadece senin yolun var. Yürümeye devam et. Sonraki yazıda SemantiCAD'i anlatacağım — AI destekli üretim planlaması, Sovereign Hybrid mimarisi ve Türk imalat atölyelerine teknoloji götürme çabası. Quantum Computing'e Rust ve Python ile Giriş: QuantumNN ve qec-playground Tunay Engin — Mon, 06 Jul 2026 00:00:00 +0000 2026'nın başında bir gece, saat 02:00 civarı, arXiv'de bir paper okudum: Li & Martonosi'nin SWIPER-SIM behavioral model'i — kuantum hata düzeltme kodlarının spekülatif pencere dekoder analizi. Paper'ı anlamam 4 saat sürdü. Implemente etmem 2 hafta. Sonuç: qec-playground</code> — dünyanın ilk open-source SWIPER-SIM simülatörü. Ve yan ürün olarak QuantumNN</code> — kuantum nöral ağlar üzerine bir deney alanı. Bu yazı, o 2 haftanın ve sonrasının hikayesi. Neden kuantum?</h2> Dürüst olayım: çünkü havalı. Ciddi cevap: çünkü klasik bilgisayarların çözemediği problemler var. Integer factorization (Shor), unstructured search (Grover), quantum simulation (Feynman'ın orijinal motivasyonu). Ve bu problemler, kuantum bilgisayarlar yaygınlaştığında birdenbire çözülebilir hale gelecek. Ama asıl sebep şu: kuantum computing, bilgisayar biliminin son frontier'ı. Yapay zeka patladı, dağıtık sistemler olgunlaştı, WebAssembly standartlaştı. Ama kuantum? Hala her şeyin başındayız. 2026'da kuantum programlama öğrenmek, 1995'te web geliştirme öğrenmek gibi. Erken giren kazanır. Ben erken giren olmak istedim. qec-playground: SWIPER-SIM'i implemente etmek</h2> Li & Martonosi'nin paper'ı (arXiv:2606.24048) şunu söylüyor: kuantum hata düzeltme kodlarının (QEC) en büyük problemi, decoding latency. Bir kuantum işlemci çalışırken, hata düzeltme kodunun decode edilmesi zaman alıyor. Ve kuantum bit'ler (qubit'ler) decohere olmadan önce sınırlı bir zaman pencereniz var. SWIPER (Sliding Window Interleaved Parallel Error Resolution), bu decoding işlemini spekülatif olarak paralelleştiren bir teknik. Fikir şu: hata düzeltme kodunun tümünü beklemek yerine, sliding window ile parça parça decode et, ve spekülatif olarak bir sonraki window'u tahmin et. Paper teorikti. Bir simülasyon framework'ü tarif ediyordu ama implementasyon yoktu. "Birisi bunu yazmalı" dedim. O birisi bendim. Teknik detaylar</h3> qec-playground şunları yapıyor: Kuantum devre simülasyonu — Qubit'leri, gate'leri, measurement'ları klasik bilgisayarda simüle ediyor. (Gerçek kuantum bilgisayar değil, simülasyon — ama algoritma geliştirmek için yeterli.)</li> Hata modelleme — Bit-flip, phase-flip, depolarizing channel gibi kuantum hata modellerini enjekte ediyor.</li> SWIPER decoder implementasyonu — Paper'daki sliding window algoritmasını birebir implemente ettim. Pencere boyutu, overlap miktarı, spekülatif tahmin parametreleri — hepsi ayarlanabilir.</li> Streamlit arayüzü — Web tabanlı, interaktif. Parametreleri slider'larla değiştirip sonucu anında görebiliyorsunuz.</li> Metrik analizi — Decoding latency, logical error rate, pseudo-threshold — paper'daki tüm metrikleri hesaplıyor.</li> </ol> Kod tarafında Python + Streamlit. Oldukça basit bir stack. Çünkü burada zor olan kod değil, fizik. Kuantum mekaniğini anlamak, stabilizer formalizmini çözmek, surface code'ların nasıl çalıştığını kavramak — asıl iş buydu. Öğrendiklerim</h3> Kuantum hata düzeltme, klasik hata düzeltmeden tamamen farklı. Klasikte bit flip'leri düzeltirsiniz. Kuantumda hem bit flip hem phase flip var, ölçüm yapmak durumu bozuyor, no-cloning theorem yüzünden kopyalayamıyorsunuz. Tamamen farklı bir dünya. </li> Stabilizer formalizmi güzel. Gottesman-Knill teoremi sayesinde stabilizer devrelerini klasik bilgisayarda verimli şekilde simüle edebiliyorsunuz. Paper'daki matematiksel formalizmi koda dökmek, başlangıçta imkansız gibi görünüyordu. Ama oturup satır satır çalışınca, aslında çok zarif bir sistem olduğunu gördüm. </li> Streamlit, bilimsel simülasyonlar için mükemmel. Jupyter notebook'tan daha iyi bir UX sunuyor. Parametre değiştir, anında gör. Paper yazarlarına göstermek için ideal. </li> Açık kaynak, akademik dünyada hızla yayılıyor. Projeyi GitHub'a koyduktan sonra 3 gün içinde bir kuantum computing araştırmacısı issue açtı: "Bunu surface code rotasyonu için de uyarlayabilir miyiz?" Cevap: evet, çalışıyorum. </li> </ol> QuantumNN: Kuantum nöral ağlar</h2> qec-playground'u yazarken bir yan etki oldu: kuantum devre simülasyonu altyapısı hazırdı. "Bunu nöral ağlar için de kullanabilir miyim?" dedim. Cevap evetti. Ortaya QuantumNN çıktı. QuantumNN, klasik nöral ağ katmanlarını kuantum devrelerle değiştiren bir framework. Fikir: Klasik bir nöral ağ katmanı yerine bir variational quantum circuit (VQC) kullan</li> Devrenin parametrelerini gradient descent ile optimize et</li> Klasik-kuantum hibrit bir model elde et</li> </ul> Ne işe yarıyor?</h3> Teorik olarak, kuantum nöral ağlar şu avantajlara sahip: Daha az parametreyle daha yüksek expressiveness. Bir kuantum devresi, klasik bir nöral ağ katmanından exponansiyel olarak daha fazla durumu temsil edebilir (Hilbert uzayının boyutu sayesinde).</li> Doğal kuantum veri işleme. Kuantum sensörlerden gelen veriler, klasik ön işleme olmadan doğrudan kuantum modele beslenebilir.</li> Kuantum avantajı potansiyeli. Henüz pratikte gösterilmedi (NISQ dönemindeyiz), ama teorik olarak bazı problemlerde klasik modellerden üstün olabilir.</li> </ol> Pratikte? Henüz emin değilim. QuantumNN bir deney alanı. MNIST üzerinde klasik bir CNN'in %99 doğruluk aldığı yerde, quantum NN %92 alıyor. Ama 10x daha az parametreyle. Bu ilginç. Teknik yapı</h3> QuantumNN şu bileşenlerden oluşuyor: from quantumnn import QuantumLayer, HybridModel # Kuantum katman: 4 qubit, 3 katmanlı variational circuit qlayer = QuantumLayer(n_qubits=4, n_layers=3, encoding="angle") # Hibrit model: klasik dense + kuantum + klasik dense model = HybridModel([ torch.nn.Linear(784, 16), qlayer, torch.nn.Linear(4, 10) ]) </code></pre> encoding="angle"</code>, klasik veriyi qubit rotasyon açılarına encode ediyor. Başka encoding stratejileri de var: amplitude encoding (daha verimli ama daha karmaşık), basis encoding (basit ama az bilgi taşır). Optimizasyon: parametre shift rule ile gradient hesaplama. Kuantum devrelerde backpropagation çalışmaz — her parametre için devreyi iki kez çalıştırıp farkı almanız gerekir. Bu, classical simulation'da bile yavaş. Gerçek kuantum donanımda daha da yavaş olacak. Ama işte araştırma bu: yavaş ve zor. Önemli olan başlamak. NISQ dönemi ve gerçekler</h2> Şu an NISQ (Noisy Intermediate-Scale Quantum) dönemindeyiz. Bu şu demek: Noisy: Qubit'ler gürültülü. Hata oranları yüksek. 100 qubit'lik bir devrede, her gate'te %0.1 hata olsa, devrenin doğru çalışma olasılığı çok düşük.</li> Intermediate-Scale: 50-1000 qubit arası cihazlar var (IBM, Google, Rigetti). Ama hata düzeltme yok. "Logical qubit" başına binlerce fiziksel qubit gerekiyor.</li> Quantum advantage: Google 2019'da "quantum supremacy" iddia etti. IBM itiraz etti. 2024'te tekrar denediler. Tartışma hala sürüyor.</li> </ul> Benim bu alana girmemin sebebi tam da bu: erken. Henüz kimse "quantum developer" değil. Herkes öğreniyor. Ve ben de öğrenenlerden biriyim. Sırada ne var?</h2> qec-playground: Surface code rotasyon simülasyonu</li> Color code desteği</li> Gerçek IBM Quantum backend ile test (IBM Q Experience API)</li> Daha fazla decoder algoritması: MWPM, Union-Find, belief propagation</li> </ul> QuantumNN: Daha büyük modeller (8-12 qubit)</li> Gerçek kuantum donanımda test (IBM, Rigetti)</li> Quantum transfer learning deneyleri</li> QML benchmark'larına katılım</li> </ul> Deneyin</h2> # qec-playground git clone https://github.com/SemantiCAD/qec-playground cd qec-playground pip install -r requirements.txt streamlit run app.py # QuantumNN git clone https://github.com/Tuntii/QuantumNN cd QuantumNN pip install -r requirements.txt python examples/mnist_hybrid.py </code></pre> İkisi de public repo. İkisi de deneysel. İkisi de "production-ready" değil — ama olmaları da gerekmiyor. Araştırma kodunun güzel olması gerekmez, çalışması yeter. Kuantum computing, kariyerimin en zor öğrenme deneyimi. Ama aynı zamanda en ödüllendiricisi. Eğer siz de merak ediyorsanız, bir paper alın ve implemente edin. En iyi öğrenme yöntemi bu. Sonraki yazıda Hyperembed'i anlatacağım — Pure-Rust BERT embedding inference motoru, SIMD optimizasyonları ve local-first AI. RustAPI: FastAPI'ye Rust'tan Bir Cevap Tunay Engin — Mon, 06 Jul 2026 00:00:00 +0000 Aralık 2025'te bir soruyla başladı her şey: "FastAPI'nin yaptığını Rust'ta neden kimse yapmadı?" Cevap aslında vardı. Axum var, Actix var, Poem var. Hepsi iyi framework'ler. Ama hiçbiri FastAPI'nin o "elinin altında hissettiren" ergonomisine sahip değildi. Hiçbiri size app.get("/")</code> yazıp üç satırda bir endpoint oluşturma hissini vermiyordu. Ve daha önemlisi — hiçbiri AI/LLM dünyasını birinci sınıf vatandaş olarak görmüyordu. Ben de yaptım. Hikaye</h2> 2025'in son çeyreğiydi. Bir sürü paralel proje dönüyordu — SemantiCAD'in Rust tarafı, Hyperembed'in embedding inference motoru, birkaç LLM tool'u derken sürekli aynı şeyi yazdığımı fark ettim: HTTP endpoint'leri. Her projede sıfırdan route tanımlıyor, middleware yazıyor, error handling yapıyordum. Toxic bir pattern'di bu — DRY'nin tam tersi. "Bir tane yapayım, her yerde kullanayım" dedim. İlk commit 15 Aralık 2025. Adını RustAPI koydum. Düz, açıklayıcı, iddialı. İlk versiyon berbattı. Sadece app.get()</code> ve app.post()</code> çalışıyordu. Ama çalışıyordu. Ve en önemlisi — Rust'ta bu kadar basit bir API yoktu. Ne yaptığını anlatayım</h2> RustAPI, FastAPI'nin Python'da yaptığını Rust'ta yapıyor. Ama birkaç ekstra katmanla: Makro tabanlı route tanımı. Bir attribute yazıyorsunuz, fonksiyonunuz bir endpoint oluyor: #[get("/hello/{name}")] async fn hello(name: String) -> String { format!("Merhaba, {}!", name) } </code></pre> Path parametreleri, query parametreleri, request body — hepsi otomatik çözülüyor. FastAPI kullanıcısıysanız evinizde hissedeceksiniz. Native MCP (Model Context Protocol) desteği. Burası işin en ilginç kısmı. RustAPI ile yazdığınız her endpoint, otomatik olarak bir MCP tool'u haline gelebiliyor. Yani bir AI agent, sizin API'nizi doğrudan çağırabiliyor. Bunu yapmak için: #[get("/weather/{city}")] #[mcp_tool(description = "Get weather for a city")] async fn weather(city: String) -> Json<WeatherResponse> { // ... } </code></pre> Bu kadar. #[mcp_tool]</code> attribute'u, endpoint'inizi Anthropic'in MCP spesifikasyonuna uygun bir tool tanımına dönüştürüyor. Claude, GPT, Gemini — hepsi bu endpoint'i kendi tool'u gibi çağırabiliyor. Bunun ne kadar büyük bir şey olduğunu anlatayım. Agent-first API tasarımı</h2> Şimdiye kadar API'ler insanlar için tasarlanırdı. RESTful, iyi dokümante edilmiş, Swagger/OpenAPI ile beslenmiş. Developer experience ön plandaydı. Ama dünya değişiyor. 2026'da API'lerin tüketicileri artık sadece insanlar değil — AI agent'lar da API çağırıyor. Ve bir AI agent'ın bir API'den beklentisi, bir insan developerdan çok farklı. İnsan developer için: "Şu endpoint'i çağır, şu header'ı ekle, response'u parse et." AI agent için: "Ne işe yaradığını söyle, parametreleri tanımla, ben çağırayım." RustAPI'deki MCP desteği tam olarak bu zihniyet değişimini temsil ediyor. Her endpoint, doğuştan agent-readable. Sıfır ek iş. #[mcp_tool]</code> eklediğiniz an, endpoint'iniz Claude'un tool registry'sine düşüyor. Buna "agent-first API design" diyorum. Ve bence 2026-2027'nin en büyük API trend'i bu olacak. Teknik detaylar (meraklısına)</h2> İşin arka planında neler dönüyor kısaca: HTTP katmanı: Kendi HTTP/1.1 implementasyonumu yazdım. Evet, sıfırdan. hyper</code> veya actix-http</code> kullanmadım. Sebebi basit: bağımlılık zincirini sıfırlamak. Bugün RustAPI'nin toplam bağımlılık sayısı inanılmaz düşük. Bu, compile süresini kısaltıyor, binary boyutunu küçültüyor ve en önemlisi — her şeyin nasıl çalıştığını biliyorum.</li> MCP katmanı: JSON-RPC 2.0 üzerinden MCP spesifikasyonunu implemente ediyor. Tool listeleme, tool çağırma, hata yönetimi — hepsi spec-compliant.</li> Permission scoping: v0.1.508 ile gelen en kritik özellik. Hangi agent hangi endpoint'i ne kadar çağırabilir? Rate limiting? Scope kısıtlaması? Hepsi yapılandırılabilir.</li> Cloud CLI: rustapi deploy</code> yazıyorsunuz, projeniz canlıya çıkıyor. Vercel modelini Rust ekosistemine taşıma hedefi.</li> </ul> Şu an v0.1.528'deyiz. 55+ GitHub star, 3 fork. Küçük sayılar gibi görünüyor ama Rust ekosisteminde bir web framework için hiç fena değil — hele 7 ayda. Performans</h2> Lafı uzatmayayım. Benchmark sonuçları: Framework</th> Request/sec (hello world)</th> P99 latency</th></tr></thead> FastAPI (Python)</td> ~14,000</td> ~8ms</td></tr> Express (Node)</td> ~24,000</td> ~5ms</td></tr> Actix-web (Rust)</td> ~180,000</td> ~0.6ms</td></tr> RustAPI (Rust)</td> ~210,000</td> ~0.5ms</td></tr> </tbody></table> MCP invocation tarafında daha da çılgın: 28 mikrosaniye. Evet, mikrosaniye. Bir MCP aracını çağırmak, bir Python fonksiyon çağrısından daha hızlı. Bunlar "hello world" benchmark'ları, gerçek dünyada fark daha da açılıyor çünkü Rust'ın sıfır-maliyetli abstraksiyonları gerçek iş yüklerinde asıl farkı yaratıyor. Nereye gidiyor?</h2> Yol haritası net: RustAPI Cloud (Q3 2026) — Managed hosting. rustapi deploy</code> ile tek komutta deployment. Bedava tier + pro tier. Vercel'in Rust versiyonu.</li> MCP Gateway (Q4 2026) — Tüm deployed API'lerinizi tek bir MCP endpoint'inde toplayan gateway. Bir AI agent tek bir URL'den yüzlerce API'ye erişebilecek.</li> Plugin ekosistemi — Auth plugin'leri, rate limiting, caching, monitoring. Topluluk katkısına açık.</li> gRPC + WebSocket — HTTP'nin ötesine geçmek. Agent'lar bazen streaming ister.</li> </ol> Öğrendiğim şeyler</h2> Sıfırdan bir web framework yazmak, size HTTP'nin içini dışını öğretiyor. Keep-alive bağlantılar, chunked transfer encoding, pipeline requests — hepsini implemente etmek zorunda kalıyorsunuz. RFC okumaktan gözlerim bozuldu diyebilirim. Ama en büyük öğrendiğim şey şu: Rust'ta ergonomi, sıfır maliyetle gelmiyor. Makro sistemi sayesinde Python'daki kadar temiz bir API sunabiliyorsunuz, ama arka planda her şey statik olarak çözülüyor. Runtime overhead yok. Bu, Rust'ın süper gücü. İkinci büyük ders: Açık kaynak, compound interest gibidir. İlk 3 ay kimse bakmadı. Sonra bir blog yazısı yazdım, Hacker News'te paylaştım, bir anda 30 star geldi. Şimdi her hafta birkaç kişi issue açıyor, PR gönderiyor. Yavaş ama istikrarlı büyüyor. Deneyin</h2> cargo install rustapi rustapi new my-project cd my-project rustapi dev </code></pre> 3 komut, 10 saniye. Sonra geliştirmeye başlayın. Website: rustapi.cloud</a> GitHub: github.com/Tuntii/RustAPI</a> Dokümantasyon: tuntii.github.io/RustAPI</a> Eğer Rust yazıyorsanız ve API geliştiriyorsanız, bir şans verin. Beğenmezseniz issue açın — ciddiyim, her feedback'i implemente etmeye çalışıyorum. Sonraki yazıda KayaDB'yi anlatacağım — sıfırdan dağıtık bir key-value store yazmak nasıl bir deneyim, Raft consensus implemente etmek, Jepsen testleri... O daha da çılgın. İlk Yazı: Bu Blog Neden Var? Tunay Engin — Sun, 05 Jul 2026 00:00:00 +0000 Merhaba! Bu, tuntii.com üzerindeki ilk yazım. Neden bir blog?</h2> İnternetin kurumsal, steril halinden biraz uzaklaşmak istedim. IndieWeb ruhuna uygun, el yapımı hissettiren bir köşe — tıpkı daudix.one</a> gibi. Ne yazacağım?</h2> Teknoloji notları</li> Kişisel düşünceler</li> Projelerimden kesitler</li> Belki biraz saçma mizah</li> </ul> fn main() { println!("Hello, tuntii.com!"); } </code></pre> Daha fazlası yakında. Takipte kalın! Zola ile Statik Blog Kurmak Tunay Engin — Sat, 04 Jul 2026 00:00:00 +0000 Bu site Zola</a> ile inşa edildi — Rust ile yazılmış, hızlı ve basit bir statik site generator. Neden Zola?</h2> Hız — Build süreleri milisaniyeler</li> Güvenlik — Statik HTML, sunucu tarafı risk yok</li> Basitlik — Markdown + Tera şablonları</li> Tek binary — Kurulumu kolay</li> </ol> Temel yapı</h2> content/ → Markdown yazılar templates/ → HTML şablonları static/ → CSS, JS, görseller config.toml → Site ayarları </code></pre> zola build</code> komutu ile public/</code> klasörü oluşur ve nginx'e servis edilir. Basit, etkili, güzel.

Tuntii — Tunay Engin - Blog

Viltrum: V ile Kendi HTTP Engine'imi Yazdım

Yazılıma Nasıl Başlarım — 2026 Edition

Agent-First Mimari: API'lerin Geleceği MCP

Agent-first API tasarımının 5 prensibi</h2>
RustAPI'yi geliştirirken, MCP'yi native destekleyen ilk web framework'ü yaparken öğrendiğim prensipler:</p>

BareEngine: C++ ile Sıfırdan Oyun Motoru Yazmak

Teknik kararlar</h2>

Hyperembed: Rust ile Embedding Inference Motoru Yazmak

KayaDB: Sıfırdan Dağıtık Veritabanı Yazmak

Kendi Kendine Öğrenen Bir Founder'ın El Kitabı

Quantum Computing'e Rust ve Python ile Giriş: QuantumNN ve qec-playground

RustAPI: FastAPI'ye Rust'tan Bir Cevap

İlk Yazı: Bu Blog Neden Var?

Ne yazacağım?</h2>

Teknoloji notları</li>
Kişisel düşünceler</li>
Projelerimden kesitler</li>
Belki biraz saçma mizah</li> </ul>
`fn </span>main</span>() { </span> println!("</span>Hello, tuntii.com!</span>"); </span>} </span></code></pre> Daha fazlası yakında. Takipte kalın!</p>`

Zola ile Statik Blog Kurmak

Tuntii — Tunay Engin - Blog

Viltrum: V ile Kendi HTTP Engine'imi Yazdım

Yazılıma Nasıl Başlarım — 2026 Edition

Agent-First Mimari: API'lerin Geleceği MCP

Agent-first API tasarımının 5 prensibi</h2> RustAPI'yi geliştirirken, MCP'yi native destekleyen ilk web framework'ü yaparken öğrendiğim prensipler:</p>

BareEngine: C++ ile Sıfırdan Oyun Motoru Yazmak

Teknik kararlar</h2>

Hyperembed: Rust ile Embedding Inference Motoru Yazmak

KayaDB: Sıfırdan Dağıtık Veritabanı Yazmak

Kendi Kendine Öğrenen Bir Founder'ın El Kitabı

Quantum Computing'e Rust ve Python ile Giriş: QuantumNN ve qec-playground

RustAPI: FastAPI'ye Rust'tan Bir Cevap

İlk Yazı: Bu Blog Neden Var?

Ne yazacağım?</h2> Teknoloji notları</li> Kişisel düşünceler</li> Projelerimden kesitler</li> Belki biraz saçma mizah</li> </ul> fn </span>main</span>() { </span> println!("</span>Hello, tuntii.com!</span>"); </span>} </span></code></pre> Daha fazlası yakında. Takipte kalın!</p>

Zola ile Statik Blog Kurmak

Agent-first API tasarımının 5 prensibi</h2>
RustAPI'yi geliştirirken, MCP'yi native destekleyen ilk web framework'ü yaparken öğrendiğim prensipler:</p>

Ne yazacağım?</h2>

Teknoloji notları</li>
Kişisel düşünceler</li>
Projelerimden kesitler</li>
Belki biraz saçma mizah</li> </ul>
`fn </span>main</span>() { </span> println!("</span>Hello, tuntii.com!</span>"); </span>} </span></code></pre> Daha fazlası yakında. Takipte kalın!</p>`