А если изменишь, то не страшно.

да разве

а вот я по значению слайс передал

Мутабельное расшареное состояние - главный источник сложности ПО. Именно поэтому ООП - полное дерьмо, в нём shared mutable state достигает своего апогея. Хотя в го это не актуально, ибо всё состояние приложения хранится (почти) всегда в базе.

Что ты несёшь...

или структуру с указателем внутри

Что ты несёшь...

ну - он не сам, он отцов цитирует

а вот Pawel пришёл, как я и предвидел

и это правда, вообще-то

Что ты несёшь...

Этот вопрос мне хочется задать тебе в ответ на каждое твое сообщение.

и это правда, вообще-то

вернее - правда про источник и вранье про go

Только там конст должен быть модификатором указателя. В любом случае данные переданные не по указателю ты не изменишь.

какие недостатки повлечёт за собой рассмотрение const *Object как иммутабельный указатель на иммутабельный объект?

никаких

Мутабельное расшареное состояние - главный источник сложности ПО. Именно поэтому ООП - полное дерьмо, в нём shared mutable state достигает своего апогея. Хотя в го это не актуально, ибо всё состояние приложения хранится (почти) всегда в базе.

всё состояние хранится в базе?! щито? Go это general purpose language а не SQL

коллеги, ну нет необходимости на кажлую провокацию вестись

вернее - правда про источник и вранье про go

И про ООП враньё

коллеги, ну нет необходимости на кажлую провокацию вестись

согласен

а вот насчет ООП это правда. хер ведь усвоишь, в какое состояние приходит твой объект при вызове метода, и в каком состоянии он находился перед ним. идея была в том, что нам и не надо будет это усваивать. но - не выстрелило

никаких

хммм, чёт я как бывалый C++'щик не совсем уверен

Ну как бы это вполне классический бэк, когда бОльшая часть общих данных лежит в базе и вся забота по синхронизации ложиться на СУБД и транзакции

вернее - высрелило и в цель, и в ногу

хммм, чёт я как бывалый C++'щик не совсем уверен

из плюсов в го, чего так?)

а вот насчет ООП это правда. хер ведь усвоишь, в какое состояние приходит твой объект при вызове метода, и в каком состоянии он находился перед ним. идея была в том, что нам и не надо будет это усваивать. но - не выстрелило

собственно - const methods

из плюсов в го, чего так?)

попиши web API на C++, поймёшь

?

кому нибудь приходит в голову в каких ситуациях может быть полезным хранение иммутабельного указателя на мутабельный объект?

кому нибудь приходит в голову в каких ситуациях может быть полезным хранение иммутабельного указателя на мутабельный объект?

Мне приходят в голову примеры с векторами, деревьями, графами и прочими структурами, которые полностью заменять не надо, но надо изменять в процессе.

Но векторов в го нет, ибо они не ложатся на гошную модель работы с памятью.

С графами и деревьями думаю то же самое.

1. immut * to mut Object: const * Object 2. mut * to immut Object: * const Object 3. immut * to immut Object: const * const Object честно говоря не хочется в Go внедрять подобные конструкции

Но векторов в го нет, ибо они не ложатся на гошную модель работы с памятью.

И тут я вспоминаю почему GC в принципе плохо ложится на императивное программирование.

func C1(o const *Object) { o.Mutate() o = nil // Compile-time error } func C2(o *const Object) { o.Mutate() // Compile-time error o = nil } func C3(o const *const Object) { o.Mutate() // Compile-time error o = nil // Compile-time error }

короче я пока-что опишу это с 3 вариациями, но помечу как спорный момент и над ним ещё предспоит вывести решение

из плюсов в го, чего так?)

И правда - чего? Конпиляет полчаса, сообщения об ошибках конпиляции на 10к экранов, сверх сложный, сверх запутанный... самое оно

И правда - чего? Конпиляет полчаса, сообщения об ошибках конпиляции на 10к экранов, сверх сложный, сверх запутанный... самое оно

просто нужно знать

И правда - чего? Конпиляет полчаса, сообщения об ошибках конпиляции на 10к экранов, сверх сложный, сверх запутанный... самое оно

За 10к экранов сообщений об ошибках скажите спасибо утиной типизации в шаблонах

И правда - чего? Конпиляет полчаса, сообщения об ошибках конпиляции на 10к экранов, сверх сложный, сверх запутанный... самое оно

Полчаса? Хром на хорошем железе компилируется часа 4-5

просто нужно знать

Нужно терпеть и каяться

просто нужно знать

Просто нужно уходить в руст.

Полчаса? Хром на хорошем железе компилируется часа 4-5

Смотрел интервью с разработчиком Хрома, он говорил что компилится 45 минут где то

Полчаса? Хром на хорошем железе компилируется часа 4-5

Круд сервис примитивный с бустом и спиритом

Полчаса? Хром на хорошем железе компилируется часа 4-5

Есть же всякие рекомендации по ускорению сборки C++

Смотрел интервью с разработчиком Хрома, он говорил что компилится 45 минут где то

На 24 ядерном северном процессоре со уберскоростными оперативкой и ссд? Может быть, но все равно с трудом верится.

На 24 ядерном северном процессоре со уберскоростными оперативкой и ссд? Может быть, но все равно с трудом верится.

на рабочей машине

Есть же всякие рекомендации по ускорению сборки C++

Только одна - похоронить эту ересь

На 24 ядерном северном процессоре со уберскоростными оперативкой и ссд? Может быть, но все равно с трудом верится.

Собирал на ноуте, за час где-то собрал без проблем

На 24 ядерном северном процессоре со уберскоростными оперативкой и ссд? Может быть, но все равно с трудом верится.

Может он на шланге конпилит

Есть же всякие рекомендации по ускорению сборки C++

а ещё есть Go))

Может он на шланге конпилит

А, точно, хром же недавно полностью на шланг переехал

а ещё есть Go))

И их задачи почти не пересекаются.

а ещё есть Go))

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html

И их задачи почти не пересекаются.

на C++ можно написать почти всё, но стоит ли..

что важнее, долгая компиляция иль быстрая работа

что важнее, долгая компиляция иль быстрая работа

компромис

недолгая компиляция и достаточно быстрая работа ?

что важнее, долгая компиляция иль быстрая работа

Ей богу, вы как будето с асемблер с руби сравниваете

на C++ можно написать почти всё, но стоит ли..

Есть задачи где варианта другого просто нет. А ещё есть задачи, где единственная альтернатива -- Rust. Те, кто бы мог переползти на го давно уже переползли.

недолгая компиляция и достаточно быстрая работа ?

Чо по симд? ?

Нашли где смотреть

Нашли где смотреть

сорцы там есть можешь на своем железе потестить, посмотрим у тебя)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html

У го regex всегда было слабым местом

cpu он конечн кушает нормально

C++ не заменим

Из вашей же ссылки

ERROR: S client not available

хех

Я к тому что разница может быть не настолько большой

Я к тому что разница может быть не настолько большой

Там же АЖ в ДВА РАЗА!

Ну и учитывая что речь изначально завелась про вебапликейшины, эти бенчи тут вообще не всрались

C++ не заменим

Не правда

Пока не заменим

Пока не заменим

пока это еще лет 20 будет

пока это еще лет 20 будет

Пока не накопится критическая масса легаси связанная с цисками?

И не станет понятно, что пора весь C/C++ код выкидывать?

весь тот, что я видел, включая тот, что я сам написал - пора

То есть да, цпп незаменим, но лучше бы его заменить как можно раньше.

blender 3d, например, на C++ написан, тоже выкидывать? или переписывать?

выкидывать, переписывать на нормальном языке

скорее что-то новое эволюционно его заменит, уже написаное на расте

правда, такого еще нет

Ну и учитывая что речь изначально завелась про вебапликейшины, эти бенчи тут вообще не всрались

ну окей для апишечек веб аппок go топ

но

выкидывать, переписывать на нормальном языке

Посоветуйте нормальный язык

скорее что-то новое эволюционно его заменит, уже написаное на расте

я тут поговорил с людьми, пытавшимися втащит раст в прод. говорят - падает, и стектрейс неинформативен

Такие штуки правильно написаны на C++ https://github.com/facebookincubator/katran https://github.com/pavel-odintsov/fastnetmon

я тут поговорил с людьми, пытавшимися втащит раст в прод. говорят - падает, и стектрейс неинформативен

надо unwrap() обрабатывать. стектрейсы правда неинформативны. но известно же где падает

Посоветуйте нормальный язык

Ява же. Ну не язык конечно, платформа и экосистема

Посоветуйте нормальный язык

нету. вернее - говорят, что swift и kotlin. но я не пишу ни на одном из них, и они, все же, очень нишевые. субд на них писать не станешь...

blender 3d, например, на C++ написан, тоже выкидывать? или переписывать?

Вы ничего не поняли. Я о том, что C/C++ очень зависит от архитектуры и вынуждают разработчиков процессоров поддерживать костыли в камнях, а разработчиков компилятора проделывать титаническую работу по написанию оптимизаций C/C++ кода основанных на эвристиках.

нету. вернее - говорят, что swift и kotlin. но я не пишу ни на одном из них, и они, все же, очень нишевые. субд на них писать не станешь...

Знал я одну Scala. И вот где она щас?

надо unwrap() обрабатывать. стектрейсы правда неинформативны. но известно же где падает

началось...

Не знаю почему "одну". Как слышу так и пишу

Однажды индустрии придется осознать, что с цисками пути вперёд уже нет, пора переходить на риски. И в этот момент весь "низкоуровневый" цпп код окажется негодным для употребления новыми процессорами.

Знал я одну Scala. И вот где она щас?

в production

Ява же. Ну не язык конечно, платформа и экосистема

А как же тредики архитектурно заложенные?

Однажды индустрии придется осознать, что с цисками пути вперёд уже нет, пора переходить на риски. И в этот момент весь "низкоуровневый" цпп код окажется негодным для употребления новыми процессорами.

"низкоуровневый" в смысле ассемблерные вставки?

да не очень-то она в продакшн