Ну как же, вот я например хочу использовать в своем приложении sdl2 (или любую другую библиотеку, написанную на C) через например вот такой враппер. Враппер при наличии только go вы может и соберете, а саму sdl2 кто будет собирать?
На понятно что gui приложение ты не соберёшь так, но это другое ограничение другого языка уже.
Таким образом можно собрать только относительно несложное приложение без зависимостей написанных на других языках. А другие языки были, есть и будут есть, потому что серебряных пуль не существует.
Ну собственно на этом можно и закончить :) Шутка (наполовину). А если серьезно - мы же берем случай не хелловорлда, а серьезного приложения с зависимостями, написанными на разных языках. То есть возвращаемся к началу - для "решения проблемы" (человек хочет попробовать новое приложение) ему нужно поставить go, поставить C/C++ компилятор, возможно, растокомпилятор (для зависимостей)... Боюсь, что с таким подходом у вас не получится значительно расширить пользовательскую аудиторию :)
в то время как в других языках эта проблема решена
Это в какой-то степени решено только в языках, которые имеют свой рантайм (типа упоминавшихся вами питона, явы или шарпика), там просто все эти проблемы переложены на рантайм - и опять же, только если у вас нет вызовов каких-то сторонних библиотек через native interface. Говорить же, что эта проблема решена в языке потому что он может статически слинковать бинарь - ну, ИМХО, такое. И опять же, этот статически слинкованный вами бинарь, даже если нет никаких условных плагинов (или вы их не забыли все трудолюбиво найти и добавить в пакет), все равно будет точно так же огребать в винде или макоси от паранойи с подписями, как у вас в статье написано.
Это только в теории так все просто, со сферическим конем в вакууме. На практике же например у используемых вами (возможно, даже не напрямую) библиотек бывают плагины, которые статически просто не линкуются, а подгружаются исключительно динамически (через dlopen() или подобные механизмы). Более того, на разных системах нужны разные плагины в зависимости от... много чего - например, где-то нужен плагин для Xorg протокола, а где-то для Wayland, версия библиотеки, установленная в системе, об этом в курсе, а то, что вы там статически себе прилинковали - нет. Го вам поможет только в наипростейшем случае хелловорлда, что-то чуть более сложное - и вы будете совершенно так же огребать.
Еще раз - я не хочу себе на машине компилятор go (это как минимум, еще раз повторюсь, что если само приложение написано на go, это не значит, что все его зависимости написаны на go) для того чтобы один раз запустить приложение на попробовать. Везде это решается бинарными пакетами, которые я просто скачиваю из некоего стора или хранилища пакетов. Я все еще не понимаю, чем условный go в этом плане лучше чем условный C++. Бинарный пакет есть бинарный пакет, и проблемы его установки никак не зависят от языка на котором он написан.
Везде наличие компилятора/интерпретатора языка даёт гарантию подключения зависимостей.
Еще раз - вот я хочу попробовать ваше приложение на винде. Вы считаете нормальным, что я для того, чтобы его попробовать, должен скачивать себе гошный тулчейн и сидеть собирать что-то там из исходников со всеми зависимостями (у которых могут быть свои тулчейны)? Или я все же должен иметь возможность скачать готовый бинарный пакет и установить его, как это делается обычно в винде, макоси и на большинстве линупсов (за исключением генту)? А если речь идет о бинарном пакете, то причем тут язык, и чем мне тут поможет установка гошного тулчейна (который нужен мне как собаке пятая нога)?
Честно говоря, я не очень понял претензии к языку. Установка неподписанных/ненотаризованных бинарей - это в любом случае проблемное дело в той же винде или в macOS вне зависимости от того, на каком языке написано то, из чего эти бинари собраны. А если вы хотите просто показать потенциальному пользователю свое приложение в режиме "скачать и запустить", то требовать, чтобы этот потенциальный пользователь имел тулчейн для его сборки (а скорее всего еще и тулчейны для сборки всех его зависимостей, ведь они могут быть написаны на разных языках), каким бы распрекрасным и удобным этот тулчейн ни был - ну, такое.
Вот мне кажется, что текущие компиляторы для х86/х64 кинут литерал в сегмент данных и ссылка никогда не пропадёт. Но это стандартом для всех систем и оптимизаторов! не гарантируется.
Вообще-то гарантируется: строковые литералы гарантированно имеют static storage duration:
Evaluating a string literal results in a string literal object with static storage duration.
Ну то есть в своих широковещательных заявлениях основываетесь не на какой-то статистике, а на собственных каких-то представлениях "из головы" и собственном опыте. Тогда стоит добавлять к своим заявлениям "ИМХО", а не преподносить их как факт. Не ведите себя как растофанатик, ведите себя как инженер.
какое-то C++ сектантство в духе конторы на букву "я", вынуждающее вас оставлять агрессивные комментарии и прибегать к демагогическим приемам
Здорово, здорово. Нечем подкрепить свои утверждения - обвини собеседника в сектантстве и демагогических приемах. С вами я на обозримое будущее разговор закончил.
Вас не смущает, что почти все программисты на Rust это и есть бывшие программисты на C++?
Я вот заметил, что вы очень любите делать широковещательные и ничем не подкрепленные заявления. Откуда дровишки что "почти все программисты на Rust это и есть бывшие программисты на C++"? Где можно ознакомиться с соответствующей статистикой?
а почему не foo(y >= 0 ? (unsigned)y : 0) (второй 0 можно заменить на логгирование/исключение/::exit(-146)/whatever)
Ну вообще это далеко не всегда нужно, особенно если ситуация когда y < 0 вполне штатная - просто в этом случае вызывать foo() не нужно вообще. Лично я предпочитаю использовать контекстозависимые линтеры типа сонара, в которых предупреждение можно пометить как "accepted", но при изменении контекста предупреждение будет расценено как "новое" и будет снова отображено. А явные касты тут только мешают.
Проверка не является одним целым с вызовом и при очередном рефакторинге может быть (ошибочно) стёрта.
Конечно! Но вся штука в том, что точно так же она может быть ошибочно стерта и при наличии явного приведения foo((unsigned)y), и компилятор тут вам ничем не поможет.
С точи зрения простого компилятора эта проверка ничего не добавляет.
Это уже другой вопрос. Для надежного отлавливания ошибок конверсии между знаковыми и беззнаковыми типами одного требования явного приведения мало - прописывание этого приведения само по себе ничего не дает, ошибка остается. Если в приведенном мной куске кода завтра один джун пропишет foo((unsigned)y), чтобы заткнуть компилятор, а послезавтра другой джун выкинет if по ошибке, то компилятор ничего не заметит (как и в расте, кстати).
Безопасности тут добавляет проверка if(y < 0), а не явное приведение y к unsigned. Если есть проверка, то явное приведение не добавляет никакой "безопасности". Бездумное приведение же без проверки просто заткнет компилятор, а ошибка останется - как и в расте, кстати.
А тут не на что ругаться, абсолютно ничего "небезопасного" в приведенном мной коде нет. Прописывание явного приведения никакой "безопасности" тут не добавляет.
Ну вообще зависимости обычно собирают отдельно с их родными ключами с использованием одного из пакетных менеджеров (я лично предпочитаю vcpkg), а собственный код - отдельно.
Ну вообще-то флаги, заставляющие компилятор делать соответствующие проверки, существуют - -Wconversion, -Wsign-conversion, и так далее, просто они не включены по умолчанию. А не включены они по умолчанию потому, что существует дофига абсолютно валидного и беспроблемного кода типа такого:
void foo(unsigned x) { ... }
void bar()
{
int y = baz();
if (y < 0) return;
foo(y);
}
Буханка-троллейбус.жпг
Ну как же, вот я например хочу использовать в своем приложении sdl2 (или любую другую библиотеку, написанную на C) через например вот такой враппер. Враппер при наличии только go вы может и соберете, а саму sdl2 кто будет собирать?
Таким образом можно собрать только относительно несложное приложение без зависимостей написанных на других языках. А другие языки были, есть и будут есть, потому что серебряных пуль не существует.
Ну собственно на этом можно и закончить :) Шутка (наполовину). А если серьезно - мы же берем случай не хелловорлда, а серьезного приложения с зависимостями, написанными на разных языках. То есть возвращаемся к началу - для "решения проблемы" (человек хочет попробовать новое приложение) ему нужно поставить go, поставить C/C++ компилятор, возможно, растокомпилятор (для зависимостей)... Боюсь, что с таким подходом у вас не получится значительно расширить пользовательскую аудиторию :)
Это в какой-то степени решено только в языках, которые имеют свой рантайм (типа упоминавшихся вами питона, явы или шарпика), там просто все эти проблемы переложены на рантайм - и опять же, только если у вас нет вызовов каких-то сторонних библиотек через native interface. Говорить же, что эта проблема решена в языке потому что он может статически слинковать бинарь - ну, ИМХО, такое. И опять же, этот статически слинкованный вами бинарь, даже если нет никаких условных плагинов (или вы их не забыли все трудолюбиво найти и добавить в пакет), все равно будет точно так же огребать в винде или макоси от паранойи с подписями, как у вас в статье написано.
Это только в теории так все просто, со сферическим конем в вакууме. На практике же например у используемых вами (возможно, даже не напрямую) библиотек бывают плагины, которые статически просто не линкуются, а подгружаются исключительно динамически (через
dlopen()или подобные механизмы). Более того, на разных системах нужны разные плагины в зависимости от... много чего - например, где-то нужен плагин для Xorg протокола, а где-то для Wayland, версия библиотеки, установленная в системе, об этом в курсе, а то, что вы там статически себе прилинковали - нет. Го вам поможет только в наипростейшем случае хелловорлда, что-то чуть более сложное - и вы будете совершенно так же огребать.Еще раз - я не хочу себе на машине компилятор go (это как минимум, еще раз повторюсь, что если само приложение написано на go, это не значит, что все его зависимости написаны на go) для того чтобы один раз запустить приложение на попробовать. Везде это решается бинарными пакетами, которые я просто скачиваю из некоего стора или хранилища пакетов. Я все еще не понимаю, чем условный go в этом плане лучше чем условный C++. Бинарный пакет есть бинарный пакет, и проблемы его установки никак не зависят от языка на котором он написан.
Еще раз - вот я хочу попробовать ваше приложение на винде. Вы считаете нормальным, что я для того, чтобы его попробовать, должен скачивать себе гошный тулчейн и сидеть собирать что-то там из исходников со всеми зависимостями (у которых могут быть свои тулчейны)? Или я все же должен иметь возможность скачать готовый бинарный пакет и установить его, как это делается обычно в винде, макоси и на большинстве линупсов (за исключением генту)? А если речь идет о бинарном пакете, то причем тут язык, и чем мне тут поможет установка гошного тулчейна (который нужен мне как собаке пятая нога)?
Честно говоря, я не очень понял претензии к языку. Установка неподписанных/ненотаризованных бинарей - это в любом случае проблемное дело в той же винде или в macOS вне зависимости от того, на каком языке написано то, из чего эти бинари собраны. А если вы хотите просто показать потенциальному пользователю свое приложение в режиме "скачать и запустить", то требовать, чтобы этот потенциальный пользователь имел тулчейн для его сборки (а скорее всего еще и тулчейны для сборки всех его зависимостей, ведь они могут быть написаны на разных языках), каким бы распрекрасным и удобным этот тулчейн ни был - ну, такое.
Вообще-то гарантируется: строковые литералы гарантированно имеют static storage duration:
Точно не могу сказать :)
Ну то есть в своих широковещательных заявлениях основываетесь не на какой-то статистике, а на собственных каких-то представлениях "из головы" и собственном опыте. Тогда стоит добавлять к своим заявлениям "ИМХО", а не преподносить их как факт. Не ведите себя как растофанатик, ведите себя как инженер.
Здорово, здорово. Нечем подкрепить свои утверждения - обвини собеседника в сектантстве и демагогических приемах. С вами я на обозримое будущее разговор закончил.
Я вот заметил, что вы очень любите делать широковещательные и ничем не подкрепленные заявления. Откуда дровишки что "почти все программисты на Rust это и есть бывшие программисты на C++"? Где можно ознакомиться с соответствующей статистикой?
Есть механизмы контекстозависимого отключения предупреждений, например.
Ну вообще это далеко не всегда нужно, особенно если ситуация когда
y < 0вполне штатная - просто в этом случае вызыватьfoo()не нужно вообще. Лично я предпочитаю использовать контекстозависимые линтеры типа сонара, в которых предупреждение можно пометить как "accepted", но при изменении контекста предупреждение будет расценено как "новое" и будет снова отображено. А явные касты тут только мешают.Конечно! Но вся штука в том, что точно так же она может быть ошибочно стерта и при наличии явного приведения
foo((unsigned)y), и компилятор тут вам ничем не поможет.Это уже другой вопрос. Для надежного отлавливания ошибок конверсии между знаковыми и беззнаковыми типами одного требования явного приведения мало - прописывание этого приведения само по себе ничего не дает, ошибка остается. Если в приведенном мной куске кода завтра один джун пропишет
foo((unsigned)y), чтобы заткнуть компилятор, а послезавтра другой джун выкинетifпо ошибке, то компилятор ничего не заметит (как и в расте, кстати).Безопасности тут добавляет проверка
if(y < 0), а не явное приведениеyкunsigned. Если есть проверка, то явное приведение не добавляет никакой "безопасности". Бездумное приведение же без проверки просто заткнет компилятор, а ошибка останется - как и в расте, кстати.А тут не на что ругаться, абсолютно ничего "небезопасного" в приведенном мной коде нет. Прописывание явного приведения никакой "безопасности" тут не добавляет.
Ну вообще зависимости обычно собирают отдельно с их родными ключами с использованием одного из пакетных менеджеров (я лично предпочитаю vcpkg), а собственный код - отдельно.
Ну вообще-то флаги, заставляющие компилятор делать соответствующие проверки, существуют -
-Wconversion,-Wsign-conversion, и так далее, просто они не включены по умолчанию. А не включены они по умолчанию потому, что существует дофига абсолютно валидного и беспроблемного кода типа такого:Те, кому надо, могут включить.