да я не про фичи

ну так в этой фиче и есть единственный смысл и идея

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

сравнима по крутости разве что clojure

в clojure круче?

Идея в том, что го не нужен

это нода не нужна, не путай

в clojure круче?

в clojure STM охренительный

а парралельность в вэбе нужна?

она упирается только в пределы JVM, но, имхо, тот, кто перепишет ее под JIT какой-нибудь хороший, совершит революцию

а парралельность в вэбе нужна?

на бэке да

1) структуры в го не являются просто блоками памяти с оффсетами по типу данных. Там есть менеджер, который может их перемещать и даже бить на куски при необходимости. 2) вот именно. То есть в си есть гибкость, а в го прибита гвоздями конкретная реализация. Некастомизируемая притом, хоть и неплохая. 3) нет, вообще разные паттерны. Как минимум потому, что ошибок в си нет в принципе. 4) не понял, к чему это вообще 5) ты, видимо, имел в виду сильную типизацию. В си она сильнее, чем в го. 6) в си писали функции, в го пишем асинхронные обработчики. Да, синтаксис близкий, но суть довольно разная.

1) Деление было на основе встраиваемых структур. Всё сложнее стало когда встриваемость сделали по указателю, я же про простые структуры. Если и там он дробит, то это уже интереснее, про такое не слышал. 2) Любая гибкость - поле для ошибок. Go создавался как opinionated решение для типичных задач. Зачем иметь 100 имплементаций и подходов, когда есть один - проще для всей экосистемы. Go создавался для реалий определённых задач. 3) В таком случае в гоу тоже нет ошибок. Там есть только интерфейс что называется error. Всё! А передавай что хочешь. Всё что есть из того, что нет в си - panic. Но факт наличия интерфейса error - opinion, которое часто используют в си, не просто так. Это паттерн, который приживался в си годами и такую практику просто стандартизировали - сделав в Go 4) К тому, что если опустить компилируемость и оптимизацию, то по этому пункту Python не отличается от Си 5) Статическая сильная, дополню. В си же тайп-каст позволяет сделать что угодно и не редко люди это использовали, но не сказать чтобы это часто было плюсом. В Гоу больше ограничений на то, как ты можешь работать с данными, но в рамках разумного - opinion разработчиков. 6) По сути Гоу сам пришлось основать на асинхронном подходе с горутинами и пуллом потоков. По этой причине ты пишешь функцию, но можешь запускать её как корутину, используя возможности имплементации. Чем же отличие от Си, если в Си ты бы использовал libuv, boost::asio?

это прям языки из совсем разных областей

Да ёлки. У Си нет "области"

Си применяется вообще везде. Из этого "везде" есть огромное количество под-областей, для которых Гоу и создавался. Си же всё-равно имеет право на жизнь, так как он, как я и сказал, "везде", и opinionated решение не может покрыть это "везде"

1) Деление было на основе встраиваемых структур. Всё сложнее стало когда встриваемость сделали по указателю, я же про простые структуры. Если и там он дробит, то это уже интереснее, про такое не слышал. 2) Любая гибкость - поле для ошибок. Go создавался как opinionated решение для типичных задач. Зачем иметь 100 имплементаций и подходов, когда есть один - проще для всей экосистемы. Go создавался для реалий определённых задач. 3) В таком случае в гоу тоже нет ошибок. Там есть только интерфейс что называется error. Всё! А передавай что хочешь. Всё что есть из того, что нет в си - panic. Но факт наличия интерфейса error - opinion, которое часто используют в си, не просто так. Это паттерн, который приживался в си годами и такую практику просто стандартизировали - сделав в Go 4) К тому, что если опустить компилируемость и оптимизацию, то по этому пункту Python не отличается от Си 5) Статическая сильная, дополню. В си же тайп-каст позволяет сделать что угодно и не редко люди это использовали, но не сказать чтобы это часто было плюсом. В Гоу больше ограничений на то, как ты можешь работать с данными, но в рамках разумного - opinion разработчиков. 6) По сути Гоу сам пришлось основать на асинхронном подходе с горутинами и пуллом потоков. По этой причине ты пишешь функцию, но можешь запускать её как корутину, используя возможности имплементации. Чем же отличие от Си, если в Си ты бы использовал libuv, boost::asio?

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

Оу. Мы возможно о разном. Никто не говорит что Гоу вытеснит. Это нереально и не нужно. Но для новых решений, для которых выбирается Си, крайне часто Гоу окажется более удобным вариантом.

вот

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

Опять же, я не говорю что они одинаковые. Я говорю что гоу имеет базис в виде опыта и подходов Си, ниш в которых Си кажется слишком сложным и отсталым для применения - highload I/O сервисы, что покрывает нынче огрооооомное количество задач и решений

Опять же, я не говорю что они одинаковые. Я говорю что гоу имеет базис в виде опыта и подходов Си, ниш в которых Си кажется слишком сложным и отсталым для применения - highload I/O сервисы, что покрывает нынче огрооооомное количество задач и решений

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

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

Позволь переформулировать: гоу - замена Си в области разработки highload I/O решений. Именно это я и имел ввиду

скажите, а вы считаете го нормальным языком?

Более чем

Позволь переформулировать: гоу - замена Си в области разработки highload I/O решений. Именно это я и имел ввиду

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

а на самом деле нет

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

Да как. В Европе и России был и до сих пор есть. В США в этой области, внезапно, JAVA ?

Да как. В Европе и России был и до сих пор есть. В США в этой области, внезапно, JAVA ?

покажи хоть одну промышленную распределенную хайлоад систему на сях

Мне приходилось работать над продуктом для обработки котировок и ставок. В результате этот продукт вроде как продали ращработчику самой популярной системы закрытой торговли в России и Европы - MetaTrader

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

ээ, всем? вообще ничего общего у них. Структуры в го никак не связаны со структурами в си, кроме как слегка похожим синтаксисом. С параллельностью совсем другая парадигма со своими плюсами и минусами. Управления памятью и параллельностью в го практически нет вообще.

Про структуры ты не прав

Слышал что в Selectel есть разработки на Си для виртуализации(я правда не специалист в этой нише), именно потому они перешли очень быстро на Гоу, как я полагаю

JAVASCRIPT @ МОЛОДОСТЬ @ ХАРДКОР

"0"+3

Про структуры ты не прав

нда? то есть в го есть выравнивание и возможность обратиться к полям по указателям по смещениям от вершины структуры?

покажи хоть одну промышленную распределенную хайлоад систему на сях

О, чуть не забыл. У меня джун года 3 назад был, в ИТМО учился. Говорил посылали работать в какой-то завод, писать на Си и делфях, какая система документоборота и синхронизации с другими инстанциями

нда? то есть в го есть выравнивание и возможность обратиться к полям по указателям по смещениям от вершины структуры?

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

нда? то есть в го есть выравнивание и возможность обратиться к полям по указателям по смещениям от вершины структуры?

https://golang.org/pkg/unsafe/#Offsetof

https://golang.org/pkg/unsafe/#Offsetof

получить-то его можно. А само поле по нему достать?

получить-то его можно. А само поле по нему достать?

Сейчас поиграюсь, посмотрю

1) структуры в го не являются просто блоками памяти с оффсетами по типу данных. Там есть менеджер, который может их перемещать и даже бить на куски при необходимости. 2) вот именно. То есть в си есть гибкость, а в го прибита гвоздями конкретная реализация. Некастомизируемая притом, хоть и неплохая. 3) нет, вообще разные паттерны. Как минимум потому, что ошибок в си нет в принципе. 4) не понял, к чему это вообще 5) ты, видимо, имел в виду сильную типизацию. В си она сильнее, чем в го. 6) в си писали функции, в го пишем асинхронные обработчики. Да, синтаксис близкий, но суть довольно разная.

Ты неправ про структуры

Ты неправ про структуры

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

про смещения полей внутри - возможно, unsafe позволяет какие-то такие трюки

но это скорее исключение, чем правило, в хорошем коде

про смещения полей внутри - возможно, unsafe позволяет какие-то такие трюки

Трюки в коде - допустимо только для динамических языков и воркараундов

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

А ты полагаешься?

А ты полагаешься?

нет, я вообще в го не использую ни unsafe, ни его антипода - reflect

нет, я вообще в го не использую ни unsafe, ни его антипода - reflect

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

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

абсолютно согласен

нда? то есть в го есть выравнивание и возможность обратиться к полям по указателям по смещениям от вершины структуры?

По смещениям можно, да.

По смещениям можно, да.

получить смещения можно. А обратиться по ним?

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

Есть там адресная арифметика

получить смещения можно. А обратиться по ним?

Да, в чем проблема?

Есть там адресная арифметика

нет

по умолчанию

Есть там адресная арифметика

Я и сказал, но через библиотеку ?

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

Пфф... С чего бы вдруг?

про смещения полей внутри - возможно, unsafe позволяет какие-то такие трюки

Так unsafe и понеслось

по умолчанию

См мой ник.

Пфф... С чего бы вдруг?

как минимум с того, что в го указатели работают не так ,как в сях

Так unsafe и понеслось

есть пример?

есть пример?

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

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

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

Окей, я вот играюсь, сам такого не делал, но сейчас посмотрим ?

предрекаю, что это будет треш, угар и содомия

по сравнению с сями :)

есть пример?

https://dpaste.de/nnpA/raw

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

предрекаю, что это будет треш, угар и содомия

На самом деле всё просто. Оборачиваешь в пойнтер и добавляешь оффсет

https://dpaste.de/nnpA/raw

какой ад

На самом деле всё просто. Оборачиваешь в пойнтер и добавляешь оффсет

вместо того, чтобы амперсанд взять, ага

https://dpaste.de/nnpA/raw

Впрочем выглядит в этом примере так себе, но суть то та же самая

какой ад

https://dpaste.de/fbjv/raw

какой ад

оно там так ради скорости

ERROR: S client not available

https://dpaste.de/fbjv/raw

еще хуже

вместо того, чтобы амперсанд взять, ага

Нет-нет. Я же говорил, Go защищает разработчика от такой ереси. Ты просто явно говоришь: я хочу ересь. И дальше пишешь как в Сях

Нет-нет. Я же говорил, Go защищает разработчика от такой ереси. Ты просто явно говоришь: я хочу ересь. И дальше пишешь как в Сях

я не говорю, что я хочу ересь :) я говорю - го не замена сей

еще хуже

нууу.. в Go можно кастить из/в unsafe.Pointer любой указатель. но адресная арифметика есть только для uintptr

нууу.. в Go можно кастить из/в unsafe.Pointer любой указатель. но адресная арифметика есть только для uintptr

потипу void*?

потипу void*?

да.

да.

ад

ну вот да, этот момент печалит и хотелось бы просто иметь возможность помечать какой-то блок кода как unsafe

как минимум с того, что в го указатели работают не так ,как в сях

и этот тезис неверный )

потипу void*?

https://play.golang.org/p/E0OtH-9t-r7

ну вот да, этот момент печалит и хотелось бы просто иметь возможность помечать какой-то блок кода как unsafe

Я тут перекрестился. Не дай бог такое дадут в руки веб-разработчика ?

и этот тезис неверный )

С чего бы?) Пока почти все верные были

С чего бы?) Пока почти все верные были

А какие должны быть причины у гоу, чтобы указатели работали как-то не так? 0о

Указатель в го не так работает, как минимум потому, что GC есть

А как работает GC? ))

А какие должны быть причины у гоу, чтобы указатели работали как-то не так? 0о

автоматическое управление памятью и аллокаторы, например

А как работает GC? ))

а что, в сях удаление объекта по указателю где-то уменьшает счетчик ссылок?

У тебя есть куча и стек. Всё что делает за тебя гоу - переносит из стека в кучу если ты взял укзатель

а чё там не сразу в куче объекты создаются?

а что, в сях удаление объекта по указателю где-то уменьшает счетчик ссылок?

Да. Я использовал как-то GC для С++, ради фана. Почему бы это не считать за то же самое? ?

и что, в сях аллокатор может переложить структуру в памяти в другое место для ускорения кода?

Да. Я использовал как-то GC для С++, ради фана. Почему бы это не считать за то же самое? ?

потому что мы про C, а не про C++?

а чё там не сразу в куче объекты создаются?

У гоу своё понятие стека, в куче. Но там сохраняется необходимость в стеке, где уже проще очищать память в силу очевидности её использования

Я тут перекрестился. Не дай бог такое дадут в руки веб-разработчика ?

это да. ну или хотя бы разрешить адресную арифметику для unsafe.Pointer.

Указатель в го не так работает, как минимум потому, что GC есть

нет, неверно.

потому что мы про C, а не про C++?

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

нет, неверно.

нет, верно

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

ну, не совсем как библиотека все-таки

и что, в сях аллокатор может переложить структуру в памяти в другое место для ускорения кода?

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

чтобы писать без нее - это надо сильно ухитриться

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

ну, тут нечто немного более хитрое, чем просто аллокатор