12:55 Rust övdük ama örnek veremedik. Buraya ekleyeyim. fn main() { let x = 10; print_value(&x); // Passing x as an immutable reference } fn print_value(val: &i32) { println!("The value is: {}", val); // val cannot be modified here because it is an immutable reference }
11:00 Immutability, pass by reference/value konusunda Swift dili de C#'a benzer mekanizmalara sahip, ancak çok daha yeni bir dil olmasından dolayı (2014 doğumlu), geçmişten ders alarak 'less error prone' olması için immutability ve pass-by-copy ana mekanizma olduğundan (Swift ilk protocol-oriented dil olarak bahsedilmişti bir WWDC konuşmasında), yani C# gibi OOP'den çevirme bir dil olmadığından (aksine çok 'functional' bir şekilde geliştirildiğinden), C#'ın 'in' kelimesiyle ve Rust'ın da 1500 farklı yoldan yapmaya izin verdiği şeyi (eminim en az 1500 tane vardır) daha native bir şekilde hallettiğini düşünüyorum. Örnek olarak: Swift'te tıpkı C# gibi iki farklı 'data type tanımlama yolu' sunuyor, 'struct' ve 'class'. Her iki keyword'de user defined data type oluşturmak için kullanılsa da arada Aristoteles Platon gibi ayrım var, struct ile oluşturulan her şey bir 'value' olarak muhafaza ediliyor, class ile oluşturulanlar ise 'reference'. (Struct'lar da tıpkı diğer OOP dillerindeki class'lar gibi tüm özelliklere sahipler, yani fonksiyon içerebilirler C structları gibi sadece variable'dan ibaret değiller.) Ve tüm Foundation kütüphanesi, yani Swift diliyle gelen temel veri tipleri (koleksiyon türleri de dahil--array, set, dictionary) struct olarak tanımlanmış. Bu da demek oluyor ki eğer bir milyon eleman içeren bir diziniz varsa ve bunu bir fonksiyona gönderirseniz, kopyalanacaktır. Bu kopya mekanizması neden 'iyi' kabul ediliyor uzun (ve çok önemli) bir konu olduğundan yorumda girmiyorum. Ancak Swift compiler akıllı bir iş yapıyor ve CoW (copy-on-write) kullanıyor. Yani veri bir yerden başka bir yere yollandığında eğer ona tutulan başka bir referans yoksa, veya gönderildiği yerde bir değişikliğe uğramıyorsa gereksiz kopya oluşturulmuyor, ve dil bunu ana mekanizma olarak 'under the hood' gerçekleştiriyor, 'in' gibi keywordlere ihtiyaç duymadan. Bu mekanizma tüm built-in veri tiplerinde çalışıyor, user-defined olanlarda ise tamamı 'value' türünde değerler içeren türler için bazen yapabiliyor (anladığım kadarıyla ya bazen ya hiç, genel olarak hiçe daha yakın, Chris Lattner çok fazla defensive copy olduğundan şikayetçiydi.) User-defined türlerde ise 'isKnownUniquelyReferenced' kullanılarak developer'ın kendisi tarafından eklenebiliyor. (Resmi dokümantasyon: The isKnownUniquelyReferenced(_:) function is useful for implementing the copy-on-write optimization for the deep storage of value types.) Ek olarak, Elixir'de 'name shadowing' oluşup olayın karmaşıklaşması ise yine bence Swift hariç diğer tüm dilllerde olan bir sorundan dolayı, o da variable ve value arasındaki farkın dil tarafından developer'ın gözüne yeterince sokulmaması. Yorum yeterince uzadığından buna değinmiyorum, ama çok önemli buluyorum. Son olarak Serialization için bir çeviri önerim var: dümdüz etmek. Bir dil geliştirirken modüller arası gereksiz bilgi paylaşmamak için encapsulation, polymorphism, access modifiers gibi mekanizmalar dile entegre edilmeye çalışılıyor, sonra serialization için gerekli reflection/introspection mekanizmaları ise verinin yanında bunları da dümdüz ediyor (bir class'ı JSON yaparken tüm 'private' field'ların da eklenmesi gibi). Bu ikisi arasında bir gerilim olduğunu düşünüyorum, eğer yanlış anlamadıysam. Birbirini etkilemeyecek şekilde bir yol olup olmadığını araştırmıştım, çok net bir cevap aklımda yok. Bu arada evime internet geldi, telefon kablosu değişti, kısa süre içerisinde DM'den yürümeyi düşünüyorum daha önceki davetinize yönelik. Yorum biraz uzun, kusura bakmayın. Uluslararası Swift gönüllüsü gibi davranıyorum arada.
Yardimci olayim. Rust'ta tek bir degiskenin birden fazla read only ve en fazla 1 write only referansi olabilir. bunlar dusurulurse yerine yenisi gelebilir. ve sadece tek sahibi olabilir. yani sadece memory allocation ile ilgili degil. bunlar asama asama thread safe kod yazmaya kadar gidiyor. en onemli olay ise bunun bir secenek degil, zorunluluk olmasi.
12:55 Rust övdük ama örnek veremedik. Buraya ekleyeyim.
fn main() {
let x = 10;
print_value(&x); // Passing x as an immutable reference
}
fn print_value(val: &i32) {
println!("The value is: {}", val);
// val cannot be modified here because it is an immutable reference
}
C++ ve Rust candır gerisi heyecandır
Evlen de artık hayatın serialization'a girsin!
11:00
Immutability, pass by reference/value konusunda Swift dili de C#'a benzer mekanizmalara sahip, ancak çok daha yeni bir dil olmasından dolayı (2014 doğumlu), geçmişten ders alarak 'less error prone' olması için immutability ve pass-by-copy ana mekanizma olduğundan (Swift ilk protocol-oriented dil olarak bahsedilmişti bir WWDC konuşmasında), yani C# gibi OOP'den çevirme bir dil olmadığından (aksine çok 'functional' bir şekilde geliştirildiğinden), C#'ın 'in' kelimesiyle ve Rust'ın da 1500 farklı yoldan yapmaya izin verdiği şeyi (eminim en az 1500 tane vardır) daha native bir şekilde hallettiğini düşünüyorum.
Örnek olarak: Swift'te tıpkı C# gibi iki farklı 'data type tanımlama yolu' sunuyor, 'struct' ve 'class'. Her iki keyword'de user defined data type oluşturmak için kullanılsa da arada Aristoteles Platon gibi ayrım var, struct ile oluşturulan her şey bir 'value' olarak muhafaza ediliyor, class ile oluşturulanlar ise 'reference'. (Struct'lar da tıpkı diğer OOP dillerindeki class'lar gibi tüm özelliklere sahipler, yani fonksiyon içerebilirler C structları gibi sadece variable'dan ibaret değiller.)
Ve tüm Foundation kütüphanesi, yani Swift diliyle gelen temel veri tipleri (koleksiyon türleri de dahil--array, set, dictionary) struct olarak tanımlanmış. Bu da demek oluyor ki eğer bir milyon eleman içeren bir diziniz varsa ve bunu bir fonksiyona gönderirseniz, kopyalanacaktır. Bu kopya mekanizması neden 'iyi' kabul ediliyor uzun (ve çok önemli) bir konu olduğundan yorumda girmiyorum.
Ancak Swift compiler akıllı bir iş yapıyor ve CoW (copy-on-write) kullanıyor. Yani veri bir yerden başka bir yere yollandığında eğer ona tutulan başka bir referans yoksa, veya gönderildiği yerde bir değişikliğe uğramıyorsa gereksiz kopya oluşturulmuyor, ve dil bunu ana mekanizma olarak 'under the hood' gerçekleştiriyor, 'in' gibi keywordlere ihtiyaç duymadan.
Bu mekanizma tüm built-in veri tiplerinde çalışıyor, user-defined olanlarda ise tamamı 'value' türünde değerler içeren türler için bazen yapabiliyor (anladığım kadarıyla ya bazen ya hiç, genel olarak hiçe daha yakın, Chris Lattner çok fazla defensive copy olduğundan şikayetçiydi.)
User-defined türlerde ise 'isKnownUniquelyReferenced' kullanılarak developer'ın kendisi tarafından eklenebiliyor. (Resmi dokümantasyon: The isKnownUniquelyReferenced(_:) function is useful for implementing the copy-on-write optimization for the deep storage of value types.)
Ek olarak, Elixir'de 'name shadowing' oluşup olayın karmaşıklaşması ise yine bence Swift hariç diğer tüm dilllerde olan bir sorundan dolayı, o da variable ve value arasındaki farkın dil tarafından developer'ın gözüne yeterince sokulmaması. Yorum yeterince uzadığından buna değinmiyorum, ama çok önemli buluyorum.
Son olarak Serialization için bir çeviri önerim var: dümdüz etmek. Bir dil geliştirirken modüller arası gereksiz bilgi paylaşmamak için encapsulation, polymorphism, access modifiers gibi mekanizmalar dile entegre edilmeye çalışılıyor, sonra serialization için gerekli reflection/introspection mekanizmaları ise verinin yanında bunları da dümdüz ediyor (bir class'ı JSON yaparken tüm 'private' field'ların da eklenmesi gibi). Bu ikisi arasında bir gerilim olduğunu düşünüyorum, eğer yanlış anlamadıysam. Birbirini etkilemeyecek şekilde bir yol olup olmadığını araştırmıştım, çok net bir cevap aklımda yok.
Bu arada evime internet geldi, telefon kablosu değişti, kısa süre içerisinde DM'den yürümeyi düşünüyorum daha önceki davetinize yönelik. Yorum biraz uzun, kusura bakmayın. Uluslararası Swift gönüllüsü gibi davranıyorum arada.
Yardimci olayim. Rust'ta tek bir degiskenin birden fazla read only ve en fazla 1 write only referansi olabilir. bunlar dusurulurse yerine yenisi gelebilir. ve sadece tek sahibi olabilir. yani sadece memory allocation ile ilgili degil. bunlar asama asama thread safe kod yazmaya kadar gidiyor. en onemli olay ise bunun bir secenek degil, zorunluluk olmasi.
Serileşme bana daha güzel geldi. ChatGTP'ye soralım ne demekmiş?
Global değişken atanması lazim işte