Здравствуйте, Тёмчик, Вы писали:
S>>Пожалуйста, объясните, как вам это удалось? Вероятно, работали в крупных конторах с хорошо налаженными процессами и эффективным менеджментом?
Тё>Я Вам уже в который раз пытаюсь донести, что «знать про визитор» и «знать визитор»- две большие разницы. Примерно как Оля «знает про C++», а Петя «знает C++».
Так вы, очевидно, не знали ни "про визитор", ни "визитор". Объясните, как вам это удалось?
Тё>Но Вы слишком узко-кругозорный, чтобы понять.
Еще раз, какие ваши доказательства? Вот про незнание о визиторе вы сами признались. Тут даже ничего доказывать не нужно. Выпады же в адрес собеседника нужно как-то обосновывать.
Тё>И кстати про C++ с Java- этим список далеко не ограничивается. Только вот на Go ещё не довелось.
Надо полагать, в этом списке почетное место занимает OCaml с Haskell-ем? Ну или хотя бы Scala? Или F#? А может Erlang?
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, chaotic-kotik, Вы писали:
CK>> Из смешного, они тащат в проект только то, что написано на Go, например https://github.com/siddontang/ledisdb вместо Redis и BoltDB вместо LMDB. Судя по всему, основной контингент там состоит из бывших PHP/Ruby/Python/etc программистов.
C0x>Не знаю какую ты группу имеешь ввиду, возможно ту которая относится к курсу Go на Coursera. Я лично там писал что выбрал Го в частности из-за bbolt (аля boltDb).
https://t.me/gogolang
C0x>Можешь смеяться сколько хочешь, а я вот объясню свою логику выбора: хочется не иметь НИКАКИХ внешних зависимостей в проекте! Хочется просто тупа скопировать 2 файла на новую VPS и сервис должен работать дальше, лучше и еще быстрее. Да вот такие у меня требования к момему собственному проекту! Хочу чтобы я тратил на развертываение 2 шага: купил VPS, скопировал файлы и запустил!
никаких внешних зависимостей, при этом куча кода вытягивается с гитхаба и статически линкуется с твоим приложением, но зависимостей никаких нет
а развертывание это всегда только копирование файла
C0x>bbolt выбрал исключительно потому-что это первая ссылка которую выдает Гугл по встроенным базам в Го. По описанию я понял, что меня лично она устраивает. Искал какие-нибудь тесты, не нашел ничего толкового. Решил буду сам тестировать.
boltdb то ладно, хотя и спорно, LMDB — супер стабильная библиотека, используется вообще везде, есть в любом дистрибутиве, в отличие от
как ты объяснишь ledis? это отдельный сервис, не встраиваемая библиотека
PS>> Не нужно всех вокруг и в частности в сообществе Го считать идиотами. У многих есть конкретные требования и они стараются в них вписаться. А уж поверь и на Си и на SQL писать многие там тоже умеют. Я лично считаю признаком идиотизма и низкой квалификации если Сишник будет создавать Вэбсервис на Си, только потому-что он крутой Сишник.
Это похоже другая. Я недавно подписался на курс по Go от МФТИ на курсере. У них там группа относительно самого курса, но периодически разные темы и вопросы всплывают, в частности и про базы.
C0x>>Можешь смеяться сколько хочешь, а я вот объясню свою логику выбора: хочется не иметь НИКАКИХ внешних зависимостей в проекте! Хочется просто тупа скопировать 2 файла на новую VPS и сервис должен работать дальше, лучше и еще быстрее. Да вот такие у меня требования к момему собственному проекту! Хочу чтобы я тратил на развертываение 2 шага: купил VPS, скопировал файлы и запустил!
CK>никаких внешних зависимостей, при этом куча кода вытягивается с гитхаба и статически линкуется с твоим приложением, но зависимостей никаких нет
В том то и дело, что статические зависимости и рантайм зависимости очень разные вещи. Одно дело когда у меня база, кэш и приложение это одно целое (один тупа файл), другое дело когда мне на новой VPS нужно развернуть и настроить сначало базу, потом еще засосать туда схему, а потом только развернуть приложение.
CK>а развертывание это всегда только копирование файла
Да ладно? Ну вот в частности развертывание скажем веб сервиса написанного не на Го или сях, это: 1. Развернуть Базу, 2. Развернуть кэш, 3. Развернуть NGinx и еще развернуть сам скриптовый интерпритатор, а только потом скопировать сами файлы. Теперь сравни это с копированием 1-2 файлов на чистую VPS.
CK>boltdb то ладно, хотя и спорно
Если есть какая либо инфа по boltdb, особенно почему спорно, то буду рад узнать, т.к. инфы толком пока мало, кроме своих тестов.
LMDB — супер стабильная библиотека, используется вообще везде, есть в любом дистрибутиве, в отличие от CK>как ты объяснишь ledis? это отдельный сервис, не встраиваемая библиотека
Я хз если честно, ни с тем ни с другим дело не имел.
Здравствуйте, chaotic-kotik, Вы писали:
CK>никаких внешних зависимостей, при этом куча кода вытягивается с гитхаба и статически линкуется
И при этом все это я делаю на своей рабочей Windows станции в удобном для себя среде, а в итоге получаю 1 файл для Linux системы, который осталось скопировать через ssh и запустить.
Здравствуйте, Cyberax, Вы писали:
C>>>Это как бы немало. EP>>Если у нас таки "реалистичный размер в 64Кб", то в варианте на Go сколько будет? C>Столько, сколько нужно.
Если это действительно так, тогда получаем квадратичную сложность
Здравствуйте, Cyberax, Вы писали:
C>2) Сегментированные стеки. Компилятор вставляет в пролог и эпилог функции (или в место вызова) код,
Специальный эпилог в код функции не вставляется. На unhappy path вставляется специальный адрес возврата в стек, на который переходит ret.
C>который может передвигать указатель стека между сегментами (в виде связного списка). Это тормозит из-за того, что эта проверка — дополнительное и дорогое ветвление, с косвенным доступом. В Golang от этого отказались примерно 5 лет назад из-за тормозов.
В Go будет точно такая же проверка в прологе и ветвление
Здравствуйте, m2l, Вы писали:
EP>>Планировщик, каналы и прочая обвязка есть в Boost.Fiber. EP>>То есть в Boost есть три библиотеки на тему stackful, начиная от низкого к более высокому уровню: Boost.Context, Boost.Coroutine, Boost.Fiber. m2l>С тем же успехом все это достижимо и на чистом С, без плюсов
Непонятно при чём здесь C
Корутины много где реализуемы, да и вообще появились раньше C. А например Erlang с зелёными процессами — раньше Go. И?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Непонятно при чём здесь C
К тому, что "много где реализуемы".... EP>Корутины много где реализуемы, да и вообще появились раньше C. А например Erlang с зелёными процессами — раньше Go. И?
Наличие в С++ библиотек, дающих корутины не приближает его к удобству и простоте многопоточного программирования на Golang.
И да, Ernalg конечно крут, но уж больно специфический даже для функциональных языков...
Здравствуйте, Sharov, Вы писали:
S>А чем реализация в голанг на том же С будет лучше реализации на С для С?
1. Синтаксическим сахаром языка. К этому относится и неявный вызов планировщика.
2. GC позволяющим играться с памятью стеков и каналов.
3. Для golang это часть языка/стандартной библиотеки. Уже сделанная и работающая на всех платформах где работает язык.
И да, если задаться целью и затачиваться под конкретную задачу, С как более низкоуровневый инструмент даёт больше возможностей для оптимизации.
Здравствуйте, chaotic-kotik, Вы писали:
C>>1) Возможность полной независимости от libc. CK>это скорее минус, что будешь делать если ABI linux изменится?
ABI в Линуксе отлит в граните. Линус ругается матом на тех, кто его ломает.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Побуду адвокатом дьявола (не имею ничего против Go). Недавно зашел в группу по golang в telegram. Вы бы почитали их обсуждения. Это какое-то днище. Люди не знают даже стандартной библиотеки Go нормально, у большинства очень узкий кругозор и какие-то очень странные представления об окружающем мире. Из смешного, они тащат в проект только то, что написано на Go, например https://github.com/siddontang/ledisdb вместо Redis и BoltDB вместо LMDB.
Я тоже использую Bolt вместо SQLite или чего-то подобного. Просто из-за того, что оно позволяет всё построить статически без всяких внешних зависимостей. При появлении C-кода начинаются сразу проблемы, если на целевом узле нет нужных библиотек (наприме).
Здравствуйте, chaotic-kotik, Вы писали:
CK>никаких внешних зависимостей, при этом куча кода вытягивается с гитхаба и статически линкуется с твоим приложением, но зависимостей никаких нет
Можно поднять своё зеркало зависимостей. У нас такое есть, так что локальные чистые билды строятся без всякого Интернета.
CK>а развертывание это всегда только копирование файла
Нет, если у софта есть зависимость от С-кода, то часто нужно будет обеспечить, чтобы были установлены нужные пакеты. А они все по-разному в разных ОС устанавливаются. И с собой сложно их просто запаковать из-за вечных проблем с версиями glibc.
Здравствуйте, Cyberax, Вы писали:
C>Я тоже использую Bolt вместо SQLite или чего-то подобного. Просто из-за того, что оно позволяет всё построить статически без всяких внешних зависимостей. При появлении C-кода начинаются сразу проблемы, если на целевом узле нет нужных библиотек (наприме).
О, может ты знаешь. У меня тоже BoltDB, но по ряду причин мне нужно её хранить исключительно в памяти (доиск RO в ряде случаев, чтоб его). Я что-то полистал документацию и такая простейшая фича присутствующая в SQlite отсутствует в Bolt. Есть какой-то простой способ добиться нужного эффекта?
Здравствуйте, kaa.python, Вы писали:
KP>О, может ты знаешь. У меня тоже BoltDB, но по ряду причин мне нужно её хранить исключительно в памяти (доиск RO в ряде случаев, чтоб его). Я что-то полистал документацию и такая простейшая фича присутствующая в SQlite отсутствует в Bolt. Есть какой-то простой способ добиться нужного эффекта?
Без патча — никак. Если запатчить, то очень просто на Линуксе.
Здравствуйте, Cyberax, Вы писали:
C>Хотя более правильно добавить в bbolt работу с данными в памяти напрямую.
Мне нужно кроссплатформенное решение. Сейчас думаю то-ли на SQlite мигрировать (выглядит более разумно, так как реляционная база данных больше подходит под задачу), либо браться за переделку Bolt-а.
Здравствуйте, kaa.python, Вы писали:
C>>Хотя более правильно добавить в bbolt работу с данными в памяти напрямую. KP>Мне нужно кроссплатформенное решение. Сейчас думаю то-ли на SQlite мигрировать (выглядит более разумно, так как реляционная база данных больше подходит под задачу), либо браться за переделку Bolt-а.
По идее, запатчить bbolt должно быть несложно и поможет другим.
Здравствуйте, Cyberax, Вы писали:
C>ABI в Линуксе отлит в граните. Линус ругается матом на тех, кто его ломает.
Линус уже не ругается матом, да и ABI никогда не был отлит в граните. Он иногда меняется. Обычно добавляется количество аргументов в системных вызовах. С точки зрения LSB это additive change, все ОК. Обратная совместимость при этом достигается за счет libC (для этого и нужно ее версионирование).
