LINUX.ORG.RU

Go vs. Swift

 , , ,


0

6

На ЛОРе поклонников Go - хоть ж..ой жуй (через одного). А вот о Swift'е, насколько заметил, отзываются не сильно положительно. Есть пользователи последнего? Чем примечателен? Говорят, на Go похож?

Быстрой уткаУткаХодьбой выяснил, что:

  • Как и Go, Swift имеет децентрализованный менеджер пакетов. Правильно понимаю, что авторы ни одного другого ЯП до такого не додумались, заставляя в 2017 складывать все яйца в одну корзину?
  • У разработчиков Swift не так выражен NIH, заставляющий Go Core Team всё писать самостоятельно и с нуля. Поэтому, имеется, например, несколько реализаций сервера (в Go есть стандартный и неправильный).
  • Swift на первый взгляд посвободней: великодушный диктатор не указывает как форматировать свой код. По соответствующему запросу находится Styleguide каких-то хренов с горы и Github'а, который сильно походит на Styleguide Go.
  • Swift побогаче на синтаксис. Есть generics, например.
  • Swift использует LLVM и пилит WebAssembly backend, возможно уже можно компилировать. Группа из лицемерной корпорации, работающая над проектом Ванадиум тоже запилила Go frontend для LLVM (если конечно это они запилили, а не просто используют) и судя по слайдам, наверное, можно получить WASM, но не уверен (после 5 часов компиляции необходимого C++ кода, которая всё это время выжирала всю RAM, получил ошибку, решил на этом пока закончить).

Что плохого в Swift, о чём я не знаю? На первый взгляд одни витамины же. Ну кроме пафоса какого-то клоуна, который его презентует?

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

imbaaa
()
Ответ на: комментарий от imbaaa

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

zamazan4ik ★★
()
Ответ на: комментарий от RazrFalcon

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

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

foror ★★★★★
()
Ответ на: комментарий от foror

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

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от zamazan4ik

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

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

xpahos ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

Miguel ★★★★★
()
Ответ на: комментарий от Freyr69

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

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

Miguel ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

foror ★★★★★
()
Ответ на: комментарий от foror

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

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

foror ★★★★★
()

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

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

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

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

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

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

outtaspace ★★★
()
Ответ на: комментарий от outtaspace

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

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

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

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

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

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

anonymous
()
Ответ на: комментарий от Miguel

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

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

anonymous
()
Ответ на: комментарий от menangen

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

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

ritsufag ★★★★★
()
Ответ на: комментарий от Miguel

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

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

anonymous
()
Ответ на: комментарий от menangen

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

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

Miguel ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

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

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

Freyr69 ★★★
()
Ответ на: комментарий от xpahos

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

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

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

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

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

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

Freyr69 ★★★
()
Ответ на: комментарий от Freyr69

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

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

Miguel ★★★★★
()
Последнее исправление: Miguel (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

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

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

Freyr69 ★★★
()

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

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

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

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

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

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

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

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

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

Alve ★★★★★
()
Ответ на: комментарий от ritsufag

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

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

menangen ★★★★★
()
Ответ на: комментарий от Miguel

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

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

Freyr69 ★★★
()
Ответ на: комментарий от Miguel

Пере что? Там же всякие джиты и прочее в 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 поменьше держит нагрузку.

menangen ★★★★★
()
Ответ на: комментарий от Miguel

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

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от Freyr69

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

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от Freyr69

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

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

очевидно же.

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

anonymous
()
Ответ на: комментарий от RazrFalcon

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

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

anonymous
()
Ответ на: комментарий от menangen

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

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

Miguel ★★★★★
()
Ответ на: комментарий от menangen

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

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

anonymous
()
Ответ на: комментарий от RazrFalcon

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

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

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

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

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

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

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

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

Freyr69 ★★★
()
Ответ на: комментарий от Freyr69

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

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

eao197 ★★★★★
()
Ответ на: комментарий от Miguel

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

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

Freyr69 ★★★
()
Ответ на: комментарий от eao197

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

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

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

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

Freyr69 ★★★
()
Последнее исправление: Freyr69 (всего исправлений: 2)
Ответ на: комментарий от Freyr69

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

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

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

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

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

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

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

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

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

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

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

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

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

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

Freyr69 ★★★
()
Ответ на: комментарий от Freyr69

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

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

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.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

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

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

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

Freyr69 ★★★
()
Ответ на: комментарий от Freyr69

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от Miguel

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

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

anonymous
()
Ответ на: комментарий от Freyr69

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

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

Лолшто?

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

eao197 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.