Про JMM не сказал, потому, что настолько очевидно, что даже не вспомнил :). Знание GC конечно очень помогает с эффективностью, но ещё помогает избежать OutOfMemory.
Они всего лишь пример реализации, больше ни для чего эти языки я не упоминал. Что видит программист — вот что важно. В этих языках он не видит этих деталей, они ему не нужны.
В Java программист эти детали обязан знать. Обязан знать, что объекты представлены переменными, в которых на самом деле находится указатель, а примитивные значения хранятся в памяти непосредственно. Обязан знать, почему в дженерик можно поставить параметром только класс. Обязан знать, как работает сборщик мусора. Это нужно ему для того, чтобы писать корректно работающие программы.
Кого это беспокоит? Кто об этом будет думать? Разработчик Go? Да не в жизни. Я говорю о философии языка и забота о кеш френдли структурах там никаким местом. Для таких целей есть другие языки.
Больше всего в Джаве раздражает, что иногда единственный ответ на вопрос как что-то сделать — сменить язык. Наличие структур — фича важная не только для кэша. Также это позволяет делать типы данных, которые по умолчанию передаются по значению, что важно уже не для оптимизаций, а для создания хорошего кода.
Какие там структуры данных, когда у нас рантайм одна большая магическая коробка, в которой происходит что-то, о чем никто кроме самого рантайма не знает.
Что в Java, что в C# что, наверное, в Go рантайм магической коробкой не является. Программист, повторюсь, обязан знать, хотя бы в общих чертах, как оно устроено внутри. Какие гарантии даёт рантайм, а каких он не даёт. Как можно писать код, а как нельзя. Если вы считаете, что это не так — пересмотрите свои взгляды, это сильно поможет в работе.
Go сделан для создания микросервисов, это прям вот вся его суть.
Go сделан для серверного бэкенда — это несколько шире, чем просто микросервисы. И это пока нет графических библиотек. Консольный софт на Go пишется только в путь — посмотрите на platinum searcher.
Поэтому я уточнил про специфику — C# не об этом и подавляющее большинство софта на это плюет.
Оптимизация структур данных под процессорный кэш нужна когда есть большой набор данных, который надо обработать. В серверном коде ситуация очень частая.
И например то, что за каким-нить DateTime на самом деле стоит структура — кому это интересно? Да никому. Кто от этого что-то выигрывает? Да никто.
Это интересно каждому, кто хочет знать, можно ли как-то изменить DateTime, переданную в качестве параметра. И интересно тем, кто хочет обрабатывать как можно больше DateTime в секунду.
В общем что я хочу этим всем сказать. Отсутствие структур в стиле С# уже оказало медвежью услугу Джаве. Кейсов, когда это нужно в программировании сервер-сайд — достаточно много. В программировании вообще — гораздо больше. Я как программист, в обмен на возможность обрабатывать эти кейсы, не меняя язык, готов смириться с тем, что мне иногда придётся думать что передавать — указатель или всю структуру целиком.
При том, что вы предложили сделать всё указателями, как там.
Я про них это все знаю.
Тогда непонятно, почему вы предложили всё сделать указателями, как там, ведь там не всё сделано указателями.
Тут нужно одно, скорее всего только указатели, что разом решит мутные вопросы, из синтаксиса уйдет лишнее, а минусов мы не получим.
Мы получим невозможность сделать массив структур, компактно расположенный в памяти, что в некоторых случаях плохо скажется на производительности. Вы, кстати постоянно забываете уточнить, что указателями хотите сделать не всё, а только объекты.
Структуры больше фенечка и объективных преимуществ в рамках платформы и ее специфики в основном не несут.
Отсутствие этой фенечки не позволяет писать код, который учитывает наличие процессорного кеша.
Пока что я вижу в Go только один вид простоты — если ты долго писал на Си — Go понятен и прост. В нём решены очень многие проблемы этого языка и решены как раз в стиле, который симпатичен программистам, знающим и любящим этот язык. Они не теряют вообще ничего, а приобретают много. Если ты всю жизнь писал на Си, но тебе надоели драйвера и хочется веба — тебе дорога в Go.
С точки зрения тех, кто пишет например на Java — Go не прост, но понятен. Они потеряли дженерики и исключения, но приобрели быструю компиляцию, быстрый рантайм, структуры, которые можно передавать по значению и понятную многопоточность. Джава очень долго не развивалась, те кто на ней программируют привыкли к бойлерплейту как к данности. Обнаружив, что может быть бойлерплейт, но без тормозов и при этом со сборщиком мусора, который к тому же отрабатывает за гарантированное время они испытывают трепет, близкий к священному. Ради такого отсутствие дженериков можно потерпеть, тем более, что их всё равно когда-нибудь добавят, как добавили в Джаву.
Я предложил сделать все указателями как это в Java и C#.
Только вот в Java указателями сделаны объекты и больше ничего. И тот факт, что на объект можно только получить указатель иногда неслабо убивает перформанс.
А в С# есть структуры, которые указателями не являются. И есть ссылки, с помощью которых можно модифицировать и передаваемые в функцию примитивные переменные и структуры. Это очень удобно.
Почти. Большиство задач, которые нужно решить потребителю-владельцу очень просты и поэтому для их решения можно обратиться к низкоквалифицированным программистам на php, а php в свою очередь позволяет низкоквалифицированным программистам быстро и дёшево решать простые задачи.
С ростом сложности задачи использование php становится всё менее и менее оправданным. Пока в один прекрасный момент система не разрастается до такого размера, что для продолжения работы требует специалистов с очень высокой квалификацией. За решения задачи такого рода с помощью, например, java можно было бы заплатить существенно меньше денег. Но переписывать уже поздно. Вот такая инкрементальность.
Но php всё равно очень популярен потому что:
1. Большинство систем не разрастается до такого уровня.
2. Язык развивается давая разработчикам средства для решения всё более сложных задач.
Ну я понял, что стёб. И я также согласен, что реально для того, чтобы писать на php надо знать очень много — что такое http, что такое сервер, как это всё работает и т. д… Всё так.
Только деньги с php можно начать получать уже после того, как понял что можно написать <?php pring «hello» ?> и научился заливать это на ftp. Деньги будут платить уже за незначительные правки существующих незначительных сайтов. Для того, чтобы получить деньги с С++ надо учиться ещё долго. Вот что я имею в виду, когда говорю про низкий порог вхождения.
Да, конечно. Вы как раз продемонстрировали очень хороший пример. У вас не установлен сервер, который будет обрабатывать php.
Предвижу вашу реакцию — чего за сервер, мне что его ставить, почему всё так сложно? Нынче есть много пакетов, которые ставят всю инфраструктуру в один клик и такой пакет вам, скорее всего поставит старший товарищ. Или вы сам по мануалу.
Это, кстати, часть инкрементального обучения — узнать, что для php нужен сервер. Следующим шагом будет выводить вместо hello текущую дату. Потому ещё что-нибудь такое. Потом вам расскажут, как делать пункты меню.
Потом вам захочется выводить на странице то, что ввёл пользователь в какое-нибудь поле. И так далее.
как понять насколько у меня «большущая структура», что пора использовать указатель?
На x86_64 указатель занимает 64 байта. Как только ваша структура начинает занимать более 64 байт имеет смысл использовать указатель. Если сформулировать по другому — указатель имеет смысл исползовать с момента, когда копирование указателя происходит гораздо быстрее, чем копирование структуры. «Гораздо» — в каждом случае своё. Иногда можно подождать даже милисекунду, потому что объекты создаются раз в минуту. А иногда подождать нельзя вообще, потому что объекты создаются непрерывно.
Спасибо за ссылку, ознакомился с COW в php. Если я правильно понял, для объектов COW в php не работает ибо в переменной содержится id объекта, а не сам объект. COW для примитивных значений в php это наверное разумно, так как они занимают в памяти много места. Но в Go эти значения занимают столько же или меньше, чем ссылки на них, поэтому тут COW может даже помешать.
Со строками, массивами и объектами, может это было бы полезно. Но подозреваю расплатой за такую штуку будет серьёзная просадка в производительности.
Таким образом move semantics никак не может являться частным случаем COW, потому, что там переменную, из которой вытащено значение, использовать нельзя категорически.
Но вот насчёт COW интересно. В каких языках есть COW, реализованный правильным способом?
Знак тождества, на мой взгляд, пытается поставить автор статьи. И лукавит, недоговаривая о том, что такое подход Нью-Джерси.
Я же хочу сказать, что пример с дженериками красноречиво демонстрирует, что по краней мере в случае с ними, простотой использования сознательно поступились в пользу простоты реализации.
COW это когда при необходимости записать значение в какую-нибудь переменную, значение записывается не туда, а в другой кусок памяти. После того, как процедура записи удачно завершена, система меняет область памяти, на которую ссылается переменная со старой на новую. Другие переменные, которые всё ещё ссылаются на старую область памяти — значения не изменят.
Move semantics — это когда вместо того, чтобы копировать содержимое области памяти, на которую ссылается переменная, в новую переменную, туда передаётся ссылка на старую область памяти. Старая переменная после этого считается не подлежащей к использованию. Копирования нет.
Возникает 2 вопроса.
1. Как move semantics может быть общим случаем для COW, если move semantics копирования не предполагает?
2. Как COW может устранить необходимость копирования созданного объекта, если там копирование есть по определению?
Даже если можно поспорить, является ли подход Нью-Джерси пост-фактум описанием Unix-философии, то совершенно точно можно быть уверенными, что создатели Go явно продвигали простоту, как ведущий элемент их философии.
Оригинал:
Even if the New Jersey method was a post facto straw-man description of the Unix philosophy or that of its creators, make no mistake that there has been an explicit endorsement of simplicity as a guiding philosophy from Go's creators.
Как по-моему правильно:
Даже если подход Нью-Джерси и оказался пост-фактум доведённым до абсурда описанием философии системы Unix или её создателей, без сомнения имело место явное продвижение простоты как руководящей философии создателей Go.
Общий смысл фразы у переводчика сохранён и я не стал бы его поправлять, если бы этот абзатц не был ключевым во всей статье. Статья в той или иной степени является ответом на древнюю публикацию Гэбриэла Worse is Better.
И главная мысль той публикации автором, на мой взгляд, совершенно извращена. Разница между подходом MIT и подходом Нью-Джерси, по мнению Гэбриэла, в том, что MIT ставит во главу угла простоту использования, а Нью-Джерси — простоту реализации.
В случае с языком программирования простота использования — это показатель, определяющий насколько просто писать программы на данном языке, а простота реализации — это насколько просто написать для него компилятор.
И в этом смысле автор прав, подход Нью-Джерси действительно выражен в Go очень ярко. Почему в Go нет дженериков? Потому, что для них сложно написать компилятор. Да, код с дженериками писать и читать проще, но простота реализации, согласно философии Нью-Джерси, важнее, чем простота использования. Такие дела.
И когда автор опускает тот факт, что речь о простоте использования против простоты реализации — он кривит душой и создаёт ложное впечатление что о философии MIT, что о Go.
По честному, в контексте статьи Worse is better, процитированный в начале абзац должен бы выглядеть вот так:
Даже если подход Нью-Джерси и оказался пост-фактум доведённым до абсурда описанием философии системы Unix или её создателей, без сомнения имело место явное продвижение простоты реализации, как руководящей философии создателей Go.
Больше всего в Джаве раздражает, что иногда единственный ответ на вопрос как что-то сделать — сменить язык. Наличие структур — фича важная не только для кэша. Также это позволяет делать типы данных, которые по умолчанию передаются по значению, что важно уже не для оптимизаций, а для создания хорошего кода.
Что в Java, что в C# что, наверное, в Go рантайм магической коробкой не является. Программист, повторюсь, обязан знать, хотя бы в общих чертах, как оно устроено внутри. Какие гарантии даёт рантайм, а каких он не даёт. Как можно писать код, а как нельзя. Если вы считаете, что это не так — пересмотрите свои взгляды, это сильно поможет в работе.
Go сделан для серверного бэкенда — это несколько шире, чем просто микросервисы. И это пока нет графических библиотек. Консольный софт на Go пишется только в путь — посмотрите на platinum searcher.
Оптимизация структур данных под процессорный кэш нужна когда есть большой набор данных, который надо обработать. В серверном коде ситуация очень частая.
Это интересно каждому, кто хочет знать, можно ли как-то изменить DateTime, переданную в качестве параметра. И интересно тем, кто хочет обрабатывать как можно больше DateTime в секунду.
В общем что я хочу этим всем сказать. Отсутствие структур в стиле С# уже оказало медвежью услугу Джаве. Кейсов, когда это нужно в программировании сервер-сайд — достаточно много. В программировании вообще — гораздо больше. Я как программист, в обмен на возможность обрабатывать эти кейсы, не меняя язык, готов смириться с тем, что мне иногда придётся думать что передавать — указатель или всю структуру целиком.
При том, что вы предложили сделать всё указателями, как там.
Тогда непонятно, почему вы предложили всё сделать указателями, как там, ведь там не всё сделано указателями.
Мы получим невозможность сделать массив структур, компактно расположенный в памяти, что в некоторых случаях плохо скажется на производительности. Вы, кстати постоянно забываете уточнить, что указателями хотите сделать не всё, а только объекты.
Отсутствие этой фенечки не позволяет писать код, который учитывает наличие процессорного кеша.
С точки зрения тех, кто пишет например на Java — Go не прост, но понятен. Они потеряли дженерики и исключения, но приобрели быструю компиляцию, быстрый рантайм, структуры, которые можно передавать по значению и понятную многопоточность. Джава очень долго не развивалась, те кто на ней программируют привыкли к бойлерплейту как к данности. Обнаружив, что может быть бойлерплейт, но без тормозов и при этом со сборщиком мусора, который к тому же отрабатывает за гарантированное время они испытывают трепет, близкий к священному. Ради такого отсутствие дженериков можно потерпеть, тем более, что их всё равно когда-нибудь добавят, как добавили в Джаву.
Только вот в Java указателями сделаны объекты и больше ничего. И тот факт, что на объект можно только получить указатель иногда неслабо убивает перформанс.
А в С# есть структуры, которые указателями не являются. И есть ссылки, с помощью которых можно модифицировать и передаваемые в функцию примитивные переменные и структуры. Это очень удобно.
С ростом сложности задачи использование php становится всё менее и менее оправданным. Пока в один прекрасный момент система не разрастается до такого размера, что для продолжения работы требует специалистов с очень высокой квалификацией. За решения задачи такого рода с помощью, например, java можно было бы заплатить существенно меньше денег. Но переписывать уже поздно. Вот такая инкрементальность.
Но php всё равно очень популярен потому что:
1. Большинство систем не разрастается до такого уровня.
2. Язык развивается давая разработчикам средства для решения всё более сложных задач.
Только деньги с php можно начать получать уже после того, как понял что можно написать <?php pring «hello» ?> и научился заливать это на ftp. Деньги будут платить уже за незначительные правки существующих незначительных сайтов. Для того, чтобы получить деньги с С++ надо учиться ещё долго. Вот что я имею в виду, когда говорю про низкий порог вхождения.
Предвижу вашу реакцию — чего за сервер, мне что его ставить, почему всё так сложно? Нынче есть много пакетов, которые ставят всю инфраструктуру в один клик и такой пакет вам, скорее всего поставит старший товарищ. Или вы сам по мануалу.
Это, кстати, часть инкрементального обучения — узнать, что для php нужен сервер. Следующим шагом будет выводить вместо hello текущую дату. Потому ещё что-нибудь такое. Потом вам расскажут, как делать пункты меню.
Потом вам захочется выводить на странице то, что ввёл пользователь в какое-нибудь поле. И так далее.
На x86_64 указатель занимает 64 байта. Как только ваша структура начинает занимать более 64 байт имеет смысл использовать указатель. Если сформулировать по другому — указатель имеет смысл исползовать с момента, когда копирование указателя происходит гораздо быстрее, чем копирование структуры. «Гораздо» — в каждом случае своё. Иногда можно подождать даже милисекунду, потому что объекты создаются раз в минуту. А иногда подождать нельзя вообще, потому что объекты создаются непрерывно.
Со строками, массивами и объектами, может это было бы полезно. Но подозреваю расплатой за такую штуку будет серьёзная просадка в производительности.
Но вот насчёт COW интересно. В каких языках есть COW, реализованный правильным способом?
Я же хочу сказать, что пример с дженериками красноречиво демонстрирует, что по краней мере в случае с ними, простотой использования сознательно поступились в пользу простоты реализации.
COW это когда при необходимости записать значение в какую-нибудь переменную, значение записывается не туда, а в другой кусок памяти. После того, как процедура записи удачно завершена, система меняет область памяти, на которую ссылается переменная со старой на новую. Другие переменные, которые всё ещё ссылаются на старую область памяти — значения не изменят.
Move semantics — это когда вместо того, чтобы копировать содержимое области памяти, на которую ссылается переменная, в новую переменную, туда передаётся ссылка на старую область памяти. Старая переменная после этого считается не подлежащей к использованию. Копирования нет.
Возникает 2 вопроса.
1. Как move semantics может быть общим случаем для COW, если move semantics копирования не предполагает?
2. Как COW может устранить необходимость копирования созданного объекта, если там копирование есть по определению?
Оригинал:
Как по-моему правильно:
Общий смысл фразы у переводчика сохранён и я не стал бы его поправлять, если бы этот абзатц не был ключевым во всей статье. Статья в той или иной степени является ответом на древнюю публикацию Гэбриэла Worse is Better.
И главная мысль той публикации автором, на мой взгляд, совершенно извращена. Разница между подходом MIT и подходом Нью-Джерси, по мнению Гэбриэла, в том, что MIT ставит во главу угла простоту использования, а Нью-Джерси — простоту реализации.
В случае с языком программирования простота использования — это показатель, определяющий насколько просто писать программы на данном языке, а простота реализации — это насколько просто написать для него компилятор.
И в этом смысле автор прав, подход Нью-Джерси действительно выражен в Go очень ярко. Почему в Go нет дженериков? Потому, что для них сложно написать компилятор. Да, код с дженериками писать и читать проще, но простота реализации, согласно философии Нью-Джерси, важнее, чем простота использования. Такие дела.
И когда автор опускает тот факт, что речь о простоте использования против простоты реализации — он кривит душой и создаёт ложное впечатление что о философии MIT, что о Go.
По честному, в контексте статьи Worse is better, процитированный в начале абзац должен бы выглядеть вот так:
Совершенно другое впечатление, не правда ли?