Rehber Python'ı neden bıraktım? Yazılım hayatımı değiştiren dil: Go ve tecrübelerim

  • Konuyu başlatan Konuyu başlatan Omerta Silenzio
  • Başlangıç Tarihi Başlangıç Tarihi
  • Mesaj Mesaj 12
  • Görüntüleme Görüntüleme 399
Electron bu aralar çok eleştiri yiyor hocam zaten. Tauri'ye, Wails'e falan geçişler artacaktır.
Aynı fikirdeyim. Milletin bilgisayarı resmen "Chrome sekmesi" çöplüğüne döndü Electron yüzünden.

Sen basit bir "To-Do List" uygulaması yapıcam diyorsun Electron'la, o gidiyor uygulamanın içine koskoca Chromium tarayıcısı gömüyor. Kullanıcı senin uygulamayı açtığında aslında arkada gizli bir Chrome penceresi açmış oluyor. Eeee kullanıcıda zaten Discord açık, Spotify açık, VS Code açık..... PC arka planda 50 tane Chrome sekmesi çalıştırmaya çalışıyor, RAM'ler ağlıyor sonra

Rust bilen veya öğrenmeyi göze alanlar Tauri tarafına, Go'nun basitliğini sevenler Wails tarafına akıor genelde. Özellikle Tauri v2 ile mobil desteği de geldi, baya gaza bastılar.

Bence de önümüzdeki 2-3 sene içinde yeni başlayan projelerde Electron'u anca "mecburiyetten" (çok spesifik Node.js paketlerine ihtiyaç varsa) görürüz, yoksa devir hafif sıklet framework devri....
 
Cok uzun bi ek yazdim, okumak istemeyenler icin TLDR; Go geleneksel concurrency'den farkli bi yapiya sahip ve eger geleneksel concurrency'ye alisik biriyseniz saglam bi kafa yapisi degisikligi gerekecek. Concurrency'nin kendisi zaten zor bi sey ama go spesifik olarak konusuyorsak, geleneksel sistemlere alisik biri icin basta bazi kisimlar sasirtici gelebilir. Hic concurrency bilmeyen kisiler icin o kadar zor olmayacagini dusunuyorum. Yine de tabii ki belli basli zorluklari olacak. Ama fikrimce geleneksel concurrency'den bi miktar daha kolay oldugu.

Bu dilin zor kismi concurrency modeli. Go'nun concurrency modeli geleneksel parellelism yada geleneksel asynchronous programming'den siddetli olcude farkli. Concurrency genel olarak zor ama go'da biraz daha farkli bi anlayis gerektiriyor geleneksel concurrency'ye kiyasla.

Go'nun concurrency modeli geleneksel multithreading'e daha yakin. Ancak iletisim sistemi birincil olarak channellar uzerinden gerceklestiriliyor ve context aracaligiyla bi routine'in (task'in) calisma sureci kontrol edilebiliyor.

Normalde, geleneksel C++'da paylasilmis bir bellek uzerinden iletisim saglanir. Bu paylasilmis bellek bi queue olabilir, bi list olabilir yada buyuk bir obje icin referans olabilir. Ancak go icin bellegi iletisim uzerinden paylasiriz. Dolayisiyla eger bir pointer paylasmiyorsak channellar uzerinden, neredeyse tum yazma ve okuma islemleri thread-safe bi sekilde gerceklesir. (Burda pointer paylasimlarina dikkat etmek gerek, cunku pointerlar, dogalari geregi ayni bellek adresine isaret edecekleri icin tek objenin iki farkli routine tarafindan kullanilmasi anlamina gelir. Bu da race condition veya bellek kaynakli problemlerle sonuclanabilir. Eger paylasilan objede bi pointer tasiyorsa, yine ayni kurallar gecerli. Slice ve Map'de iclerinde pointer tasiyan birer descriptor/header'dir, onlarin da bu sistemde paylasilmalari aslinda tasidiklari pointerlarin paylasilmasi anlamina gelir. Aman dikkat.)

Geleneksel multithreading sistemlerinde, ornegin C++'ta elinizde bi thread objesi, C'de bi thread id'si, Java'da yine bir thread objesi elinizde olur. Daha sonrasinda bu objeyi kullanarak bu threadin sagligini takip edebilir, disaridan thread'i durdurabilirsiniz (interrupt). Ayni durum golang icin gecerli degil. Go buna izin vermiyor. Durdurulabilirlik icin go saglanmis olan context objesiyle cancel (iptal) gerceklestirilmesini istiyor. Ve goroutine'lerde bu objeye itaat edilecek sekilde yazilmis olmali. Belirli guvenli noktalarda iptal edilebilir olmalilar.

Ayrica goruntime goroutineleri ayni bir isletim sistemi gibi zamanliyor. Isletim sistemleri dogal olarak preemptive zamanlama becerisine ihtiyac duyarlar. Preemptive zamanlamanin arkasindaki temel mantik bir isin uzun bir sure bir islemci kaynagini somurup, diger islerinde ayni kaynagi kullanabilmesine olanak saglamaktir.

Zamanlayicinin kendisinin de ayrica bu kaynaga ihtiyaci oldugu icin, zamanlayici elinden geldigince oncelik siralamasina gore butun islemlere zaman ayirmaya calisir ve cok uzun calisani gecici askiya alip bi sureligine de olsa baska bi kac ise sure verip, tekrar askiya aldigini geri yukler boylece her sey bi miktar ilerlemis olur. Go 1.14'ten beri bu mantik yardimiyla, cpu-bound logic icin bile neredeyse sifir block mantigiyla ilerleme saglayabiliyor.

Ondan oncesinde cooperative scheduling kullaniyorlardi, bu da cok uzun calisan cpu bound logiclerin bi go processorunu komple kiliteleyebilecegi anlamina geliyordu, simdi durum boyle degil. Tabii ki milyonlarca uzun calisan isin varligi, tum islerin hep beraber ciddi anlamda yavaslamasina sebep olabilir hala, cunku bu seferde resource starvation yasanacak genel anlamda.
 
Bu siteyi kullanmak için çerezler gereklidir. Siteyi kullanmaya devam etmek için çerezleri kabul etmelisiniz. Daha Fazlasını Öğren.…