другой вопрос насколько это оправдано

потому что код на си опасен, вцелом для всей вм

если гдето будет баг утечка памяти или еще чтото

также и с Go vs любой язык с динамической типизацией, если скорость ДОСТАТОЧНА, пофигу на попугаи

то рухнет вся машина

вон на похапэ демонов пишут

GO идеологически не признаю. Немогу смириться что я мартышка

там память течёт

интересно как nif и планировщик бима сработаются

если ниф будет отжирать все процессорное время

GO идеологически не признаю. Немогу смириться что я мартышка

я вот не могу понять для чего он, для каких задач

вот это незнаю

можно иначеэ

можно написать одтельную однопоточную ноду

на си

и работать через RCP

это тоже есть

нода рухнет

ее опять можно поднять

http://erlang.org/doc/tutorial/cnode.html

GO идеологически не признаю. Немогу смириться что я мартышка

о! я не один такой значит..

интересно как nif и планировщик бима сработаются

http://erlang.org/doc/man/erl_nif.html

тут описано

и логотиа у ГО, такая тупая и смешная какашка голубого цвета

ну перестали же на асме всё подряд делать, потому что скорость работы программ на Си была ниже, но ДОСТАТОЧНОЙ

после того, как я написал первое и последнее приложение под win на asm... в общем, там одни коллбеки и вызовы виндового апи. так что если ты там даже что-то и сделаешь быстро, то только 1+2. а потом всё это будет дружно ждать ответа винды. так что разница только в синтаксисе. а си по определению лаконичнее и понятнее, чем asm

GO идеологически не признаю. Немогу смириться что я мартышка

++

после того, как я написал первое и последнее приложение под win на asm... в общем, там одни коллбеки и вызовы виндового апи. так что если ты там даже что-то и сделаешь быстро, то только 1+2. а потом всё это будет дружно ждать ответа винды. так что разница только в синтаксисе. а си по определению лаконичнее и понятнее, чем asm

так надо же алгоритмы бенчмаркать =)

дело не в какашке. я не люблю якобы "зеленые процессы, как в ерланге"

ну про логотип это юмор конечно

но всетаки он какбы намекает

свое мнение я выложил в ветке камментов https://habrahabr.ru/company/wrike/blog/323550/#comment_10115444

дело не в какашке. я не люблю якобы "зеленые процессы, как в ерланге"

гороутины и есть "зелёные потоки" =)

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

если шедулинг происходит не в ядре, а в рантайме - это зелёные потоки =)

гороутины и есть "зелёные потоки" =)

но они не как в эрланге

ясен пень

но по терминологии они все зелёные

В ерлаге полноценная модель Акторов

в го

каналы какието

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

я честно говоря слабо представляю чем шедулинг го отличается от шедулинга эрланга

и как можно к одному из них относиться отрицательно? - хз

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

ну в эрланге у тебя ВМ полноценная, которая шедулит

нет вытесняющей многодазачности между ними

нет контроля над работой горутин. как их убить. как узнать, что она сдохла.

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

в го как с этим делом?

в го как с этим делом?

if err != nil

ну может потом в Go это и поправят. сегодня вон в камментах написали про Go1.8. там все должно стать "в 2 а то и более раз быстрее"

if err != nil

да и без паттерн матчинга всё это превращается в жуткую лапшу

ну. к моей говностатье вообще написали перл. что то типа "лапша из функций паттернматчинга"

ну может потом в Go это и поправят. сегодня вон в камментах написали про Go1.8. там все должно стать "в 2 а то и более раз быстрее"

кому это нужно и для каких целей?

да, в ерланг патерн матчин гармонично встраивается в отлов ошибок

ну. к моей говностатье вообще написали перл. что то типа "лапша из функций паттернматчинга"

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

кому это нужно и для каких целей?

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

да ну. плюсов мало. статья говно. я уже вот думаю пора завязывать писать статьи на хабр. никакого профита вообще

да и без паттерн матчинга всё это превращается в жуткую лапшу

не просто жуткую, а очень жуткую, но @mtreskin скажет "Ну и что?"

абстрактные фразы - "для более качественной многозадачности. контролем над завершением" а люди то решают конкретные задачи

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

вот мне и интересен класс задач для которых я должен выбрать Golang, а не C++ или Elixir или Ruby

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

а картинка даже лучше чем статья! :)

ERROR: S client not available

Александр. ты спросил про абстрактную вещь - про многозадачность. я тебе про нее и ответил

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

что я сделал не так?

камменты помогают! каждый раз что-то новое узнаю для себя

есть люди, которые решают конкретные задачи на го

да я не говорю что не писать, я грущу, что люди не могут правильно воспринимать подобные статьи

и по кой-то хрен им становится нужно управляемо прибивать горутины

не просто жуткую, а очень жуткую, но @mtreskin скажет "Ну и что?"

Ну и что?

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

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

но в чатике Го мне пояснили, что это не так. и в каких случаях это может сиграть плохую шутку

Ну и что?

привет ;)

я просто не мог допустить, что в 2010 году, кто-то может сделать многозадачность таким образом, что горутина прерывается, когда я из нее, допустим, делаю print

привет ;)

Привет

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

так было в windows до 95й. можно было запустить exe и он завешивал всю винду

апп на go спасает то, что она берет сразу несколько threads

как в ГО с иммутабельностью?

апп на go спасает то, что она берет сразу несколько threads

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

Ребята

или Clojure?

У вас спина белая

У вас спина белая

У вас спина белая

это не белая, это #F4FCFC

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

Зачем так делать? Надо выход предусматривать.

или Clojure?

Вообще кложура смотря где, на java это java threads на javascript ну там туго, хотя core.async конкретно спасает

а riak ts тыкал кто?

а riak ts тыкал кто?

riak cs только =) (очень хороший и стабильный продукт)