go (programlama dili)

• yazmasi acayip kolay, öğrenmesi de acayip kolay, 25 tane keywordden ibaret geleceğin unicorn dillerinden. bunu elestirenler library ve community eksikliginden bahsederler ama bunu yaparkende 20 senelik dillerle kıyaslarlar. go daha çok genc ve community gun geçtikçe buyuyor.
  
  statically typed bir dil olmasi js/python yazarken hep sordugumuz ‘integer miydi lan bu acaba’ sorularini ortadan kaldiriyor.
  10 developer complex bir proje uzerinde calisirken bu değişken tiplerini bilmemenin nasıl bir hamallık sebebi oldugunu bilmeyen, bu yükten kurtulmak icin modeller, schemalar tasarlamamis ve değişken tipi tanımlamak nedir yeaaa diyen jediler icin: (bkz: bak surdan siktir git)
  
  bence en onemli 2 artisi direk machine code olarak compile edilmesi ve built-in concurrency yapısına sahip olması (goroutines).
  
  go hızlı, harbiden hızlı, yerli otomobil falan halt etmiş yanında öyle hızlı. 10 milyon itemli [string]string mapi 1.3qs de load ediyor, ayni anda diger goroutine cay demliyor.
  
  built-in testing koymus adamlar icine, en baba test library mocha abiii muhabbetlerine gerek yok, altı ustu test, et geç adamı hasta etme deyip icine koymuşlar mis gibi.
  
  linting compiling falan açık ara en iyisi. oyle vay efendim tanımladım değişkeni ama kullanmadım, yok efendim if icindeki return den sonra else koyup icinde return ettim juniorliklarina karşı ‘memory i sokakta mi buluyoruz lan kaldır o kullanmadigin değişkeni derlemem kodu’, ‘if icinde return ettin, ordan çıkarsa zaten buraya gelecek bi daha niye else yaziyorsun çocuğum gerizekali misin’ diyen cesur ve öğretici bir compileri var.
  
  hem c++ gibi low-level isler yapayim, pointerlari kullanayım ama garbage collectordan anlamam o isi nasıl yapcaz diyorsaniz demeyin, go kullanın, icine koymuslar onu da.
  
  go devops icin takim çantası olacak o belli, daha ötesini izleyecek artik nereye evrilecek. rest apilerimi go’ya tasiyayim dersen bin tane alternatifin var ama kolaylık noktasında hiçbiri bir express degil (egri oturup doğru konusalim). o günlerde gelir elbet.
  
  su an icin, backend tarafinda, kolay olsun, hızlı olsun, coca cola kalitesinde ama nese gazozu fiyatına olsun diyenler icin güzel dil go, avrupa’ya gecince maaşlar da şahane.
• kolay bir memory optimizasyonu yontemi soyleyecegim.
  
  detayina girmeyecegim fakat memoryden birazcik kaybedip cpudan kazanmak icin go compileri datalari padding yaparak memoryde aligned duracak sekilde ayarliyor. structlar ozelinde fieldlardan en buyuk sizeli olana gore aligment yapiyor.
  
  type foo struct {
  ___ a bool // 1 byte
  ___ b int32 // 4 byte
  ___ c bool // 1 byte
  ___ d bool // 1byte
  }
  
  sen yukaridakini gorurken compiler asagidakini goruyor.
  
  type foo struct {
  ___ a bool // 1 byte
  ___ _ [3]byte // padding
  ___ b int32 // 4 byte
  ___ c bool // 1 byte
  ___ d bool // 1byte
  ___ _ [2]byte // padding
  }
  
  12 byte.
  
  padding yaparken bitisigindeki attributeler alignment sizei gecmiyorsa bir nevi birlesiyor ve fieldlarin siralamasina gore bu padding degerleri ve birlesip birlesmeme durumu degisecegi icin field siralamasi basta soyledigim memory kaybi miktarini degisken kiliyor.
  
  eger ilk bastaki structta field siralamasini asagidaki gibi yaparsak;
  
  type foo struct {
  ___ b int32 // 4 byte
  ___ a bool // 1 byte
  ___ c bool // 1 byte
  ___ d bool // 1byte
  }
  
  bu sefer compiler sunun gibi gormeye baslayacak;
  
  type foo struct {
  ___ b int32 // 4 byte
  ___ a bool // 1 byte
  ___ c bool // 1 byte
  ___ d bool // 1byte
  ___ _ [1]byte // padding
  }
  
  8 byte.
  
  bir satir oynatarak struct basina 4 byte kurtardik.
  
  arch bazli max alignment ve word sizelar ve alignment logici icin tik
  playgroundda oynamak icin tik
  
  ps: bitisik _ ler tab/space yerine kullanilmistir.
  
  baslik aramasi icin keywordler: optimisation, optimization, memory, padding, alignment
  arastirmak isteyene konu basliklari: unaligned memory access, aligned memory access, golang memory alignment, memory padding optimisation, structure padding in c
• project euler hack edilip veritabanındaki kat ettiğimiz aşama bilgileri sıfırlanınca f#'ı bırakıp sıfırdan go ile başladım. kodlarken c'den çok pascal hissiyatı veriyor (sözdizimi, temel fonksiyonları vs). sonradan merak edip kısaca araştırdım. zaten tasarımcıları c'den sonra en fazla pascal/modula/oberon (kısaca: niklaus wirth) ailesinden etkilendiklerini söylemişler.
  
  genel olarak tasarımındaki pragmatik, sonuç odaklı yaklaşımı beğendim mesela public/private ayrımını fonksiyon isminin ilk karakterinin büyük küçük harf olmasıyla yapması buna güzel bir örnek. generics eksikliği geliştiricileri tarafından da kabul ediliyor ama "doğru yapmanın yolunu henüz bulamadık" diyerek şimdilik erteleniyor.
  
  modül sistemini ve tasarım tercihlerini çok beğendim. paket isimlendirme ve erişim mantığı. github'dan paket import edebilme vs.
  
  kurgusal bir stream'den okuma mantığıyla çalışan concurrency modeli (kanallar) enfes. bir benzeri d'de de vardı. bu işin en sorunsuz yolu o.
  
  hata denetimini exception kullanmamak suretiyle opt-out yerine opt-in yapmış olması belli senaryolarda anlaşılabilir (örn: mobil uygulama, web vs). ama kritik uygulamalarda (finans, nükleer santral, battlestar galactica), programcının özellikle denetlemeyi hatırlamadıkça kodun "hata yokmuş gibi" devam etmesi problem. belki doğru tasarımla aşılabilir ama ek efor gerektirdiği kesin.
  
  basit matematik problemleriyle gittiğimden oop eksikliğinin, daha doğrusu salt interface tabanlı ve hiyerarşisiz kodlama mantığını deneme şansım olmadı. hatta şu anda string'den aldığım slice'ın içi niye sıfır dönüyor gibi şeylerle cebelleşiyorum. ama eksik gördüğüm kısımlarına rağmen beğendiğimi söyleyebilirim.
  
  tooling çok iyi. package manager'ından tut da, formatting, documentation, linting vs hepsi hazır geliyor. geliştirici dünyasında kendi package manager'ı olmayan yazılımı dövüyorlar.
  
  visual studio'yu çok sevdiğimden go için ide arayışımda liteide'yi buldum yeni başlayan için gayet başarılı. atom kullananlar için de go-plus ve atom-runner eklentileriyle baya kullanışlı hale geliyor.
• sanırım c'yi sevdiğim için hoşuma giden programlama dili. şu anda iş yerinde bana verilen task'leri otomatize etmek dışında ciddi şekilde kullanma fırsatı bulamasam da bir gün tamamen go yazabileceğim bir iş bulmak için can atıyorum. go ile yazılmış ufak tefek projelerim var, hiçbiri büyük ve önemli değil, ancak bu linkedin'den iş teklifleri gelmesini engellemiyor. hepsini reddediyorum tabii, benden daha tecrübeli insanlara ihtiyaçları var ve şu anki işimi seviyorum. demek istediğim go görece yeni bir programlama dili olsa da insanın önüne önemli fırsatlar çıkarabiliyor.
  
  şu ana kadar kullanıp beğendiğim kaynaklar
  
  1- kitap tercih ederseniz, the go programming language kitabı oldukça iyi.
  
  2- tests with go'yu tavsiye ederim. alttaki formats yazısının yanından erişebilirsiniz kitaba.
  
  3- video eğitimi için inanç gümüş'ün udemy'deki eğitimi herhangi bir programlama dili özelinde yapılmış en kaliteli kurs kesinlikle. oldukça ayrıntılı bir kurs.
  
  4- gophercises, sanırım pek anlatmaya gerek ne olduğunu. ücretsiz bir kaynak sadece mailinizi alıyor, birkaç ayda bir falan kurslarım indirime gitti diye mail atmak dışında bir şey yapmıyor mail adresinizle. aynı adamın algoritmalar ile ilgili yine ücretsiz kursu var ancak içeriği henüz dolu değil. aynı şekilde ben de go'da veri yapıları ve algoritmalar ilgili ufak bir şey yaratmayı düşünmüştüm, ama şu var ki go'da generic'ler halen yok. geldikten sonra çok şey değişecek, ancak o zaman mantıklı olur.
  
  5- exercism.io yeni bir şey öğreniyorsam default uğradığım ilk yer, sadece go özelinde değil.
  
  web'e geçtiğimde kaynak bulmak konusunda zorluklar yaşadım.
  1- alex edwards'ın let's go kitabını çok beğendim. go, api ve microservisler için çok uygun deniyor ancak bu kitapta server side rendering yapıyoruz. ancak bu durum kitaptan pek çok öğrenmemizi engellemiyor. yazın kendisi api yazmak ile ilgili bir kitap daha çıkaracak onu dört gözle bekliyorum.
  
  2- elimde gophercises'ı yapan jon calhoun'un go ile web programlama kitabı da var ama henüz okuyamadım. 700 sayfa civarında, birkaç ay içinde okuyacağım umarım.
  
  3- mikroservislerle ilgili bildiğim iki kaynak var sadece şu an. ikisini de bitirmedim henüz yorum yapamam ama yine de koyayım. devam eden bir youtube serisi ve bir udemy kursu.
• son bir yıldır aktif olarak kullandığım dildir ve uzun bir süre boyunca go'dan başka bir şey yazacağımı sanmıyorum. burada nasıl öğrendiğimden bahsetmiştim.
  
  dilin benim gördüğüm bazı avantajları;
  
  - kullanıcısına olayların arka planında neler döndüğünü kullanış aşamasında öğretiyor olması.
  örnek vermem gerekirse nodejs kullanırken hiç websocket bağlantısının nasıl kurulduğu hakkında bir bilgim yoktu, ws endpointini oluşturur client ile bağlanırdım, go ile bir websocket endpointi yazmaya çalıştığımda anladım ki, websocket bağlantısı normal bir http bağlantısının upgrade edilmiş haliymiş, upgrade ederek tcp bağlantısını açık tutuyormuş. tabi ki ben nodejs kullanırken de basit bir google araması ile bunu öğrenebilirdim fakat go da bunu direkt kullanırken görüyorsunuz çünkü http post request geldiğinde o requesti bizzat siz alıp upgrade etme fonksiyonunu çağırıyorsunuz ve o size bir websocket bağlantısı dönüyor.
  
  mesela bir txt dosyasından veri okuduğunuzu düşünün, burada buffer nedir neden kullanmanız gerektiğini çok iyi anlıyorsunuz, dosyayı bufferlayarak okumanın önemi nedir keza yine çok net bir şekilde oturuyor zihninizde.
  böyle bir şeyi grpc üzerinde dosya upload clienti yazarken çok net anladım, bizzat dosyayı bufferlayarak chunk of bytes gönderiyorsunuz ki kocaman dosyayı tek requestte koymak gibi bir hata yapmayın.
  
  işte böyle şeyleri go yazarak çok rahat bir şekilde kavrayabiliyorsunuz, bence go'nun low levelliği bu bağlamda tam olması gerektiği kadar.
  
  - concurrency modeli çok hoş
  gerçekten çok lightweight ve kullanması keyifli bir concurrency modeli var. ben daha önce birçok dilde concurrency ile uğraşmıştım hiçbiri go kadar pratik ve keyifli olmadı.
  fonksiyonunuzun önüne tek bir 'go' keywordu koyarak onun farklı bir sub threadde çalışmasını sağlayabiliyorsunuz ve aralarındaki iletişimi go channel denilen araçlar ile gerçekleştiriyorsunuz.
  
  burada bir noktayı vurgulamak istiyorum ; go channelleri düzgün kullanmak gerçekten marifet isteyen bir şey, go channel kavramına eliniz biraz ısınınca kolay bir şekilde routine'ler arası iletişim kurabiliyorsunuz. ben alışmak için websocket üzerine kurulu bir chat sistemi yazmıştım, orada ilk başta baya epic failler geçirmiştim fakat çok hızlı alışıyorsunuz.
  
  - öğrenmesinin çok kolay olması
  ben yaklaşık 1 haftada yoğun bir çalışma ile dilin bütün ana hatlarını bitirdim daha sonra proje yapmaya koyuldum.
  
  - aktif ve yardımcı bir topluluğunun olması
  bu hem türkiye özelinde hem de globalde geçerli bir durum.
  ankarada oldukları için henüz katılamadım ama gophers türkiye ekibi çok güzel etkinlikler düzenliyor.
  
  kanallarına buradan göz atabilirsiniz.
  
  - büyük şirketlerde çok aktif bir şekilde kullanılmaya başlanması
  uzun uzun yazmayacağım, türkiyedeki bütün büyük teknoloji şirketleri servislerinin bazılarını ( özellikle cpu intensive olanları ) go ile yazmaya başladılar. anlayacağınız iyi bir talep var.
  
  - standart library ve dökümantasyonlarının mükemmel olması
  bunu uzun uzun açıklamama gerek yok, dilin kendi içinde built in gelen kütüphaneler tam bir isviçre çakısı ve adamlar her şeyi çok net bir şekilde açıklamışlar.
  
  - dilin arkasında (bkz: rob pike) (bkz: ken thompson) (bkz: robert griesemer) gibi manyakların durması
  
  - dilin çok temiz standartlarının olması, bir şeyi doğru yapmanın genelde bir yolu olması
  bunu şuan twitterda çalışan (bkz: ahmet alp balkan) ' dan da duymuştum.
  bu dilde bir şeyi implement etmek istediğinizde genelde herkesin uzlaştığı doğru bir standart oluyor.
  
  gördüğüm tek bir dezavantajı var o da bazen avantaj olarak bile görülebilir ;
  
  - nodejs gibi pratik bir çevreden geliyorsanız bazen fazla boilerplate kod yazdığınızı düşünüyor olabilirsiniz, ben bunu 2 satırda yazıyordum şimdi 5 satırda yazıyorum dediğiniz durumlar olabilir ama bu çok nadir yaşanıyor.
  
  yaşansa bile burada aslında node.js in encapsulate ettiği kısmı da siz yazıyorsunuz ve yazdığınız şeyin üzerinde tam kontrol sahibi olabiliyorsunuz.
  
  go'yu seviyoruz
  in go we trust
• son 5 senedir en çok kullandığım güzel ve sade programlama dili. kendimce artıları, eksileri:
  
  artılar:
  - low level/high level olma noktasında çok ideal bir yerde. hem iyi performans veren programlar yazabiliyorsunuz hem de bunları yazarken c gibi incik boncuk işlere çok fazla girmeniz gerekmiyor.
  - çok sade bir yapısı var, öğrenmek için kotlin vs. tarzı dillerdeki gibi 50 tane opsiyonel olayı, 100 farklı keyword'ü vs. öğrenmeniz gerekmiyor. hele mühendislerin çok sık iş değiştirdiği günümüz piyasasında bence hızlı öğrenilen basit dillerin değeri oldukça yüksek.
  - yine kotlin'e kıyaslarsak, zincirleme yan yana yazılmış çok iş yapan fonksiyonlar yerine oturup düzgünce okunabilecek şeyler yazmaya yönlendiriyor, böylece daha kolay okunabilir ve modifiye edilebilir bir kod ortaya çıkıyor. tek satırda koca koca işler yapan fonksiyon yazdım gibi gereksiz bir cool olma çabası yok. oturup şov yapmadan düzgünce yazıyorsunuz yazacağınız şeyi.
  - go routine olayı müthiş. bir thread açmak için hem sadece tek keyword yetiyor hem de çok az ekstra hafıza istediği için thread açarken çok düşünmenize gerek kalmıyor.
  - yine channel, select gibi olayları thread üzerinden şeyler yaparken işinizi çok kolaylaştırıyor.
  - çok güzel bir network kütüphanesi var. bir çok low level özelliğe kolayca ve anlaşılabilir şekilde ulaşabiliyorsunuz. c'deki gibi sanki uzay mekiği kodu yazıyor gibi hissetmiyorsunuz.
  - standart kütüphanesi genel olarak çok iyi. java'daki gibi bir methodun 50 milyon farklı signature'lü hali, aynı class'ın 4-5 farklı isim verilmiş versiyonları yok. çok sade ve ne yaptığı belli olan fonksiyonlar var hep. dökümantasyonu da gayet iyi. godoc sayesinde dökümantasyonu doğrudan fonksiyonların üstüne yorum olarak girdiğinizden de ayrıca browser kullanmadan ide'nin içinde tek tıkla kullandığınız fonksiyonun açıklamasını okuyabiliyorsunuz.
  - sadeliği öne çıkarmasıyla sürekli sağda solda yeni çıkan anlamadığınız konseptler duymuyorsunuz. factory'dir, abstract builder'dır vs. cool olmak için abstractlığın bokunun çıkarıldığı kavramlar yok. kodu yazarken yazdığınız kodun metasından ziyade göreceği işleve odaklanıyorsunuz.
  - java'daki spring vs. gibi ekosistemi tamamen ele geçirmiş framework'ler yok. bir tane hello world programı çalıştırmak için arkada 50 farklı script, 24 farklı framework, 85 tane xml config dosyası çalışmıyor. bir go projesini sıfırdan kurarken durduk yere bilmem ne dependency'sinin bilmem ne config'inde bilmem ne class'ını yükleyemedi diye durduk yere hatalar almıyorsunuz.
  - inheritence yerine composition'a alışmanız biraz zaman alabilir ama alışınca çok nadir senaryolar dışında inheritence'ı pek aramıyorsunuz.
  - public private yazmak yerine büyük küçük harfle başlamak bence çok pratik.
  - getter setter gibi artık geçtiğimiz on yılda kalması gereken kavramlar mevcut değil.
  - iş imkanları giderek artıyor. görece yeni dil olduğundan piyasada java vs. gibi milyonlarca bu dili bilen yazılımcı yok, hele bu dilin gurusuyum modunda takılan insan sayısı çok çok az diğer popüler dillere kıyasla. dolayısıyla iyi bir iş arama süreciyle başka bir dil kullanarak alacağınız maaşın 1-2 tık üstünü alma şansınız var. tabii ki dili öğrenmeye başlayan insan sayısı da artıyor olduğundan bu durum birkaç yıl sonra kaybolabilir.
  
  ne artı ne eksi:
  - error handling sistemi hakkında hala kararsızım. bir yandan exception gibi programın akışını çok değiştiren bir yapıdan ziyade (panic'le hala bunu yapabiliyorsunuz ama kısıtlı durumlar hariç pek kullanılmıyor), error dönme olayı bence çok daha mantıklı. fakat sürekli if err != nil {return nil, err} (veya errors.wrap kullanarak) şeklinde err dönmek bir yerden sonra bayıyor. buna böylece her error'un üzerine onu nasıl handle edeceğinizi düşünmeniz gerekiyor tarzı yorumlar gördüm ama pratikte %90 en fazla çok ufak bir info ekleyip gene düz error dönüyorsunuz.
  - bir struct'ın hangi interface'i implement ettiğini yazmamak zaten küçük interface'lerin kullanılmasına yönlendirildiği, dolayısıyla 1 fonksiyonla (close gibi) bir sürü interface'i implement ediyor olma ihtimaliniz olduğu için tutarlı. fakat yine de interface'te bir değişiklik olduğunda rastgele bir kod bloğu yerine doğrudan struct'ın tanımında bir hata almayı yeğlerdim.
  
  eksileri:
  - bazen o kadar basit fonksiyonları elle yazmanız gerekiyor ki yok artık diyorsunuz. en basitinden math kütüphanesi sadece float64 kullandığından 2 int içinden en düşük olanı bulmak gibi çok basit bir işlem için 3 kere int float64 arası dönüşüm yapmanız gerekiyor (ya da oturup elle bu fonksiyonu int'ler için kendiniz yazmanız veya sırf bunun için internette başka bir kütüphane aramanız lazım). array/slice'lar ile ilgili yine çok basit şeyler için (contains gibi) generic'ler henüz olmadığından elle fonksiyon yazmanız gerekiyor. contains gibi şeyleri daha kolay handle etmek, veya duplicate entry'leri engellemek gereken senaryolarda genelde slice yerine map kullanmayı tercih ediyorum bu yüzden.
  - python gibi high level fonksiyonlar bir yana bu tarz çok trivial şeyleri bile elle yazmanız gerektiği için leetcode gibi yerlerde bir çok soruda go kullanmak çok inefektif. iş görüşmelerine hazırlık yapıyorsanız gene en iyisi bir yandan python'da pratik yapmaya devam etmek.
  - interface olarak aldığınız bir parametreyi nil mi diye kontrol ederken aslında type'ı nil mi diye kontrol ediyor. eğer type'ı belli ama içeriği yine de nil olan bir değer gönderirseniz nil değilmiş gibi gözüküyor. çok fazla spesifik bir durum ama muhtemelen bu yüzden içinde bug bulunduran çok fazla go programı var. (örnek: https://play.golang.org/p/ixlhtbphyaa) böyle çalışmasının mantığı da muhtemelen gönderdiğiniz öğe nil bile olsa teknik olarak type'ı belli olduğu için hala methodları çağırabiliyor olmanız. (örnek: https://play.golang.org/p/dbyo65iyjs9)
  
  dilin eksisi değil ama hayatın eksileri:
  - go'da yazmaya alıştıktan sonra kotlin tarzı bir dil kullanan bir yerde çalışıyorsanız biraz beyniniz yanıyor. go'nun size bak bu kötü diye yaptırmak istemediği ne varsa kotlin size bunların hepsini zorla yaptırıyor, psikolojiniz bozuluyor.
  
  dille alakasız başka bir eksiklik:
  - dili yeni öğrenmeye başlayan bir çok insan dilin mantığını pek çözmeden işe giriştiğinden ortalıkta çok fazla java kafasıyla yazılmış kod var. hele başka dillerden go'ya aktırım yapıldığı (java'da yazılmış bir json kütüphanesinin sonradan go versiyonunun çıkması gibi) durumlarda çok felaket şeyler ortaya çıkıyor. bu durumda olan çok fazla önemli kütüphane var. muhtemelen şirketlerde birileri bu kütüphanenin çok acil go versiyonunu çıkarmamız lazım diye 2 java developar'a 1 hafta süre veriyorlar onlar da pata küte java yazar gibi yazıp geçiyor.
  
  çok ufak keşke şöyle olsaydı dediklerim:
  -defer olayı çok güzel. bir resource açtıktan sonra onu kapatacak olan satırı hemen onun bir altına defer ile yazabilmek bir çok potansiyel hatanın önüne geçiyor. fakat defer'in doğrudan fonksiyona bağlı çalışması yerine tanımlandığı kod bloğuna (if, veya for bloğu gibi) bağlı çalışmasını tercih ederdim. mesela bir for loop'unda sürekli resource açtığınız bir senaryoda defer kullanmanız bazen imkansız olabiliyor, mecburen eski usüle dönüyorsunuz. kullanma imkanınız varsa bile yine her halükarda bütün resource'lar bütün iterasyonlar bittikten sonra kapanacağından en iyi ihtimalle çok inefektif bir durum ortaya çıkıyor. fakat go zaten küçük fonksiyonlar öne çıkarmaya çalıştığından ve de bu durumda da baktığınız zaman for loop'ta yapmaya çalıştığınız şeyi bir fonksiyonun içine taşımaya yönlendirmiş olduğundan aslında yine de dilin mantığına çok ters bir durum değil. fakat ben gene de fonksiyon yerine bloğa bağlı çalışmasını tercih ederdim.
• 1.3 versiyonu cikmis. ben de golang eksi sozluk temsilcisiyim galiba.
• bu dilin beni en cok ceken ozelligi: surekli calisan bir process yapmak istiyorum diyelim. bunu oturup javayla yazsam 60-70 mb memory tuketecegi garanti. c# desen dunyada hala windows server satin alan bireyler var mi emin degilim. go ile process'imi yaziyorum ne bi leak var ne sikimsonik olaylar. saniyede onlarca network request isleyen process sadece 8 mb ram tuketiyor. bundan iyisi, (kendisiyle concurrent yazabilene) c++'tir.
  
  not: fakirim, ayda 5$ verdigim linux serverda 15 kusur process/site calistiriyorum surekli.
• go için yavaş diyen arkadaş bunu production ortamda test etti mi acaba ?
  
  java, c# ve python üçlüsünden meydana gelen tüm yapıları go ile tekrardan yazdık. sonuç 8 tane ec2 instance yerine artık 3 ec2 instance kullanmaya başladık ve 4 kat daha dazla trafiği kaldırır hale geldik.
  
  yazara tavsiyem, dil fanatiklerinin oluşturduğu benchmark testlerine bakmamasıdır.
• yaklaşık 1 aydır kendisi ile haşır neşirim. eğer daha önce başka bir dilde deneyiminiz varsa öğrenmesi çok çok kolay diyebilirim. en zor konusu channel muhabbeti onu da bir iki youtube izlemesi, ufak bir iki deneme ile çok kolayca kavrayabiliyorsunuz.
  java spring boot ile yazılmış aynı işi yapan uygulama 500-600mb ram tüketirken, go ile yazılan uygulama 5mb (evet 5) ram tüketiyor ve response time'ları da oldukça düşük. eğer microservice geliştiren bir ekipte iseniz kesinlikle bir şans vermeniz gerektiğini düşünüyorum. şu anda bir service ile başladık, baktık güzel gidiyor, yeni geliştireceğimiz service'leri de go ile yazmaya çalışacağız.
  
  java ya da c#'dan geliyorsanız interface mantığı biraz değişik gelebilir (bkz: duck typing)
  
  özellikle yüksek yük altında çalışan uygulamalarınız varsa, docker image boyutu yaklaşık 15-20mb olduğu için çok daha hızlı scale edilebilir, ram ve cpu tüketimi de java veya .net'e göre daha az olduğu için kaynak tüketiminizi de azaltabilirsiniz.
  
  ayrıca go ile yazılmış bir uygulamayı incelerseniz çok kolay bir şekilde anlayabiliyorsunuz. eğer intellij'ye alışıksanız da goland'i tavsiye ederim ya da intellij'e golang dil desteği için de plugin mevcut. go go go.