C Programlama Dili (C dilinin sorunları)

• Bellek sorunları: GC, statik analiz vb. hiçbir aracın yardımını almaz.

• Tanımsız davranış: Daha çok düşük seviye ortamlar için kullanılmaya başlandı ve optimizasyon talebi yüksekti; optimizasyon için tanımsız davranışlar arttı. Düşük seviye performans ile taşınabilirliğin iki avantajını aynı anda elde edemedi.

• Büyük ölçekli programlamaya uygun değil: Modül ve paket yöneticisinin yokluğu. #pragma once gibi yaygın kullanılan şeylerin bile standartta yeri yok.

[ffdd270]

İyi yazıyı paylaştığınız için teşekkürler. Ancak küçük bir noktada kafama takılan bir şey olduğu için yorum bırakıyorum.

• Muhtemelen ilk yazdığınız 2011 yılında bunlar yoktu, ama artık birkaç C paket yöneticisi çıktı. Conan da var, Microsoft'un vcpkg'si de var. npm'e kıyasla birkaç eksikleri var (vcpkg'de sürüm yönetimi hâlâ beta etiketi taşıyor, conan'da ise vcpkg'ye göre daha az kaynak var), ancak hiç olmadığı döneme göre çok daha iyi hale geldi.

[lifthrasiir]

Yazıyı yazan benim (haha...). Site şu anda soft release aşamasında ve deneysel olarak içerik yazıyor olduğum için, içeriğin sürekli olarak değiştirilebileceğini anlayışla karşılamanızı rica ederim. Kendim de doğrudan takip ediyorum ama e-postayla görüş göndermeniz de mümkün, bunu da not edebilirsiniz.

vcpkg, söylediğiniz gibi şu anda en umut verici paket yöneticisi gibi görünüyor ve Conan da aslında epey eskiden beri var olan bir proje (ilk yazım zamanı ile de çok uzak değil). Ancak bu projelerin en büyük özelliği, kendilerinin bir build system'e sahip olmaması; yani meta build system olmalarıdır. (Ana destek hedeflerinden biri olan CMake'in kendisinin de bir meta build system olduğunu düşünürsek, belki de meta-meta build system sayılabilir...) Bu yüzden build system'in kendisinden kaynaklanan sorunları doğrudan çözmeleri pek mümkün değil. vcpkg'de bu konuda biraz daha düşünülmüş izler var; örneğin aynı bağımlılığın farklı sürümleri, bir projede (farklı bağımlılık yolları üzerinden) gerekliyse enlistment'i bölmek mümkün. Ama bu da build system'in kendi sınırlarını aşmak için kullanılan bir geçici çözümden ibaret. Örneğin Rust ve Cargo'da bu durumda iki sürüm de build edilir ve tek bir crate içinden bunlara başvurmakta sorun yaşanmaz.

Ayrıca vcpkg'nin şu anda Visual Studio içinde NuGet düzeyinde bir araç entegrasyonuna bile sahip olmadığı anlaşılıyor (yalnızca MSBuild entegrasyonu var gibi...), Linux/BSD dağıtımlarının paket yöneticileriyle entegrasyonu da pek gelişmiş görünmüyor. Bu sorun, şu anda dil bazlı paket yöneticilerinin karşı karşıya olduğu en büyük problemlerden biri aslında; Rust gibi yeni diller bunu tek tek cepheleri aşarak çözüyor, ama C/C++ paket yöneticilerinin mutlaka mevcut sistemlerle entegrasyonu hedeflemesi gerekirken bu konu hâlâ ağır ilerliyor. Ancak bu kısım çözüldükten sonra vcpkg türü araçların C/C++ geliştirmede genel olarak kullanılabilir araçlar hâline geldiği söylenebilir. Bunun henüz gerçekleşmemiş olması, yazıda paket sistemlerini düşük değerlendirmemin başlıca nedenidir. (Yazıda sözünü ettiğim single-file library bolluğu da, vcpkg türü sistemlerin o kadar da güçlü bir çekicilik oluşturamadığının dolaylı bir kanıtı sayılabilir.)

[ffdd270]

Ayrıntılı yanıt için teşekkürler. Sonuçta temeli = m=.. derleme olduğu için, npm ya da diğer paket yöneticilerinden farklı olarak aşılamayan bir duvar var gibi görünüyor. vcpkg de son zamanlarda sürüm konusunda epey kafa yoruyor gibi, ama bunu aşmak kolay olmayacak gibi duruyor.

Acaba C++20'nin modül sistemi bu sorunun çözümü olabilir mi diye de düşünüyorum ama... o zaman kapsam C dilini aşmış oluyor (...). Görünüşe göre C dili için artık sadece dikenli bir yol kalmış. Şimdi kalkıp C20'yi standartlaştırsalar bile, sürüm geçiş oranı C++'taki kadar yüksek olmayacaktır..

[functor]

İyi görüşleriniz için teşekkür ederim.

Benim kişisel düşüncem şöyle. Birkaç C paket yöneticisinin olması iyi bir gelişme, ancak sorun bunların çok fazla kullanılmıyor olması gibi görünüyor. Daha doğrusu, C’nin zaten çok büyük bir mirası olduğu için, yukarıda bahsedilen sorunları çözmek adına artık fazla geç kalınmış olabileceğini düşünüyorum. Bu yüzden de Rust gibi yeni dillere geçmeye yönelik girişimler daha fazla değil mi?

[ffdd270]

Söylediklerinizi dinleyip yeniden düşününce, yukarıdaki paket yöneticilerinin odağının C dilinin ömrünü uzatmaktan çok, C dilini kullanmak zorunda olan programcıların ömrünü uzatmaya kaydığı gibi görünüyor.

Artık yeni bir eve (C++, Rust...) taşınma zamanı geldiğinde, eski evdeki OpenGL ya da Lua gibi mobilyalara ihtiyaç duyulduğunda, paket yöneticisi yoksa bunları elle taşımak gerekiyordu (linkleme yap, make çalıştır, DLL ya da lib sürümleri tutmadığı için saç baş yol, LNK hatalarına bakarken kendini aşağı atasın gelsin...) ama artık paket yöneticileri olduğu için bunu profesyonel taşımacılık gibi tertemiz şekilde taşıyabiliyoruz. Ortaya çıkarılmış o kadar çok şey var ki, yeni evde de kullanmak gereken zamanlar olacaktır...

Artık dilin kendi avantajlarından çok, bugüne kadar birikmiş tecrübe ve ekosistemin getirisi daha ağır basıyorsa, bunun gerçekten ölmekte olan bir dil olduğunu hissettiriyor (...

[galadbran]

Rust'ın birçok açıdan next C/C++ imajını en güçlü şekilde taşıdığı görülüyor gibi. (next olarak görülen birkaç dil arasında görece en karmaşık olduğu yönünde bir imaj da var... haha)

[dalinaum]

Görünüşe göre Rust yalnızca imaj olarak değil, gerçekte de zor.