C# vs Kotlin

Насколько логично звучит для вас фраза "В русском языке стальные предметы обычно тяжелые, а деревянные — лёгкие"? Вроде бы и правильно по смыслу, а сравнение иголок с бревнами мы проведем по категории не-обычно. Но при чем тут русский язык?

И я не собираюсь переубеждать лично вас, но на таких статьях в том числе учатся люди, которые потом придут к нам на собеседование и будут как заученную мантру повторять "ссылочные типы хранятся на стеке, а значимые в куче". Может быть, прочтя комментарии, они задумаются "хм, а ведь и правда, они же не кучевые и стековые, наверное, неспроста!"

По вашей же ссылке я читаю

A class or a record is a reference type. When an object of the type is created, the variable to which the object is assigned holds only a reference to that memory. When the object reference is assigned to a new variable, the new variable refers to the original object. Changes made through one variable are reflected in the other variable because they both refer to the same data.

A struct is a value type. When a struct is created, the variable to which the struct is assigned holds the struct's actual data. When the struct is assigned to a new variable, it's copied. The new variable and the original variable therefore contain two separate copies of the same data. Changes made to one copy don't affect the other copy.

И только потом идет про кучу.

Действительно, догадаться можно, но чтобы поставить собеседуемого в тупик лучше спрашивать про боксинг, и вот тогда процент догадывающихся резко упадёт.

Кстати, по моей практике, нет. Про boxing/unboxing большинство что-то слышали и с разной степенью уверенности могут ответить, что в случае боксинга значение попадет в кучу.

Всё-таки, на мой взгляд, то, как присваиваются значения — это важное, но всё-таки следствие того, где значения располагаются. Также, например, важным следствием является то, как идёт очистка памяти от значений.

Не могу в полной мере согласиться. Представьте, что в рантайме .NET 8 кроме стека и кучи появилась какая-нибудь "яма", и рантайм будет сам решать, когда выделять память в куче, а когда в яме. Семантика типов-значений и типов-ссылок от этого не изменится — в переменных значимых типов по-прежнему будет храниться само значение, а в переменных ссылочных типов — ссылка на значение, хранящееся в куче или в яме, со всеми вытекающими особенностями присваивания.

Хотя постойте… Зачем представлять? Уже есть Large Object Heap, и рантайм решает за нас, аллоцировать память в SOH или в LOH. И да, разработчику иногда важно представлять, где произойдет аллокация, чтобы оптимизировать производительность, но с точки зрения языка C# разницы между "small" reference type и "large" reference type нет.

Позвольте мне также побыть занудой и заметить, что локальные переменные не размещаются на стеке, там размещаются значения локальных переменных ;) Но всё-таки, «типы размещаются на стеке» — это удобное упрощение, как мне кажется.

Можно я тоже побуду занудой? Значения локальных переменных любых типов могут располагаться на стеке; могут располагаться в регистрах процессора; могут располагаться в куче, если на ними создаётся замыкание; могут вообще нигде не располагаться.

.

Подскажите пожалуйста, как это можно загуглить?

А в чем практическое различие? В котлине лямбды и ссылки на методы взаимозаменяемые:

class Greeter(
    private val name: String  
) {

    fun greet(printer: (String) -> Unit) =
        printer("Hello $name!!!")

}

object Writer {

    fun write(message: String) = print(message) 

}

val greeter = Greeter("World")
greeter.greet { message -> print(message) } //Лямбда
greeter.greet(Writer::write) //Ссылка на функцию

В котлине для подобного есть lateinit

class Service1 {

    @Inject
    lateinit var logger: ILogger

    fun doSomething() {
        logger.info("test")
    }

}

P.S. Очень странно в C# выглядит выражение null!, то есть это null, но мы уверены, что это не null