теперь заживём

компилируемый руби

тот момент когда шмузи начинает отпускать

пацаны, а если питон транслировать в с++ и откомпилировать будет скорость с++?

сдается мне что в вашей поделке скорость тоже от руби будет

типа гил?

это же не руби

типа кложи

кложа это лисп с с выражениями, там этого нет

и синтаксис похож на руби

не знаю зачем я это смотрел

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

ну и там интерпретатор, а не компилятор

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

там в конце даже ссылка есть на книжку

https://interpreterbook.com/

слушали последний выпуск девзена? ребята из okmeter используют go для клиентов, которые метрики отправляют и очень довольны http://devzen.ru/episode-0148/

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

Есть вполне конкретное определение у того же Фаулера, что такое "чистый код"

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

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

посыл был в том, что это не руби, который компилируется в го

кажется понял

но это не точно

#вакансия #работа #релокация #офис #backend Доброго дня. Международная компания из сферы онлайн игр и гемблинга наймет Backend Developer. Требуется: - опыт коммерческой разработки на бекэнде от 3-х лет - знание и умение Go - опыт с SQL и NoSQL выше самых простых запросов - понимание Scrum/Kanban и следование принципам TDD - плюсом будет опыт/знание JavaScript, Angular и/или React Условия: - офис в Таллине, фултайм - 2500-3500 EUR на руки Контакт: tygertrail@gmail.com ЛС могу пропустить

А вот после godep save планируется ли vendor папку в git засовывать, или так как мы имеем ревизии в godep.json это не нужно? Что скажете

А вот после godep save планируется ли vendor папку в git засовывать, или так как мы имеем ревизии в godep.json это не нужно? Что скажете

не нужно

Я бы сказал, что по желанию.

Репозиторий могут удалить и скачать будет неоткуда :)

ребят что лучше на ваш взгляд: kubernetes или docker swarm? аргументировнно пожалуйста

Как уже было сказано выше - попросить показать код, с которым придется работать

Архитектурный вопрос: есть ли у event loop'а преимущество перед green thread'ами единственное мне известное преимущество event loop'а это отсутствие конкуррентного программирования, т.е. ручной синхронизации а ещё есть?

а?!

грин треды это абстракция поверх евент лупа, соответственно евент луп менее ресурсозатратен наверн

коллеги

коллеги

остановитесь, рогатые твари!

А вот после godep save планируется ли vendor папку в git засовывать, или так как мы имеем ревизии в godep.json это не нужно? Что скажете

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

гринтреды - термин из java 1.0, означал псевдотреды на кооперативной многозадачности

грин треды это абстракция поверх евент лупа, соответственно евент луп менее ресурсозатратен наверн

эмм, разве green thread scheduler это event loop??

нет, конечно

в чем принципиальные отличия?

но сетевой ввод-вывод в go на событиях, насколько я знаю

но сетевой ввод-вывод в go на событиях, насколько я знаю

ну там на самом деле select (poll, epoll kpoll etc.)

которые не события, да

в чем принципиальные отличия?

в написании кода... в то время как на green thread'ах можно писать блокирующий код - на event loop'е это катастрофа

это с точки зрения пользователя

ребят что лучше на ваш взгляд: kubernetes или docker swarm? аргументировнно пожалуйста

Такие вопросы напоминают этот бородатый тред: https://www.anekdot.ru/id/117802/

event loop -> получает событие -> вызывает callback

scheduler -> переключение контекста -> выставляет instruction pointer

всё верно, event loop имеет только 1 поток выполнения бизнес логики, green thread'ы могут выполняться параллельно

как по мне так scheduler работает как event loop где события - это тригер переключение контекса (runtime.gosched(), системный вызов и т.д.)

эмммм

вроде бы в бусте есть асио

и там ты можешь пул потоков назначить на обработку сервиса

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

на потоках пула?

asio - это не гринтреды

я этого и не говорил

о чем то все?.. а, о преймуществах эвентлупа перед гринтредами!

как по мне так scheduler работает как event loop где события - это тригер переключение контекса (runtime.gosched(), системный вызов и т.д.)

в данном вопросе мы исходим из точки зрения пользователя (программиста естественно), как реализован scheduler - неважно и не видно, главное что код мы пишем на green thread'ax. А с event loop'ом код мы пишем на callback'ах, promise'ах и т.д.

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

ну ты спрашивал в чем преимущество event loop'а - он уровнем ниже, соответственно накладных расходов может быть меньше, при правильном приготовлении

он уровнем глубже :)

но накладные расходы на переключение контекста - это из эпохи одноядерных процессоров (P3) страшилка

однако в event loop'е огромная проблема с написанием блокирующего кода

однако в event loop'е огромная проблема с написанием блокирующего кода

новички любят синхронный код код блокируя этим event loop, это катастрофа

callback hell?

он, родимый

вернее, нет

callback hell уже сто лет не актуален

это другая проблема

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

но она стоит острее

по крайней мере на си и плюсах

на древних компиляторах

против callback hell есть инструменты например Promises, на данный момент разрабатываю библиотеку асинхронного программирования для Qt: https://qbeon.github.io/QuickStreams/

уже столько сахара накрутили и паттернов, что коллбэк хэла уже давно нет

там ещё более продвинутый подход.. asynchronous programming in streams

в кутэ же система событий во фреймворке, зачем там асинхронная библиотека?