A>Мой главный язык — джава. Немного питона. Языки с ручным управлением памятью, в общем, как-то обошли стороной, поэтому могу сравнить с тем что знаю
Посмотри в сторону Kotlin. Он есть в варианте для JVM (можно в проекте совмещать код на Java и Kotlin), Native (Linux, Windows, Mac, iOS, можно совмещать с кодом на C и Swift) и еще JS (но эта экзотика для тех, кто хочет фронтэнд и бэкэнд писать на одном языке). Во всех вариантах будет работать сборка мусора, даже на Native Mac или Linux.
M>Посмотри в сторону Kotlin. Он есть в варианте для JVM (можно в проекте совмещать код на Java и Kotlin), Native (Linux, Windows, Mac, iOS, можно совмещать с кодом на C и Swift) и еще JS (но эта экзотика для тех, кто хочет фронтэнд и бэкэнд писать на одном языке). Во всех вариантах будет работать сборка мусора, даже на Native Mac или Linux.
Привет. Котлин нравится. Делали бэкенд на нем. Хорошо заходит в e-commerce но замечания в большинстве относятся и к нему.
В целом он как бы "вверх от джавы", го — вниз
Здравствуйте, Zhendos, Вы писали:
Z>А так разве можно в Go просто дернуть системный вызов?
без проблем
Z>Там вроде для вызова системных вызовов нужно отдельный пул потоков городить и прочее, Z>потому что корпоративная многозадачность пойдет лесом, если прямо взять и вызвать системный Z>вызов который потенциально может текущий поток усыпить на неопределенное количество времени.
пул потоков — это не про го вообще. там другие абстракции. "пулирование" можно просимулировать, ограничив число горутин (горутина != потоку)
на возможность делать системный вызов не влияет
Z>Там вроде для вызова системных вызовов нужно отдельный пул потоков городить и прочее, Z>потому что корпоративная многозадачность пойдет лесом, если прямо взять и вызвать системный Z>вызов который потенциально может текущий поток усыпить на неопределенное количество времени.
а да. у них там есть corner cases. приняли пропосал https://github.com/golang/go/issues/24543 про preemptive вытеснение, должно помочь.
поэтому и написал в большинстве "простых" работает хорошо ж)
Здравствуйте, Masterspline, Вы писали:
M>Зачем тратить усилия на переусложненный инструмент, если нужный результат можно получить проще
Тоже самое наверное когда-то про позиционные системы исчисления говорили, ну а что, на пальцах ж проще считать, особенно когда все задачи уровня пересчитать с десяток баранов
Здравствуйте, Masterspline, Вы писали:
M>Зачем тратить усилия на переусложненный инструмент, если нужный результат можно получить проще.
Практика показывает что нельзя. Получается протекающий и падучий багадром, в котором постоянно уязвимости находят.
Собственно по этому раст и появился. Разработчики огнелиса очень хотели сделать некоторые оптимизации, но им было очень страшно. Ибо человек просто физически не способен держать в памяти все связи в сложном коде. А компилятор может. Он туп, но имеет абсолютную внимательность.
M>Rust по сравнению с C переусложнен,
А с моей точки зрения в расте не хватает многих фич.
Правда не из С++, а из сильно других языков.
M>а до возможностей C++ он не дорос и никогда не дорастет (он уже сейчас сложен, если в него добавить то, что есть в C++, он станет неподъемно сложен).
А вот с этого места подробнее.
Что такое может С++ чего не может раст?
M>Rust инструмент нишевой для фанатиков — любителей головоломок и тем, кому хочется попробовать что-то новое. Ну и до кучи, в коммерческом программировании разработчики выбирают инструмент, чтобы решить задачу, а не для того, чтобы гордиться, что они там что-то "осилили". То, ради чего в Rust приходится в каждой строчке бороться с borrow checker
Напрягал он меня только в первый день.
Дальше только помогал.
В более 90% кода я его просто не замечал. Я на нем реально писал как на немерле с немного другим синтаксисом.
Может опыт разработки на С++ просто приучил меня не делать UB вот раст меня и не напрягает.
M>(и включать unsafe, когда побороть его не получается, например, для двусвязного списка),
Зачем тебе двусвязный список?
Мне, правда, интересно. Я написал очень много сложных алгоритмов и двусвязный список не использовал ни разу.
M>в C++ решается использованием статического анализатора типа coverity. Людей, которые борются со своим инструментом разработки (с переменным успехом) и гордятся, когда "осиливают" его, я уже давно перестал понимать.
Просто, прежде чем писать на языке, нужно понять его философию. Тогда ты сможешь брать этот язык под задачу, которую на нём хорошо решать. И будешь её решать в том стиле, который поощряет данный язык. Тогда и бороться будет не с чем.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, andmed, Вы писали:
WH>>У go даже эмблема со зверюшкой, у которой явно синдром дауна. A>Спасибо за анализ. Я замечал что растаманы активные, а они еще и злобные оказывается
Здравствуйте, andmed, Вы писали:
A>- обработка ошибок. например у меня передается буфер и я делаю в методе несколько записей в него. мне все равно на какой по счету записи я сфейлюсь, мне нужно выкинуть ошибку а количество записанных символов не важно (ответ по http скажем шлем). так бы я поставил try/catch и все, а в го нужно If на каждую запись. и дело не в сборке стека. если в го есть семантика сигнализирования об ошибке то хотелось бы механизмы удобной их аггрегации и без сбора стека A>- традиционно сюда относят отсутствие дженериков.
Это будет поправлено в следующих версиях, сейчас идут обсуждения и эксперименты. В целом, по прикидкам получится неплохо.
A>- долгоживущих монолитов на нем не писал, но вызывает вопросы их работоспособность учитывая что гошный GC (afaik) не умеет compaction
Умеет, в Go сейчас точный GC с уплотнением. Он также умеет возвращать память обратно системе.
A>- в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем.
Есть atomic.Value и сотоварищи.
A>- управление зависимостями. тема известная. авторы языка не сидят на месте. здесь пусть выскажутся те, кто пишут большие проекты в продакшн с многими зависимостями. вроде как работа ведется постоянно. без конфликтующих зависимостей проблем нет как с GOPATH так и с новыми модулями (с модулями есть баги, допиливают)
Новая система модулей вполне логичная, ничем не хуже Maven для JVM. Про модули в Java 10 я вообще умолчу — уродство ещё то.
A>- девелоперское сообщество. когда пытаются перенести практику ООП. с интерфейсами и тайп кастингом в го можно можно накрутить, но в таких случаях непонятно, зачем берут именно го, если нужен энтерпрайз то это другие языки. на го это получается.. плохо
Не надо на Go писать в стиле Java. Собственно, и на Java не надо писать в стиле Java.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, andmed, Вы писали:
A>>- в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем. C>Есть atomic.Value и сотоварищи.
физически они-то есть конечно, но на них гарантий нет. то есть разработчики не гарантируют их работу (например, в части оптимизаций компилятора и видимости других переменных). https://golang.org/ref/mem
Здравствуйте, andmed, Вы писали:
A>>>- в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем. C>>Есть atomic.Value и сотоварищи. A>физически они-то есть конечно, но на них гарантий нет.
Есть. atomic.Value гарантированно работает. Нет гарантий, если делать присваивания вручную.
Здравствуйте, Cyberax, Вы писали:
Ops>>Атомарность есть, а барьеров нет. Хрен знает, что там компилятор и/или процессор переупорядочит. Все же привычный atomic — это еще и барьеры. C>atomic.Value является барьером, он не переупорядочивается. Все методы в atomic аннотированы как //go:noinline. Это планируется официально кодифицировать как барьер, но у пока разработчиков руки не дошли ( https://github.com/golang/go/issues/5045#issuecomment-412714313 ). На практике всё работает.
Тут скорее речь о том, что в том же C++ ты можешь явно задать тип синхронизации (хрен знает как по-русски правильно будет) атомарных переменных: https://en.cppreference.com/w/cpp/atomic/memory_order. В Go, похоже что, по умолчанию везде встроенна модель аналогичная std::memory_order_seq_cst.
Здравствуйте, kaa.python, Вы писали:
KP>Тут скорее речь о том, что в том же C++ ты можешь явно задать тип синхронизации (хрен знает как по-русски правильно будет) атомарных переменных: https://en.cppreference.com/w/cpp/atomic/memory_order. В Go, похоже что, по умолчанию везде встроенна модель аналогичная std::memory_order_seq_cst.
Да, именно так. В Go всё очень примитивно, хотя в стандартной библиотеке и рантайме используются более продвинутые механизмы. Можно и самому, но это будет уже зависимость от деталей работы компилятора.
KP>Тут скорее речь о том, что в том же C++ ты можешь явно задать тип синхронизации (хрен знает как по-русски правильно будет) атомарных переменных: https://en.cppreference.com/w/cpp/atomic/memory_order. В Go, похоже что, по умолчанию везде встроенна модель аналогичная std::memory_order_seq_cst.
вот ведь.. в плюсах подробная документация. спасибо за ссылку!
Здравствуйте, WolfHound, Вы писали:
WH>Нужна не скорость, а параллельность, инкрементальность и спекулятивность (это когда ИДЕ компилирует код, пока ты пишешь). В этом случае даже если ты начал работать с проектом, в котором гигабайт исходников то компиляция завершиться мгновенно.
К сожалению, это фантазии, который не практике не работают. Инкрементальность не дает гарантированно быстрой компиляции при изменении любого участка кода. А если этого нет, будет возникать куча ситуаций в процессе разработки, когда программист из команды поменял одну строчку кода, и у всех полностью перекомпилируется проект. Единственный способ бороться с долгой компиляцией (инкрементальной в том числе) — делать как можно меньше зависимостей между компонентами, и компилировать их отдельно. Какие бы хорошими ни были программисты, если сам по себе язык не способствует написанию слабо связного кода (loosely coupled), то любой большой проект скатится к долгой компиляции. А не способствуют этому все ООП языки. В rust в этом плане плохо сделаны traits, поскольку при описании реализации нужно явно указывать имя trait. В интерфейсах Go реализован duck typing вместо явного указания интерфейса при описании реализации, что уменьшает связность кода. Но в Go много других проблем. Нет дженериков например.
По-хорошему в языке должен быть единый синтаксис для описания обобщенных конструкций, должны быть контракты, которые накладывают ограничения на множество типов одновременно, а не по контракту на каждый отдельный тип (интерфейсы, traits). В зависимости от режима компиляции (можно добавить PGO, JIT) должен автоматически выбираться динамический или статический способ реализации обобщенных функций. В крайнем случае можно добавлять необязательные подсказки компилятору. Это позволит как сократить объем генерируемого машинного кода и отладочной информации (в случае динамической реализации), что напрямую влияет на время компиляции, так и оптимизировать узкие места (статическая реализация).
Пока ни Go, ни Rust не являются идеальными языками. В Go решали (и частично решили) проблему со сложностью кода проектов и скоростью компиляции, но не реализовали часть других нужных фичей. Кроме этого, из-за сборки мусора язык не может быть системным или подходящим для высокопроизводительных приложений. В Rust решали проблему безопасного управления памятью без накладных расходов в runtime. Проблему эту решили, но с точки зрения простоты кода и монолитности (я не имею в виду локальную сложность, связанную с borrow checker) кода язык не далеко ушел от C++. Как мне кажется, в больших проектах на С++ на миллионы строк основная проблема не безопасная работа с памятью. При достаточной квалификации программистов и использовании различных инструментов для тестирования (санитайзеры, фаззеры) ошибки работы с памятью отлавливаются. Основная проблема в нарастающей сложности проекта и замедлении разработки.
Здравствуйте, Aleх, Вы писали:
A>К сожалению, это фантазии, который не практике не работают. Инкрементальность не дает гарантированно быстрой компиляции при изменении любого участка кода. А если этого нет, будет возникать куча ситуаций в процессе разработки, когда программист из команды поменял одну строчку кода, и у всех полностью перекомпилируется проект.
Вот тут ты не прав. У всех не будет.
Будет у одного. Причем он будет использовать для этого все машины в конторе.
А когда остальные обновляться, то всё уже будет скомпилировано. К ним бинарники по гигабитной сетке приедут.
A>Единственный способ бороться с долгой компиляцией (инкрементальной в том числе) — делать как можно меньше зависимостей между компонентами, и компилировать их отдельно. Какие бы хорошими ни были программисты, если сам по себе язык не способствует написанию слабо связного кода (loosely coupled), то любой большой проект скатится к долгой компиляции. А не способствуют этому все ООП языки. В rust в этом плане плохо сделаны traits, поскольку при описании реализации нужно явно указывать имя trait. В интерфейсах Go реализован duck typing вместо явного указания интерфейса при описании реализации, что уменьшает связность кода. Но в Go много других проблем. Нет дженериков например.
Теперь попробуй придумать сценарий, в котором в случае с go не придётся все перекомпилировать, а в случае с раст придётся.
И главное оцени его реалистичность.
Ну и не забывай что трейты в расте намного мощнее.
Например, можно прицепить к типу свой трейт. Даже если это не твой тип.
Далее можно реализовывать трейты для трейтов. Таким образом, если ты реализовал один трейт то в подарок получаешь ещё несколько.
А когда у нас появляются генерики, то всё становиться ещё интереснее.
Реализацию трейтов можно сделать зависимой от того какие трейты реализуют параметры типа.
A>Ещё в rust некрасивая двойственность синтаксиса:
хъ A>По-хорошему в языке должен быть единый синтаксис для описания обобщенных конструкций,
Небольшой сахарок. Не более того. Вообще не проблема.
И вообще данная фича используется почти исключительно для возвращения итераторов из функций.
A> должны быть контракты, которые накладывают ограничения на множество типов одновременно, а не по контракту на каждый отдельный тип (интерфейсы, traits).
Пример можно?
Если это что-то интересное, то можно в раст RFC запилить. Если плюшки будут стоить мороки с реализацией то наверняка сделать.
Там даже non lexical lifetimes сделали. А мороки с ними очень много.
Правда, до стабильной версии они ещё не доехали, но как я понял из переписки это вопрос ближайшего времени.
A>Пока ни Go, ни Rust не являются идеальными языками.
Это вообще не возможно. Для каждой задачи оптимальным является язык заточенный для этой задачи.
A>В Go решали (и частично решили) проблему со сложностью кода проектов и скоростью компиляции, но не реализовали часть других нужных фичей.
Они решили задачу использования программистов, для которых вот это
for trans in state_set.iter()
.flat_map(|state| vars.signal_transitions.get(state))
.flatten()
нереально сложный код.
При этом в реальности код проектов становится сложнее. Ибо если переписать это на циклах, то тут будет гора кода.
A>В Rust решали проблему безопасного управления памятью без накладных расходов в runtime. Проблему эту решили, но с точки зрения простоты кода и монолитности (я не имею в виду локальную сложность, связанную с borrow checker) кода язык не далеко ушел от C++.
Монолитность кода зависит исключительно от разработчиков, а не от языка.
Есть, конечно, языки где нет возможности декомпозировать код. Там всё плохо. Но раст и С++ к ним не относятся.
A>Как мне кажется, в больших проектах на С++ на миллионы строк основная проблема не безопасная работа с памятью. При достаточной квалификации программистов и использовании различных инструментов для тестирования (санитайзеры, фаззеры) ошибки работы с памятью отлавливаются. Основная проблема в нарастающей сложности проекта и замедлении разработки.
Каждый раз, когда кто-то начинает разговор в стиле git gud то люди открывают его код или трекер и сразу находя кучу ошибок, которые может устранить более умный язык.
Рискнёшь свой код показать?
Проблема больших проектов в том, что они создают очень большую ментальную нагрузку. Которая умножается на ментальную нагрузку создаваемую языком.
А раст по сравнению с С++ создаёт намного меньшую ментальную нагрузку даже в обычном коде. А когда дело доходит до многопоточности разница просто колоссальная.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
A>>- долгоживущих монолитов на нем не писал, но вызывает вопросы их работоспособность учитывая что гошный GC (afaik) не умеет compaction C>Умеет, в Go сейчас точный GC с уплотнением. Он также умеет возвращать память обратно системе.
не смог найти упоминания compaction в гошном gc. наоборот, здесь прямо разрешается передача пойнтеров в сишный код, что при уплотнении было бы небезопасно https://golang.org/cmd/cgo/#hdr-Passing_pointers
для больших данных не менее важно и то что гошный gc не generational. вижу много жалоб на медленную работу гц при больших мапах. там же есть некоторые решения, но для себя сделал вывод что пытаться с го работать с большим хипом — это использование этого языка не по назначению. пока не впилят generational гц (и если, да)
Здравствуйте, andmed, Вы писали:
A>>>- долгоживущих монолитов на нем не писал, но вызывает вопросы их работоспособность учитывая что гошный GC (afaik) не умеет compaction C>>Умеет, в Go сейчас точный GC с уплотнением. Он также умеет возвращать память обратно системе. A>не смог найти упоминания compaction в гошном gc.
Действительно, я ошибся. GC в Go точный (не консервативный) и параллельный, но не уплотняющий: https://golang.org/src/runtime/mgc.go
A>наоборот, здесь прямо разрешается передача пойнтеров в сишный код, что при уплотнении было бы небезопасно https://golang.org/cmd/cgo/#hdr-Passing_pointers
C code may not keep a copy of a Go pointer after the call returns. This includes the _GoString_ type, which, as noted above, includes a Go pointer; _GoString_ values may not be retained by C code.
Рантайм автоматически пришпиливает указатели при вызове С-кода.
