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, о чём я не знаю? На первый взгляд одни витамины же. Ну кроме пафоса какого-то клоуна, который его презентует?

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

Если у вас из этой статьи в голове останется что-то одно, пусть это будет этот слайд. Ось Y — это время, потраченное на сборку мусора. Ось X — это «относительный расход памяти». Относительный к чему? К минимальному требуемому размеру памяти.

Вот то, что этот слайд нам хочет сказать: «Пока у тебя в 6 раз больше памяти, чем нужно на самом деле, ты — в шоколаде. Но горе тебе, если опустишься ниже 4 размеров требуемой памяти». Необязательно верить мне на слово:

На основе статьи 2005 года? Серьезно?

Ну это все-таки от языка зависит, не могу прочитать тот документ, потому не знаю, что там сравнивают и как, но сдается мне, что для языков с иммутабельными объектами, для языков с возможностью аллокации на стэке результаты будут отличаться.

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

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

А может и не быть. Почитай уже про алгоритм работы tcmalloc или jemalloc. Не нужно сравнивать перспективные GC, существующие только в научных статьях и менеджер памяти Windows XP или RedHat 3.0. Сравнивать имеет смысл на реальных приложениях и тут GC далеко не впереди планеты всей.

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

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

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

Так он и используется что в Jane Street, что в мираже.

А вообще вру, low latency gc уже год как смерджили.

где и когда у вас что произойдет. А с malloc/free все прописывается явно.

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

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

Так он и используется что в Jane Street, что в мираже.

Еще раз: в трейдинге много разных задач. Вы уверены, что на OCaml-е там именно low-latency системы написаны? А не какой-нибудь batch processing? Или какие-нибудь генераторы C-шного кода?

Тебе легче от того, что ты явно вызываешь функцию с недетерминированным временем исполнения?

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

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

На основе статьи 2005 года? Серьезно?

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

Кстати, совсем недавно читал на хабре статью от разработчиков mail.ru (кажется). Там они рассказывали про разные сборщики мусора и заодно про новый модный сборщик с минимальными задержками, появившийся в Go. Так вот от вовсе даже не на поколениях основан, а реализован по алгоритму Дейксты, кажется, из 70-х годов.

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

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

Ты какую-то чепуху несешь. Кэшмисс - 8 циклов на хасвеле. Переместить кусок хипа даже не знаю сколько стоит. Ну явно не 8 циклов, запись в память занимает уже десятки наносекунд. А там у тебя еще столы полезут в пайплайне. Что-то мне не кажется что переместить хип хорошее решение. Лучше уж резервировать под структуру адресное пространство.

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

В большинстве случаев если ты пишешь CRM или ну сайтик, например, корпоративный. Большинство случаев бывает разное и то что я видел было на Java и работало с offheap структурами.

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

Разметку отрендерить? Интерпретировать простенький язычок?

У вас очень странное представление о вебе...

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

Берите любой из гугла.

Еще что-нибудь?

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

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

Вы уверены, что на OCaml-е там именно low-latency системы написаны?

Да. Я туда как-то раз пытался устроиться, так что немного поизучал, чем они там занимаются, послушал их доклады.

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

Ну и где ссылки на эти доклады?

На Java, например, активно low-latency системы пилят, но там программистам приходится всем вручную управлять, так что GC остается не у дел.

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

Что-то вы спорите на пустом месте. Разве не понятно, что GC vs ручное управление vs подсчёт ссылок - это всегда компромисс. А точнее:

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

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

Ручное выделение памяти - когда программа не сложная, либо когда человеческие ресурсы не ограничены и стоят того, чтобы жёстко экономить память и работу CPU, минимизировать задержки на выделение памяти под структуры (игровые сервера, котировки, UDP сервисы). Особенно, когда это происходит не часто и в исключительно алгоритмических задачах, либо на жутко слабом CPU и очень медленной памяти.

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

Что-то вы спорите на пустом месте.

Мне не показалось, что на пустом. Тут какая-то явная упоротость, мол, за пределами GC жизни нет.

GC используется, когда...
Подсчёт ссылок - когда...
Ручное выделение памяти - когда...

Забавная классификация :)

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

Golang это С без Юникса то есть очень простой(с нарушениями алгол-дисциплины)язык близкий машине своего времени.

так как докер как килерапп совсем не тоже самое что юникс как килерапп то и не так заметен golang - всёж гугля не такая монополия как атт

----------------------- с иной точки зрений golang ща как C(1971/*ибо B(NB)* как С 0.1/+(2017-2009) т.к. как С 1979 года - известен среди евангелистов, в индустрии ещё тока апробировался (ибо пекут Аду и прочих гигантов средьмаша).

по свифту - это ещё больший вендорлокин - ибо objC оказался излишне богат для простого софтостроения

у голэнга одна из(раних) фишек готовность быть на баребон

а у свифта вроде как только @всё что делает производитель IПродукта есть годнота@

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

дык языком давно дело не ограничевается в dev-среде.

Golang - сделан удобным для автогенерации и замены(когда нибуть) кусков кода написанных наёмным прогером на код перегенирированный программой по генерации и модификации сырцов

оттого и в опциях есть автоконвертатор от старых версий языка в текущую.

крч. явный недостаток голэнга это открытое восприятие(мэнеджером) писателя на нём как легкозаменимый ресурс

т.е. в этом и только в этом авторы голэнга смогли превзойти авторов Дуба

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

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

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

В какой-то момент времени, так закроемся уровнями абстракций, что и не вспомним, что такое память и как с ней работать.

Это вы про GC?

но я думаю чем проще будет код, тем лучше

С каких пор лапша из if err != nil стала признаком простоты?

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

Спагетти-код — плохо спроектированная, слабо структурированная, запутанная и трудная для понимания программа, особенно содержащая много операторов GOTO (особенно переходов назад), исключений и других конструкций, ухудшающих структурированность.

https://ru.wikipedia.org/wiki/Спагетти-код

В каком месте это «лапша»? Возможно, ты имел ввиду «простыня»? Коль так, в чём сложность этой конструкции для тебя?

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

Нашли к чему придраться...

Сложности никакой, но писать Простыню на каждую обработку ошибок - тупо. Для этого есть исключения, макросы и прочие ништяки, которых нет в Go.

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

ОК, пусть так. Покажи мне этот более лучший ЯП, годный на замену Python / Ruby, но со статической типизацией, компилируемый в нативный код, с поддержкой различных платформ (от Windows и Linux, до Android и iOS, в перспективе WebAssembly), и не сильно маргинальный, чтобы на нём существовали вакансии. А то я всё ищу такой, чтобы спрыгнуть с Go, а ты походу знаешь, но скрываешь это.

MadDeer ()
Ответ на: комментарий от RazrFalcon
  • Rust ближе к C++, нежели к Python.
  • Далеко не эталон изящности, закрученный и чрезмерно перегруженный синтаксис. «if err != nil» и ":=" vs. «var» в Go просто верх красоты на его фоне. Например: https://withoutboats.github.io/blog/rust/2017/01/04/the-rust-module-system-is...
  • Декларируется открытость процесса разработки, а на деле с ней намного хуже, чем в Swift и даже Go. В последних перед запиливанием фичи готовится подробнейший документ, ведётся его обсуждение (см. package manager proposal в Swift, например). В Rust стандартный пакетный менеджер запилили на 4м сообщении со словами «готово, назвал его Cargo, почему не скажу, просто мне так нравится».
  • «Cargo.toml» - ублюдочное название и такой же формат. Единственный файл в проекте, начинающийся с верхнего регистра и при этом имеющий расширение. Тысячи людей передёрнуло от этого, может хотя бы «cargo.toml» для последовательности - спросили они или оба варианта сразу, «мне и так нравится», - ответил разработчик Mozilla, идите все по известному адресу.
  • На сайте, в разделе компаний, использующих Rust - несколько скамов. Если МММ Мавроди начнёт писать на нём, тоже ссылку на его проект опубликуют? Это характеризует «популярность» ЯП.
  • Не сильно богатая стандартная библиотека.
  • Нефеншуйное название. Они бы его ещё гноем или гнилью назвали.
  • У Rust и Go, по большей части, разные use case'ы.
anonymous ()
Ответ на: комментарий от anonymous

Rust ближе к C++, нежели к Python.

Я с этим и не спорил. Да и Go с Python тоже не родня. Какая связь между скриптовым языком с исключениями, кучей ништяков и сахара и паскалем с грин-тредами?

Далеко не эталон изящности

Вкусовщина, дальше.

Декларируется открытость процесса разработки

Всё там в порядке. Язык развивают через RFC. Cargo, не являющийся частью языка, вообще отдельный фрукт.

«Cargo.toml» - ублюдочное название и такой же формат.

Ваша аргументация не перестаёт пробивать дно.

Тысячи людей передёрнуло от этого

Ссылку на статистику в студию? Или вы посчитали все голоса в своей голове?

несколько скамов

Ну так пожалуйтесь - может удалят.

Не сильно богатая стандартная библиотека.

Критерии «богатости» в студию.

Нефеншуйное название.

Ваша аргументация не перестаёт пробивать дно. x2

У Rust и Go, по большей части, разные use case'ы.

Ну хоть какой-то проблеск здравого смысла.

В общем и целом: обычные претензии вида «мне не нравится - значит гавно».

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

С каких ... в Go стала признаком простоты?
Вкусовщина
«мне не нравится - значит гавно»

Вот ты и поговорил с собой.

Ссылку на статистику в студию?

Гугли.

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

Простыню на каждую обработку ошибок - тупо.

Для этого есть исключения

Писать простыню на обработку ошибки — не норм, а писать простыню на обработку исключения — норм?

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

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

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

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

robotron5 ()