Azure CTO: "Artık yeni projelere C/C++ ile başlamayı bırakmanın zamanı geldi"

• GC'siz bir dilin gerçekten gerekli olduğu senaryolarda Rust kullanalım
• Bunun nedeni güvenlik ve güvenilirlik
• Sektör C/C++'ı kullanım dışı ilan etmeli

[ahwjdekf]

Şimdiye kadar Rust'ı överek kullananların bile async ile karşılaşınca bir anda hevesinin kaçtığı söyleniyor. Hatta Rust ile kütüphane bile yapmayın mı deniyor (fazlasıyla karmaşık, titiz ve zor). Böyle şikayetler de çıkıyor gibi görünüyor.

[kernel00]

Mark Russinovich'in kim olduğunu bile bilmeden onu küçümseyen insanlar da var... sysinternals tool suite ve Windows Internals kitabının yazarıdır... Windows'u tersine mühendislikle inceleyip araçlar geliştirirken Microsoft Fellow olan bir kişidir...

[ahwjdekf]

Rust fanatiklerinin sorunlarıyla dalga geçen kısa bir video

https://twitter.com/cmuratori/status/1367627549816152064?lang=en

[ahwjdekf]

Rust'un henüz resmi bir spesifikasyonu bile yokmuş...

[functor]

C++ için resmî bir spec "var", ama tüm implementasyonlar (gcc, clang, ...) eksik.

[lifthrasiir]

Bu yaygın bir mantık ama açıkçası çok fazla spesifikasyon okumuş ve birkaç kez de uygulama yapmış biri olarak, spesifikasyonun var olup olmamasının kendi başına ne anlam ifade ettiğini pek bilmiyorum.

"Spesifikasyon" için çeşitli stratejiler vardır. Dışarıdan görünen davranışı merkeze alarak anlatan yöntemler ve iç işleyişi anlatan yöntemler vardır; ayrıca doğal dil mi yoksa makinenin okuyabileceği bir yöntem mi (sözde kod ya da matematiksel tanım gibi) kullanıldığına göre de ayrılır. Python veya Rust dil referans belgeleri gibi şeyler, dışarıdan görünen davranışı doğal dille anlatan spesifikasyonlardır. ISO standartları vb. yerlerde sık görülen yaklaşım ise iç işleyişi doğal dille anlatan spesifikasyondur; ancak bu iç işleyişin gerçek uygulamaların yaklaşımıyla örtüştüğüne dair bir garanti yoktur. Bunun yerine, bu iç işleyişle uygulanmış varsayımsal bir uygulama ile gerçek uygulamalar dışarıdan bakıldığında aynı şekilde çalışıyorsa, yani observationally equivalent ise, standarda uygun sayılır şeklinde tanımlanır. ECMAScript doğal dille anlatılmış olsa da gerçek yapısı fiilen doğal dille yazılmış sözde kod düzeyindedir; WebAssembly gibi, iç işleyişi hem doğal dil spesifikasyonu hem de matematiksel tanımla birlikte sunan örnekler de vardır.

Uygulama açısından bakınca doğal dil spesifikasyonlarının hepsi aşağı yukarı aynıdır. Doğal dil spesifikasyonları gerçek uygulamadan ayrı olarak hazırlanmak zorunda olduğundan, ikisinin zamanla birbirinden kopması da mümkündür; ayrıca hata yapılması da sık görülür. Dışarıdan görünen davranışın mı yoksa iç işleyişin mi uygulaması daha kolaydır sorusu duruma göre değişir; fakat programlama dilleri açısından bakıldığında bunlardan birini seçmek için özel bir zorunluluk yoktur. Bu açıdan Rust için zaten bir spesifikasyon vardır ve başka alternatif uygulamaların ortaya çıkabileceği kadar da bu spesifikasyon yeterli bilgi sağlamaktadır.

Eğer bir standardın olgunluğunu sadece ISO standardı olup olmamasına göre değerlendirmek istiyorsanız, size ISO/IEC 18181-1 JPEG XL standardında yaklaşık 100 hata bulduğumu (ve bu yüzden 2nd amendment'ın geciktiğini) söyleyebilirim...

[xguru]

Hacker News'te de 800'den fazla yorum vardı... burası da hararetliymiş...
https://news.ycombinator.com/item?id=32905885

[kayws426]

Emeğinize sağlık.
Bu arada... bir kişinin sevdiği bir şey saldırıya uğradığında, o kişinin tepkisini yorumlamaya çalışırken bunu onun kişiliğine bağlama konusunda dikkatli olunması gerektiğini söyleyen bir yazı görmüştüm ve bunun güzel bir söz olduğunu düşündüm; çünkü gerçek hayatta böyle bir tutuma sahip olmak muhtemelen zor olduğu içindir.

[ahwjdekf]

Tweet yorumları arasında etkileyici bir tane var.

People end up writing Rust code the "unsafe way". - atlandı - Rust was never meant to replace those.

[kayws426]

Bu noktada, Mark Russinovich'in kim olduğunu öğrenebileceğiniz bir bağlantı bırakıyorum.
https://en.m.wikipedia.org/wiki/Mark_Russinovich

[ahwjdekf]

Bir şey daha söyleyeyim. C++ kullanırken sürekli hata çıkarıp bug üreten insanların, “Ya bu olmuyor, madem bugünlerde popüler olan Rust var, ona geçelim... Hem bellek hatalarını da dert etmeye gerek yokmuş” demesi durumu değiştirmiyor. Bu insanlar aynı. Rust ile de benzer bug’lar çıkaracaklar... Sonra da yine “Acaba sırada hangi dili öğrenip denesek?” diyecek çok kişi var. C++’ta pointer dereference’i bile düzgün yapmamış insanlar Rust’ı göklere çıkarıyor.

[ahwjdekf]

O tür insanlar, Rust'ın güçlü yanları olarak öne sürdüğü ownership, reference, borrowing gibi şeyler derleme aşamasından itibaren hata verip baş ağrıttığı için bunların hepsini görmezden gelip, unsafe karıştırarak sanki C++'mış gibi gelişi güzel kullanacaktır.

[functor]

Zaten nasıl olsa ölecekseniz neden yaşıyorsunuz?
Bununla neredeyse aynı düzeyde bir mantık gibi.

[budlebee]

Nasıl olsa kazaya sebep olacak kişi emniyet kemeri de takmıyor, trafik ışığını da umursamıyor; o yüzden emniyet kemeriyle trafik ışığının pek bir anlamı yok demek gibi geliyor bana.
Elbette iyi olan kişi ne yaparsa yapsın iyi yapar, kötü olan kişi de ne yaparsa yapsın kötü yapar denebilir; ama o mantıkla gidersek araçların faydası üzerine bir tartışma yürütmek mümkün olmaz.

[cr543l]

Sorun, dilin kullanımının fazla zor olması; ama evet, doğru bir tespit.

[iolothebard]

Visual Rust çıkarsa kabul lol

[binaryeast]

C/C++ artık gerçekten Latince’nin konumuna gidiyor gibi görünüyor. Akademik amaçlar için elbette herkesin öğrenmesi gerekir, ama ustalaşması neredeyse imkânsıza yakın; ayrıca eski bir sistem olduğu için bugünün ölçütleriyle bakıldığında mantıksız kalan birçok yanı da var...

[dalinaum]

Her şeyin unsafe olduğu dilleri rahatça kullanırken, unsafe kullanımına sınırlı şekilde izin veren dillere neden asla olmaz gözüyle bakıldığını görmek ilginç.

[functor]

Bence bu bir tür Stockholm sendromu.

[williameom]

C'nin Ruhu

1. Programcıya güvenin.  
2. Programcının yapılması gereken şeyi yapmasını engellemeyin.  
3. Dili küçük ve basit tutun.  
4. Bir işlemi yapmanın yalnızca tek bir yolunu sunun.  
5. Taşınabilirliğinin garanti edilmediği durumlarda bile onu hızlı yapın.

[functor]

Bana kalırsa daha ilk maddeden yanlış gibi görünüyor haha. İnsan doğası gereği hataya açık çünkü..

[heal9179]

C++ tarafında da akıllı işaretçiler ve bellek havuzu aktif şekilde kullanılırsa oluyor zaten..
Düşündüğünüzden daha az durumda işaretçileri doğrudan elle yönetmek gerekiyor diye düşünüyorum.

Thread-safe kodun sonuçta programcının kendi becerisine bağlı olduğunu düşünüyorum.
Hangi dili kullanırsanız kullanın,
becerisi yeterince iyi değilse
güvenli ama düşük performanslı ya da tehlikeli kod ortaya çıkıyor.

[hiyama]

Programcıların becerilerine araba kullanmayı ya da uçak uçurmayı emanet etmek fazla korkutucu, değil mi....

[functor]

Thread-safe kod yazmak sonuçta programcının kendi yeteneğidir <- bence bu düşünce tehlikeli; çünkü memory / thread safety, programın sadece çökmesi ya da yavaşlaması düzeyinde bir mesele değil, güvenlik açığına dönüşebiliyor. Bu yüzden bunun tek bir kişinin becerisine bırakılmaması gerektiğini düşünüyorum.
Bunu önceden engellemenin çeşitli yolları uzun süredir araştırılıyor ve bunlar olgunlaşıp Rust gibi dillere ya da başka araçlara dönüştü; bunları kullanmayıp suçu bireye yüklemek için yazılımın günlük hayat üzerindeki etkisinin artık fazla büyük olduğunu düşünüyorum.

[mastotron]

İnsan, insan olduğu sürece hata yapması kaçınılmaz; ne kadar zeki bir programcı olursa olsun hata yapabilir. Bellek hataları da sonuçta hatalardan kaynaklanıyor...

Bugünlerde, kendi başına iyi yapmaktan ziyade en baştan hata yapmayı zorlaştıran bir ortam sunmanın daha iyi bir yaklaşım olup olmadığı da düşünülebilir.

[ahwjdekf]

Şirketimizde Rust kullanacaksak unsafe kullanmak yasak. Ancak böyle bir kural olursa dil düzeyinde sunulan güvenliğe bir kez olsun güvenebiliriz diyebiliriz. Ama bu mantıklı mı?

[mastotron]

Elbette Rust kullanan şirketlerde, gerçekten gerekli olmadıkça unsafe kullanılmaması gerektiği konusunda bir uzlaşma vardır. Bundan da öte, bizzat Rust ile yazmayı denemenizi öneririm... unsafe kullanmanızın gerçekten ne kadar gerekeceğini, ancak kendiniz deneyerek anlayamaz mısınız?

[ahwjdekf]

tokio gibi bilinen kütüphanelerde unsafe her yere boca edilmişti

[novemberoscar]

"Ya hep ya hiç" yaklaşımıyla, ya tamamen mükemmel değilse hiçbir değeri yokmuş gibi gören yorum epey fazla görünüyor.

unsafe / safe ayrımını açıkça yapıp yalıtmak mümkün ve bellek hatasını 100 kez çıkaracak birinin bunu 10 kez çıkarmasına indirebilme gibi bir avantaj var; ama yine de unsafe var / yine de bellek hataları oluşuyor => o halde C++'tan daha iyi bir yanı yok diye bakmanın ne kadar gerçekçi bir değerlendirme olduğundan ben pek emin değilim 😅

[ruinnel]

Yorum sayısına bakılırsa öyle ama.....
Sanki durum daha çok, ya hep ya hiç görüşünde olan bir kişinin çok fazla yorum yazmış olması gibi görünüyor.

[csjune]

Ben de bu yoruma katılıyorum. Bir şeye ne kadar ikili karşıtlıklar üzerinden bakarsanız, sonunda zararı kendinize olur.

İşin içinde, artılarıyla eksilerini tartıp sonuçta en çok artı sağlayan seçeneği seçmek olağandır. Sektörün doğası gereği şu anda C/C++ kullanmak zorunda olunan bir durum değilse, rust kullanıldığında elde edilen faydalar büyük olduğu için bence rustın kullanıldığı alanlar giderek genişliyor.

rusta geçen insanlar da aptal değil; rustı kullanınca sonuç olarak C++'tan daha iyi tarafları olduğunu gördükleri için kullanmaya devam ediyorlardır zaten haha

[alstjr7375]

Hiçbir şey... Her şey

[functor]

Artık Rust'ın bir sonraki C++ olduğuna katılmayan pek az kişi vardır. Sonuçta Linux çekirdeğinde bile resmi dil olarak benimsendi.
Ancak Rust'ın gerçekten kullanımı rahat bir dil olup olmadığı biraz tartışmalı... bellek güvenliğini daha en baştan yakalamak için yaptığı statik analiz yüzünden derleme süresi epey can yakıyor ve ownership gibi semantiklerin zor olması nedeniyle Python ya da Java gibi genel amaçlı dillere kıyasla çok daha fazla çalışma gerektiriyor.

[dalinaum]

Derleme süresi açısından asıl büyük sorun muhtemelen LLVM'nin kendisidir. Facebook, LLVM'nin instruction selection iyileştirmesi için çaba harcadığına göre durum daha iyiye gidecektir.

[functor]

Araştırınca gerçekten öyle olduğunu gördüm. Ben zamanın büyük kısmının ownership ile ilgili type check’e harcandığını sanıyordum ama LLVM backend kısmı da büyükmüş..

[ahwjdekf]

rust ilk çıktığında çok ilgi duymuş, biraz da çalışmıştım... unsafe kısmını görünce hemen bıraktım. Bunu neden öğrenip kullanmam gerektiğine dair mantıklı bir gerekçe bulamadım. Nasıl olsa biraz karmaşık olan programlarda unsafe kullanmak zorunda kalıyorsunuz. Ama o zaman da Rust'ın bu kadar övündüğü güvenlik ortadan kalkıyor. Bunu neden kullanalım ki?

[mastotron]

Rust'ta unsafe, yalnızca düşük seviyeli kodlama yaparken gerekir; genel uygulama yazarken ise neredeyse hiç kullanmanız gerekmez denebilir.

Ayrıca unsafe blok içinde bir bellek sorunu ortaya çıksa bile, sorunun oluştuğu kısmın unsafe blok içinde olduğu dil düzeyinde garanti edildiğinden, hata ayıklamayı kolaylaştırma gibi bir avantajı da vardır.

[functor]

unsafe var diye "Bunu neden kullanıyoruz?" diye soracaksanız, en baştan C/C++ kullanmamanız gerekmiyor mu?

[ahwjdekf]

C++ da gelişmeye devam ediyor; unsafe kullanacaksam zaten doğrudan C++ kullanırım, sırf bunun için RUST öğrenip kullanma gereği hissetmiyorum.

[functor]

Tüm Rust programlamalarında unsafe gerekmez.
unsafe gerektirecek kadar hassas bellek manipülasyonu genelde kütüphane geliştirmeye kaydığı için, (muhtemelen en büyük talebin olduğu) uygulama geliştirme tarafında unsafe kullanmak zorunda kalınacağını pek sanmıyorum.
C++'ın da gelişmeye devam ettiği doğru, ama geriye dönük uyumluluk için taşınan miras gerçekten çok can yakıyor. Sırf bir unsafe yüzünden rahatsız oluyorsanız, sanırım C++'ın bütün özelliklerinden de hoşlanmıyor olursunuz :)

[alstjr7375]

Bu yüzden unsafe tavsiye edilmiyor.
safe kullanırsanız, her şeyin unsafe ya da C/C++ kadar güvensiz olmasından daha güvenli olur.
https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf

[ahwjdekf]

unsafe gibi belirsiz bir mekanizma olmasa, Rust C++ için gerçek bir alternatif olabilir.

[jjpark78]

Keşke FFI biraz daha kullanıcı dostu olsaydı diye düşünüyorum.. Bileşik yapıları FFI üzerinden harici kütüphanelerle alıp vermeye çalışmıştım ve bunun çok acı verici olduğuna dair bir anım var.

[alstjr7375]

Hatta Rust'tan Rust'a bile kolay olmadığı için..
https://github.com/rodrimati1992/abi_stable_crates

[jjpark78]

MS'in Rust'ı aktif şekilde desteklediği durumun bir uzantısı olarak bakarsak, oldukça doğal bir açıklama gibi görünüyor.

[colus001]

O kadar inatçı Torvalds bile Rust'ı benimsediyse, öğrenenlerin de giderek azaldığı bir dili sırf kullanmayı sürdürmek için devam ettirmeye gerek görmüyorum.

[ahwjdekf]

Bellekle ilgili hatalar Rust kullanılıyor diye asla tamamen ortadan kalkmaz. Hata yapan insanlar, önlerine hangi dili koyarsanız koyun yine bol bol hata üretir. C++ şu anda hiçbir sorun olmadan verimli şekilde gayet iyi kullanılıyor; neyi kaldırıyorsunuz ki? Gerçekten de savaş çıkaracak türden bir bomba açıklamayı gelişigüzel yapmış.

[functor]

C/C++'ın hiçbir sorun olmadan verimli şekilde kullanıldığını söylemek zor; tarih boyunca C/C++ kaynaklı sayısız bellekle ilgili hata patlak verdi ve muhtemelen şu anda da bir yerlerde patlamaya devam ediyor. (Bu sayede pek çok PL/SE araştırmacısı geçimini sağladı gerçi.)
Microsoft'un açıkladığı verilere göre güvenlik açıklarının %70'i bellekle ilgili hatalardan kaynaklanıyor (https://zdnet.com/article/…)
Chromium projesinin yaptığı araştırma da benzer sonuç veriyor (https://www.chromium.org/Home/chromium-security/memory-safety/); burada da yine hataların neredeyse %70'i bellekle ilgiliydi.

[jjpark78]

Windows çekirdeği hatalarının çoğu bellekle ilgili hatalar ve
Rust ile geliştirilen kısımlarda bu hataların belirgin biçimde azaldığına dair eski bir haberi bir yerde görmüştüm..

Dilin doğası gereği readonly kullanımını güçlü biçimde teşvik eden bir tasarıma sahip olması nedeniyle, C++'tan daha güvenli bir dil tasarımına sahip olduğunu inkâr etmek zor gibi görünüyor. Ancak bu yüzden daha önce hiç duymadığımız sahiplik diye bir kavram ortaya çıkıyor ve programlama zorlaşıyor tabii.

Ayrıca çok iyi tasarlanmış C++ koduna kıyasla kabaca yazılmış Rust kodunun bile istatistiksel olarak daha hızlı çalıştığı yönünde bir performans avantajı da var.

[lordang]

Galiba biraz tartışma yaratabilecek bir şey söylemiş. haha
Bence C++, fazla eski olduğu için geriye dönük uyumluluğa takılıp kalıyor ve bu yüzden modernleşmesi yavaş ilerliyor.
Ayrıca geriye dönük uyumluluğu titizlikle koruyup bir yandan da modern şeyler ekleyince, aynı işi yapmanın fazlasıyla çok yolu ortaya çıkıyor; bence bu da yeni başlayanlar için giriş engelini daha da yükseltiyor.
Ben de artık C++ yerine Rust'ın daha iyi olduğunu düşünüyorum. Bellek yönetimiyle ilgili hataları bulmak için gözlerimizin kızardığı günler artık geride kalsın.

[jjpark78]

Evet, doğru.. Sıfırdan başlayan bir geliştirme projesiyse, özellikle C++ seçmek için bir neden yok..

[kandk]

Kesinlikle katılıyorum

[loblue]

Rust kullanmak istesem de ancak yardımcı olarak kullanabiliyorum; iş açısından hâlâ pek kullanacak bir alan yok.
Bu yüzden bir türlü tam alışamıyorum, kısa süre elimi çekince de unutuyorum...
Kesinlikle hoşuma gidiyor ve kullanmak istiyorum ama... hehe

[koreacglee]

Heap kullanımı verimliliği için bir kez olsun bellek havuzu yazmayı denememiş olanlar, durmadan RUST diye geveliyor haha Azure CTO’nun sanki sektör standardını temsil edecek kadar ağırlığı olan bir görüş sunduğu yok; elbette Microsoft geneliyle sınırlı olarak bile şirketin resmi duruşunu temsil eden bir fikir de değil, sadece bir anda ne tutmuşsa tamamen kendi öznel düşüncesini gevelemekten ibaret olabilir... C++’ı düzgün bilmeyenler Rust’ı da düzgün yapabilecek mi? Neyse, ortalık boş konuşanlarla dolu.

[functor]

Üslubunuzdan itibaren bayağılığınızı açıkça ortaya koyuyorsunuz. Kolay gelsin.