Здравствуйте, Cyberax, Вы писали:
C>>>Очень легко получить циклические ссылки. S>>В каналах? Каким образом? C>В коде, который их использует.
Каким боком это должно подтверждать выдвинутый ранее тезис: "Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC." ?
Здравствуйте, C0x, Вы писали:
C0x>>>libc так плоха? C>>Да. C0x>Чем?
Если быть точным, glibc плоха. Если скомпилировать обычное приложение на машине с Ubuntu 18.04, то оно не запустится на Ubuntu 16.04 из-за того, что символы в glibc версированы. Сейчас есть musl libc и Alpine, на которых тоже можно собрать статические С++ приложения, но это требует немалых прыжков и ужимок.
С Golang можно тупо скопировать один файл приложения и оно запустится.
Вдобавок, кросс-компиляция выглядит вот так: "GOOS=linux go build ...". Первыми у нас это заценили инженеры — можно написать и отладить код симуляции локально на MacBook, сделать бинарик и одной командой зафигачить на кластер на реальных данных.
Здравствуйте, so5team, Вы писали:
C>>В коде, который их использует. S>Каким боком это должно подтверждать выдвинутый ранее тезис: "Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC." ?
Нужно было написать: "Хотя код, активно использующий каналы иногда бывает сложно писать без GC".
Здравствуйте, Cyberax, Вы писали:
S>>Каким боком это должно подтверждать выдвинутый ранее тезис: "Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC." ? C>Нужно было написать: "Хотя код, активно использующий каналы иногда бывает сложно писать без GC".
С таким же успехом можно было написать и "Хотя код, активно использующий динамическую память, иногда бывает сложно писать без GC".
К CSP-шным каналам отсутствие/наличие GC имеет очень косвенное отношение.
Здравствуйте, Cyberax, Вы писали:
C>С Golang можно тупо скопировать один файл приложения и оно запустится.
C>Вдобавок, кросс-компиляция выглядит вот так: "GOOS=linux go build ...". Первыми у нас это заценили инженеры — можно написать и отладить код симуляции локально на MacBook, сделать бинарик и одной командой зафигачить на кластер на реальных данных.
Кстати именно из за этого я и выбрал Го для своего проекта. Работаю на Винде, а собираю под линухи и копирую по фтп.
SK>>Все равно не понятно. Без проблем можно кучу коннектов в одном потоке рулить. Как не крути потоки только лейтенси добавляют. H>Добавляют только в том случае, если потоков больше физических ядер.
Вот и вопрос — нафига? Зачем иметь больше потоков, чем физических ядер?
H>Но это пока 384 ядра, года через 3-4 будет и 1024 физических ядер в рамках одного сервера.
Это совсем не противоречит тому, что я говорю. Я говорю, что потоков больше чем ядер быть не должно. Я не не говорил, что их должно быть меньше.
Если система проектирутеся так, что потоков больше, чем ядер, это всегда подразумевает как минимум переключение контекста и как максимум синхронизацию. И то и то — зло.
H>А мы к этому уже готовы сейчас, вот дайте такое железо-я это все эффективно, без переделки кода (чуть конфиги только крутану)-освою на все 100%. H>Тема холиварная и все такое, поэтому дальше спорить не вижу смысла, но я уже сейчас готов к росту количества ядер в CPU в будущих серверах, все утилизирую начисто
Да нет, тут дело не в холиваре совсем. Честно я просто что-то не понию, вот и пытаюсь узнать. Может научусь чему-нить.
Здравствуйте, Cyberax, Вы писали:
C>С Golang можно тупо скопировать один файл приложения и оно запустится. C>Вдобавок, кросс-компиляция выглядит вот так: "GOOS=linux go build ...". Первыми у нас это заценили инженеры — можно написать и отладить код симуляции локально на MacBook, сделать бинарик и одной командой зафигачить на кластер на реальных данных.
+1
И с внешними зависимостями здорово — тупо скопировал gohome и всё. Никаких развлечений с разными окружениями.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Планировщик, каналы и прочая обвязка есть в Boost.Fiber. EP>То есть в Boost есть три библиотеки на тему stackful, начиная от низкого к более высокому уровню: Boost.Context, Boost.Coroutine, Boost.Fiber.
С тем же успехом все это достижимо и на чистом С, без плюсов и boost-а. Просто стоимость такого кода больше аналогичной функциональности в golang.
Здравствуйте, Cyberax, Вы писали:
C>Вдобавок, кросс-компиляция выглядит вот так: "GOOS=linux go build ...". Первыми у нас это заценили инженеры — можно написать и отладить код симуляции локально на MacBook, сделать бинарик и одной командой зафигачить на кластер на реальных данных.
Когда-то кросс-компилировал C++ код под убунтой, это были кусочки для win32, lin 32, lin 64, mac i 64 и mac ppc 32, mac ppc 64- они складывались в жава апплет и оттуда дергались в зависимости от оси/браузера. Нужно было установить кросс-компиляторный build chain из официальной репы.
Здравствуйте, Cyberax, Вы писали:
KP>>Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым. C>И при это Go-шники делают такой же качественный код.
Побуду адвокатом дьявола (не имею ничего против Go). Недавно зашел в группу по golang в telegram. Вы бы почитали их обсуждения. Это какое-то днище. Люди не знают даже стандартной библиотеки Go нормально, у большинства очень узкий кругозор и какие-то очень странные представления об окружающем мире. Из смешного, они тащат в проект только то, что написано на Go, например https://github.com/siddontang/ledisdb вместо Redis и BoltDB вместо LMDB. Судя по всему, основной контингент там состоит из бывших PHP/Ruby/Python/etc программистов.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Благодаря макросам этот стиль структурно не сильно отличается от stackful корутин — это то что было уже давно. EP>А сейчас, в нескольких мейнстрим компиляторах уже реализованны предложения stackless, причём уже несколько версий назад.
У корутин в С++ есть очень большой минус — отладка. Стектрейсов либо нет, либо в них невозможно ничего понять. Многие инструменты отладки не работают нормально с stackful корутинами, valgrind и санитайзеры могут довать false positives.
Здравствуйте, chaotic-kotik, Вы писали:
CK>у большинства очень узкий кругозор и какие-то очень странные представления об окружающем мире.
У меня такое впечатление об идейных плюсниках. Огульно поливают всё, что не их божественный C++, значительная часть верует в исключительную скорость C++, при этом не знает базовых вещей CS как big-O, основные структуры данных и т.п.
Здравствуйте, Тёмчик, Вы писали:
Тё>У меня такое впечатление об идейных плюсниках. Огульно поливают всё, что не их божественный C++, значительная часть верует в исключительную скорость C++, при этом не знает базовых вещей CS как big-O, основные структуры данных и т.п.
Высказал свое веское мнение спешиалистЪ, который Visitor освоил только проходя собеседование в 2016-ом году. Возможно, это мнение у вас сложилось поскольку вы общаетесь в среде себе подобных.
Здравствуйте, so5team, Вы писали:
Тё>>У меня такое впечатление об идейных плюсниках. Огульно поливают всё, что не их божественный C++, значительная часть верует в исключительную скорость C++, при этом не знает базовых вещей CS как big-O, основные структуры данных и т.п.
S>Высказал свое веское мнение спешиалистЪ, который Visitor освоил только проходя собеседование в 2016-ом году. Возможно, это мнение у вас сложилось поскольку вы общаетесь в среде себе подобных.
О, типичный представитель нарисовался. Выучил названия, но ничего не понял.
Здравствуйте, Тёмчик, Вы писали:
Тё>О, типичный представитель нарисовался.
Какие ваши доказательства?
Тё>Выучил названия, но ничего не понял.
Очень сложно понять как спешиалистЪ вроде вас, много лет говорящий про то, что он программирует на C++ и на Java, не знал про Visitor столько лет. Ладно бы вы на функциональных языках программировали, а про C++/Java только слышали краем уха. Так ведь нет.
Пожалуйста, объясните, как вам это удалось? Вероятно, работали в крупных конторах с хорошо налаженными процессами и эффективным менеджментом?
Здравствуйте, chaotic-kotik, Вы писали:
CK> Из смешного, они тащат в проект только то, что написано на Go, например https://github.com/siddontang/ledisdb вместо Redis и BoltDB вместо LMDB. Судя по всему, основной контингент там состоит из бывших PHP/Ruby/Python/etc программистов.
Не знаю какую ты группу имеешь ввиду, возможно ту которая относится к курсу Go на Coursera. Я лично там писал что выбрал Го в частности из-за bbolt (аля boltDb).
Можешь смеяться сколько хочешь, а я вот объясню свою логику выбора: хочется не иметь НИКАКИХ внешних зависимостей в проекте! Хочется просто тупа скопировать 2 файла на новую VPS и сервис должен работать дальше, лучше и еще быстрее. Да вот такие у меня требования к момему собственному проекту! Хочу чтобы я тратил на развертываение 2 шага: купил VPS, скопировал файлы и запустил!
bbolt выбрал исключительно потому-что это первая ссылка которую выдает Гугл по встроенным базам в Го. По описанию я понял, что меня лично она устраивает. Искал какие-нибудь тесты, не нашел ничего толкового. Решил буду сам тестировать.
PS> Не нужно всех вокруг и в частности в сообществе Го считать идиотами. У многих есть конкретные требования и они стараются в них вписаться. А уж поверь и на Си и на SQL писать многие там тоже умеют. Я лично считаю признаком идиотизма и низкой квалификации если Сишник будет создавать Вэбсервис на Си, только потому-что он крутой Сишник.
Здравствуйте, m2l, Вы писали:
m2l>С тем же успехом все это достижимо и на чистом С, без плюсов и boost-а. Просто стоимость такого кода больше аналогичной функциональности в golang.
А чем реализация в голанг на том же С будет лучше реализации на С для С?
Здравствуйте, so5team, Вы писали:
Тё>>О, типичный представитель нарисовался.
S>Какие ваши доказательства?
Тё>>Выучил названия, но ничего не понял.
S>Очень сложно понять как спешиалистЪ вроде вас, много лет говорящий про то, что он программирует на C++ и на Java, не знал про Visitor столько лет. Ладно бы вы на функциональных языках программировали, а про C++/Java только слышали краем уха. Так ведь нет.
S>Пожалуйста, объясните, как вам это удалось? Вероятно, работали в крупных конторах с хорошо налаженными процессами и эффективным менеджментом?
Я Вам уже в который раз пытаюсь донести, что «знать про визитор» и «знать визитор»- две большие разницы. Примерно как Оля «знает про C++», а Петя «знает C++». Но Вы слишком узко-кругозорный, чтобы понять.
И кстати про C++ с Java- этим список далеко не ограничивается. Только вот на Go ещё не довелось.
Не надо использовать блокировки в высокопроизводительных системах.
