Go vs. Swift

Считаю сабж не уместен, потому что сравниваем корову с овцой. Разные языки, для разных вещей. Swift для эко-системы яблочного сада и распостранение вне сада, думаю не будет, а куда засунется golang, мне лично не понятно (хотя, пишу на нем pet-скрипты), вроде пристроился на бэкенде веба.

Тогда в этом не было потребности.

ИМХО, он так и останется в гугловых недрах + немного вылезет наружу. Сильной популярности он не снискает.

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

И да, джава - полет нормальный.

Дельфи очень хорошо взлетели, тогда весь рунет был доками усыпан. Мне даже удивительно

Сколько из них имели некрякнутую дельфю? :)

GC это не всегда плохо. У них и плюсы есть.

Я что-то не помню чтобы у GC были плюсы. Плюсы могут быть в уровне вхождения и скорости разработки для конкретных языков, а вот потребление памяти, паузы на чистку всегда страдают.

Не принципиально. Проблема в алгоритме, а не в компиляторе.

Почему вы говорите обо мне в третьем лице?

Пойнт в том, что Go делают люди, серьёзно считающие, что вот это вот — хороший пример.

В рунете тогда вообще было что-то некрякнутое? )

Так в том-то и дело, что делфи, по-моему, взлете только в СНГ, но тут не платёжеспособная аудитория. А цены у них дай Бог.

Вот тут говорят еще в Бразилии очень популярно https://www.quora.com/How-popular-is-Delphi-programming-language/answer/Chris... Но как я и говорил, оценки не дам, для меня тогда интернет ограничивался рунетом.

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

ну так я и имел в виду скорость разработки.

великодушный диктатор не указывает как форматировать свой код

Это очень плохо. Очень. Как жертва быдлокодеров (покусали) - всячески ратую за строжайшие кары для таких свободолюбцев.

Swift побогаче на синтаксис. Есть generics, например.

Это проблема. Богатые синтаксисы будут затруднять ротацию программистов в проектах. А нужны ли эти generics если в Go без этого можно обойтись?

одни витамины же

Какие-то очень горькие витамины, яблочный жыр.

А нужны ли эти generics если в Go без этого можно обойтись?

С такой логикой нужно продолжать кодить на Сишке.

А нужны ли эти generics если в Go без этого можно обойтись?

Из того, что в Go чего-то нет, не следует, что без этого можно обойтись.

Почему вы говорите обо мне в третьем лице?

А что, все обязаны знать, что это твоя жжшечка, недоумок?

Лично у Томпсона и Пайка узнавал, что и как они считает по поводу приведённого тобой примера?

Из того, что в Go чего-то нет, не следует, что без этого можно обойтись.

Из того, что ты, баран, считаешь, что без чего-то нельзя обойтись, не следует, что без этого нельзя обойтись.

А про веб фреймворки на компилируемых языках - это ад и израиль, все эти перекомпиляции, нахрен нужно.

Можно и на лету. Да и сборка в среднестатистическом проекте это секунды.

Go делают люди, серьёзно считающие, что вот это вот — хороший пример

Это хороший пример, а ты докопался до столба. Но понтанулся математикой на ровном месте, молодец.

А про веб фреймворки на компилируемых языках - это ад и израиль, все эти перекомпиляции, нахрен нужно.

Бэкенд на интерпретируемом языке — это полный дебилизм. Переинтерпретация на каждый запрос, нулевая надёжность — нафиг, нафиг.

Дейкрсты на тебя нет.

Ну и пара мс всё таки довольно много.

Для худшего случая? Там средние задержки — десятки наносекунд. В каком-нибудь файловом менеджере или браузере ты их не заметишь.

malloc/free в худшем случае тоже могут ощутимые задержки вызывать.

Я что-то не помню чтобы у GC были плюсы.

1) Сборщик мусора уплотняет память при копировании из кучи в кучу — уменьшает вероятность кэш промаха

2) Сборщик мусора зачастую умеет копировать связные объекты: списки, деревья. Объект копируется от корня и дальше по узлам в неприрывный участок памяти — уменьшает вероятность кэш промаха при работе с деревьями, списками и другими связными объектами.

3) Сборщик мусора может совершать сборку мусора тогда, когда это удобно: нет запросов, железо простаивает и.т.д., а не при выходе из блока/вызове free.

4) Сборщик мусора может работать в отдельном потоке, то есть избавить основной поток от оверхэда от работы с кучей совсем.

Навскидку. И все это искаробки. Разумеется этого всего можно добиться и на сишке/крестах с помощью переизобретения сборки мусора, кастомных алокаторов и прочих ухищренийизвращений. Но в большинстве случаев оно того не стоит.

5) Сборщик мусора может грохнуть кучу данных одним махом, не тратясь на вызовы free для каждого объекта отдельно.

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

С такой логикой нужно продолжать кодить на Сишке.

Зато есть интерфейсы и ооп-стайл полиморфизм.

Как и Go, Swift имеет децентрализованный менеджер пакетов. Правильно понимаю, что авторы ни одного другого ЯП до такого не додумались, заставляя в 2017 складывать все яйца в одну корзину?

Тебе от этого жарко/холодно? Оттого, где и как лежат пакеты? Нет, только честно, ты собираешь выбирать ЯП не основываясь на том, какие требования выдвигаются к ПО, которое ты собираешься писать, а основываясь на каких-то там деталях? Идиотизм, имхо. ЯП выбирают исходя из нужд программиста в конкретном ПО!

Swift на первый взгляд посвободней: великодушный диктатор не указывает как форматировать свой код.

Хренасе, вот это свобода! Если даже не указывает, как форматировать код (правда, разрабатывать ты можешь только под одну анально огороженную платформу с миллионом ограничений и рамок, но это херня, форматировать - твоя свобода!).

Swift побогаче на синтаксис. Есть generics, например.

Блин, уже не смешно даже, тут 80% LOR'а даже не знает, что такое дженерики, а 50% их никогда не юзали, но вспомнить их это святое? Запахло GO? Ну-ка надо напомнить про дженерики!

Swift использует LLVM и пилит WebAssembly backend, возможно уже можно компилировать. Группа из лицемерной корпорации, работающая над проектом Ванадиум тоже запилила Go frontend для LLVM (если конечно это они запилили, а не просто используют) и судя по слайдам, наверное, можно получить WASM, но не уверен (после 5 часов компиляции необходимого C++ кода, которая всё это время выжирала всю RAM, получил ошибку, решил на этом пока закончить).

Пилит... судя по слайдам... наверное, можно... не уверен... не компилиться...

Это просто праздник какой-то. Пока программисты будут выбирать ЯП на ЛОРе основываясь на сплетнях, мифах и всякой неважное фигне - в жопе они перманентно и останутся.

6) Аллокация в GC может быть быстрее, чем malloc, вплоть то простого бампа указателя.

Мне показалось долгой и неудобной разработка под веб на свифте. Имеет смысл только если сайт совсем примитивный и охота прям из кожи вон вылезти, но кодить на Swift.

С Django / Rails даже не сравнится ещё лет 5.

Пойнт в том, что Go делают люди, серьёзно считающие, что вот это вот — хороший пример.

Я думал, там другой автор. Ну и зачем докапываться до иллюстративных примеров. Они ж не про матан и алгоритмы, они иллюстрируют фичи языка. Большинство иллюстративных примеров, что я видел, были не оптимальны. Ты ж не будешь ругать пример на хаскиле с рекурсивным вычислением числа Фибоначчи, который можно переписать в виде цикла или функции с хвостовой рекурсией?

Пере что? Там же всякие джиты и прочее в Java и Node.JS уже с дремучих времён. Это в php раньше так кодили, сейчас давно уже архитектура веб сервисов другая - есть application server на всяких node.js / python Django/Flask, есть морда к нему на nginx. И nginx все кеширует, вплоть до web <-> application server запросов. Application server (node.js, к примеру, запускается один раз, внутри виртуальной машины node.js происходит JIT компиляция функций в машинный код архитектуры и всё- далее происходит вызов этих участков из оперативы. Т.ч. скорости там примерно 4K - 7K ответов в секунду на минимальном инстансе Linode. Не думаю, что в РФ прям дохрена сайтов, у которых на одну машину приходит 4.000 запросов в секунду. На реальном железе скорости могут быть и до 20 - 50 тыс ответов в секунду на Node.js + Posgresql / Mongo. Зависит от субд, схем и прочих радостей, Django поменьше держит нагрузку.

это полный дебилизм

Увы, но почти весь бекенд именно на «этом».

Увы, без бенчей на реальных задачах не понять.

Можно придумать столько же контрпримеров, но это не отменяет того факта, что большинство прикладного софта с требованиями к отзывчивости (типа браузеров и игры) всё так же пишут на языках без GC.

Некоторые, правда, умудряются пилить инди игры на .net, но получается пока так себе. Там GC грузить то и не чем особо, но озу жрёт как паровоз.

Страдаешь от фрагментации памяти и постоянных задержек free, очевидно же.

Современные аллокаторы памяти, во-превых, делят память на классы по размерам 4, 8, 12, 16, 32... байт, во-вторых, память используется виртуальная, в-третьих, еще есть swap. А теперь приведи пример, когда фрагментация памяти на 64-х битной системе даст дополнительные издержки по сравнению с GC. А также расскажи, как постоянные издержки free дадут большие затраты, чем запуск сборщика мусора.

очевидно же.

Так говорят, когда не разбираются в вопросе, потому что когда действительно очевидно, то и говорить нечего.

Ну и практика показывает, что языки, завязанные на IDE так и не взлетели.

Говорят Java без IDE использовать крайне неудобно (хотя тесной завязки на конкретную IDE и нет, но совсем без нее ничего сложнее HelloWorld никто не пишет).

Они иллюстрируют свои шрифты. Сделанные для этого языка. Это уже, в общем-то, приговор.

Там же всякие джиты

А, то есть, компиляция внезапно стала OK?

А про веб фреймворки на компилируемых языках - это ад и израиль, все эти перекомпиляции, нахрен нужно.

Щас даже фронтэнд компилируют (обфускация, запаковка, всякие LESS, SASS). Да и перед развертыванием приложения его принято тестировать. Так что твое негодование, как минимум, непонятно.

что большинство прикладного софта с требованиями к отзывчивости (типа браузеров и игры) всё так же пишут на языках без GC.

На шарпе давно все пишут. Трейдеры и прочие финансисты вообще на хаскиле с окамлом пишут и хвалят их скорость. Игры — отдельный разговор, да.

Про большинство софта пруф нужен, конечно.

Там GC грузить то и не чем особо, но озу жрёт как паровоз.

И виноват, конечно, GC? А если у меня фуррифокс грузит озу и течет, как школьница в объятьях Лимонова, то кого мне винить? Тоже GC?

GC на быстродействие влияет крайне мало, особенно если он не останавливающий мир, аки в хаскиле, а работает себе в соседнем потоке. А сравнить байткод язык с компилируемым и сделать вывод о GC — это клиника.

Можно придумать столько же контрпримеров

Придумай, заинтриговал.

Ну а чо, libc свою запили, теперь можно и шрифты.

Трейдеры и прочие финансисты вообще на хаскиле с окамлом пишут и хвалят их скорость.

В трейдинге и финансах огромная куча задач, какие-то требуют высокий throughput, какие-то требуют низкий latency. И если для первых Haskell с OCaml-ом (а так же Java или C#) вполне уместен, то вот для вторых GC ну никак. Даже если отдельные умельцы предпочитают делать это на Java, то все равно с ручным управлением памятью.

Они иллюстрируют свои шрифты. Сделанные для этого языка.

Да, отличные шрифты, прям как в plan9. Молодцы, что запилили.

какие-то требуют низкий latency.

Ну тебе виднее, конечно, кому что нужно и уместно.

https://blogs.janestreet.com/building-a-lower-latency-gc/

Хотя пределы есть, конечно. Только что-то мне сдается, что malloc/free при таком-то критичном latency, исключающем любой GC, тоже использовать не будут.

Про большинство софта пруф нужен, конечно.

Там было про прикладное. Это, конечно, слабый аргумент, но у меня на ПК 95% софта на C/C++. Мобилки не в счёт, ибо там нет выбора ЯП.

А если у меня фуррифокс грузит озу

Сравнили махину типа браузера с инди игрой из 2.5 спрайтов.

GC на быстродействие влияет крайне мало

Главное верить. Приложений, которые выполняют одну и ту же задачу, но написанных на разных языках - мало. А все бенчмарки не пользу GC.

Я не говорю, что GC плох, но фанатизм меня не привлекает.

Придумай, заинтриговал.

Для разогрева: детерминированное освобождение ресурсов.

Сравнили махину типа браузера

В чем махина? Разметку отрендерить? Интерпретировать простенький язычок? Почему surf на вэбките у меня на вкладке в два раза меньше жрет памяти? Может дело в рученьках?

А все бенчмарки не пользу GC

Ты приведешь эти бенчмарки, конечно же?

детерминированное освобождение ресурсов.

Я об этом писал выше. Еще что-нибудь?

Ну тебе виднее, конечно, кому что нужно и уместно.

Это даже не вызывает сомнения.

https://blogs.janestreet.com/building-a-lower-latency-gc/

И? Работам в области Real-Time Java уже сто лет в обед. Но ботанам из Jane Street интереснее сделать то же самое, но самим, для OCaml-а. Кстати, до продакшена они хоть это дело довели уже?

Только что-то мне сдается, что malloc/free при таком-то критичном latency, исключающем любой GC, тоже использовать не будут.

malloc/free более предсказуемы, чем GC. Поэтому «обычный GC» перестают использовать гораздо раньше, чем malloc/free.

Кстати, до продакшена они хоть это дело довели уже?

Нет, они используют ванильный гц.

malloc/free более предсказуемы

Лолшто? Критерий предсказуемости в студию. Если ты предсказать время задержки не можешь, то где ж здесь предсказуемость?

1) Сборщик мусора уплотняет память при копировании из кучи в кучу — уменьшает вероятность кэш промаха

Для чтения это дает положительный эффект, для записи отрицательный (если параллельные потоки пишут в два объекта и они лежат в одной строке кеша, то запись будет последовательной).

2) Сборщик мусора зачастую умеет копировать связные объекты: списки, деревья. Объект копируется от корня и дальше по узлам в неприрывный участок памяти — уменьшает вероятность кэш промаха при работе с деревьями, списками и другими связными объектами.

Копирование элементов списка в последовательный участок памяти, наверное, полезно. Но в результате копирование уже закешированные элементы придется считывать из новых участков памяти. Т.е. копирование очень недружественно к кешу. Также следует учесть затраты на само копирование.

3) Сборщик мусора может совершать сборку мусора тогда, когда это удобно: нет запросов, железо простаивает и.т.д., а не при выходе из блока/вызове free.

Это в теории, а на практике перед блоком, где не желателен вызов сборщика мусора его вызывают явно, чтобы не возникло ситуации, что ему потребуется запуск в критическом блоке (например, из-за нехватки памяти).

4) Сборщик мусора может работать в отдельном потоке, то есть избавить основной поток от оверхэда от работы с кучей совсем.

Очень недружелюбный к кешу алгоритм. В текущем потоке, чтобы освободить память, обычно, нужно лишь пометить соответствующий блок, как свободный, при этом многие данные лежат в кеше. Если это делать из другого потока - то сначала нужные участки памяти придется подгрузить (возможно, из чужого кеша, где они так же используются).

В результате получается, что GC работает приемлемо, когда CPU загружен далеко не полностью, но в таком случае затраты на управление памятью вообще не имеют значения, потому что отожрешь ты 3% от неработающего CPU или 10, он все равно простаивает.

Самая большая неприятность в сборщике мусора в том, что для достижения сравнимой скорости работы по сравнению с ручным управлением памятью GC нужно в 4-6 раз больше памяти (https://habrahabr.ru/post/188580/). Кто считает, что память дешева - сравнивайте не стоимость плашки памяти в DNS, а тарифы VPS хостеров, амазона, например. По причине беспредела в отношении к использованию памяти со стороны GC Apple отказались от GC.

5) Сборщик мусора может грохнуть кучу данных одним махом, не тратясь на вызовы free для каждого объекта отдельно.

Только для начала следует детально рассмотреть алгоритм работы GC. И, скорее всего, окажется, что перед этим он обработает каждый кусок памяти по отдельности, в результате сгруппирует свободную память и только после этого ее грохнет одним махом. По времени это будет ничуть не лучше удаления по одному куску через free().

Нет, они используют ванильный гц.

Тогда порасказывайте еще ваших влажных сказок про использовании OCaml-а в low-latency системах.

Лолшто?

Лолто, что в случае с GC вы не знаете, где и когда у вас что произойдет. А с malloc/free все прописывается явно. Отсюда и предсказуемость.