Свои. У нас реализация некоторой математики на Си писана. Там Си используется и потому что скорость и потому что эти алгоритмы нам нужны не только на сервере, а Си он везде применим, на всех платформах, в отличие от Go/Rust/ObjC/Java/etc.
Ока-ай, изменяем задачу — значится мы теперь совсем не сервер, а очень даже клиент. Нам нужно сделать какой-нибудь http get к сильно тормозящему серверу, и пока оно тормозит и сосет оттуда данные медленно медленно, продолжать печатать в консольку раз в секунду что-нибудь. Так? ;-)
Да, при этом у нас процесс должен быть один и поток должен быть один.
Ну, основная цель и основной, флагманский проект на Rust это все же не встраиваемые решения, а просто многопоточный движок браузера. Именно поэтому в Rust вкладывается Samsung и поэтому Rust вообще был придуман мозиллой.
Да, парсит. Это называется cgo ( golang.org/cmd/cgo/ ). Если не соответствует то будет ровно то же самое, что бывает в этом случае и в Си — ошибка компоновки.
У нас код тех самых демонов в основном написан на Го но там есть вкрапления на Си- оно все абсолютно бесшовно собирается целиком в единый исполняемый файл.
За это я лично Go и ценю (кроме всего прочего). Собственно даже яблочный Swift работает с Си намного более геморройным образом.
Ну, то есть биндинг все равно писать надо, и хедеры сишные оно не понимает (поэтому и нужно руками писать lib_curses.cr), соответственно если в либе изменится сигнатура функций (аргументы например, но не имена) оно будет работать просто не так как надо (но при этом все соберется и слинкуется).
А вот Go понимает сишные хедеры и биндинг там в общем то можно и не писать. Если сигнатуры поменяются — то будет ошибка компиляции с явным тычком носа в те места где сигнатуры не совпадают.
Плодить threads им запрещено, ибо явным образом выставлено GOMAXPROCS=1 :-)
Я правильно понимаю, что для моделирования ситуации достаточно написать http-сервер который всем клиентам сказавшим GET одновременно раздает ну скажем гигабайта по 4 респонза (ну или просто о-очень долго льет 10 кб данных каждому)?
Не, близость к железу вторична (ну то есть хорошо когда она есть (c возможность от оного железа абстрагироваться), но и без нее жить можно во многих случаях).
Хм. Какой-то Rust не настоящий… Вон в том же хаскелле вроде как green threads и без особой поддержки компилятора сделали.
В общем, я укрепился во мнении что Rust до юзабельного состояния если когда-то и дойдет, то точно не в ближайшие год-два. Поэтому я пожалуй буду продолжать упорстовать во грехе и не буду его рассматривать как достойную альтернативу C++ или Go в своих проектах. :-)
Ну, на самом деле Go более низкоуровневый чем C++ :-) Под высотой уровня я подразумеваю возможность создавать пользовательские абстракции, чем возможностей больше — тем уровень выше. У Go с этим явно хуже чем у C++. А у Rust с этим примерно также (где-то лучше где-то хуже) как и у C++.
GC сам по себе на «высоту уровня» не влияет.
А легкие потоки у Rust, как это и положено высокоуровневому языку, находятся в библиотеке: doc.rust-lang.org/0.11.0/green/ (это в низкоуровневых языках подобные вещи приходится вшивать в сам язык, ибо выразить такие абстракции этим языком не представляется возможным).
Эмм… Нет :-) Работают же мои демоны одновременно обслуживая множество соединений (в одном потоке).
Можно более развернутый пример где была бы видна работа этого самого event-loop'a? То есть несколько разных запросов и проч. Я постараюсь аналог накидать на Go. (ну и словесное описание задачи тоже было бы хорошо увидеть)
Писать качественный код и решать проблемы идеоматичным для данного ЯП способом можно и на фортране-77 (и такого кода написано МНОГО). Да и на коболе тоже в общем то можно. Вопрос лишь в том, сколько усилий придется для этого приложить.
Использовать interface{} мне приходится к сожалению часто (ибо вшитых в язык контейнеров не хватает, а любой библиотечный контейнер работает исключительно через interface{}), что ухудшает самодокументированность кода (вот тут объявлен список, какие элементы будут в него класть? а не ясно!) и увеличивает вероятность ошибки (периодически то тут то там все же сыпятся ошибки приведения типов из interface{}, в том числе в сторонних либах, увы).
А в Go этот код будет просто в самой Goрутине (при этом потоков новых плодиться не будет — это ж горутина).
PS. Немного тупой вопрос, но на всякий случай, чтобы до конца понимать что делает приведенный выше код — чем это отличается от обычного синхронного тупого кода на си, где http_client_fetch будет обычным блокирующим вызовом? Я же правильно понимаю, что эти две строчки будут, грубо говоря, в main'e?
ну, Rust тоже как бы метит на легкую асинхронщину и даже на легкую многопоточность. При этом он вроде как будет даже более высокоуровневым нежели С++, не то что Go. Но у Rust беда одна — его нельзя использовать до сих пор :-) Собственно даже D использовать нужно с большой опаской и оглядкой. А вот Go вполне себе стабилен и при этом, по совокупности показателей, весьма удобен.
Для асинхронщины в Go есть да, goroutine + каналы, больше ничего и не нужно (если вдруг чего-то не хватает — интересно было бы послушать чего именно). Это конечно не так здорово как потоки в erlang'e, но в принципе достаточно.
Если бы я больше предпочитал динамическую типизация, вероятно я взял бы python (но подозреваю что в этом случае я бы проиграл в плане производительности ну и интерпретатор со всеми либами пришлось бы с собой таскать).
А так да, для нашего случая (для этой конкретной части проекта) наилучшим решением оказался Go.
Очень надеюсь что они не закроются (вроде бы были когда-то другие коворкинги в НН, но все позакрывались/разорились).
Да, при этом у нас процесс должен быть один и поток должен быть один.
PS. Весьма жаль, что эта новость про IoT в НН дошла до меня только сейчас.
У нас код тех самых демонов в основном написан на Го но там есть вкрапления на Си- оно все абсолютно бесшовно собирается целиком в единый исполняемый файл.
За это я лично Go и ценю (кроме всего прочего). Собственно даже яблочный Swift работает с Си намного более геморройным образом.
А вот Go понимает сишные хедеры и биндинг там в общем то можно и не писать. Если сигнатуры поменяются — то будет ошибка компиляции с явным тычком носа в те места где сигнатуры не совпадают.
Я правильно понимаю, что для моделирования ситуации достаточно написать http-сервер который всем клиентам сказавшим GET одновременно раздает ну скажем гигабайта по 4 респонза (ну или просто о-очень долго льет 10 кб данных каждому)?
Хм. Какой-то Rust не настоящий… Вон в том же хаскелле вроде как green threads и без особой поддержки компилятора сделали.
В общем, я укрепился во мнении что Rust до юзабельного состояния если когда-то и дойдет, то точно не в ближайшие год-два. Поэтому я пожалуй буду продолжать упорстовать во грехе и не буду его рассматривать как достойную альтернативу C++ или Go в своих проектах. :-)
Про Crystal первый раз слышу — что у него с пониманием сишных хедеров?
PS. У бинарника который получается у Go зависимостей нет вовсе. Он всебя статически влинковывает все что нужно и это довольно удобно.
GC сам по себе на «высоту уровня» не влияет.
А легкие потоки у Rust, как это и положено высокоуровневому языку, находятся в библиотеке: doc.rust-lang.org/0.11.0/green/ (это в низкоуровневых языках подобные вещи приходится вшивать в сам язык, ибо выразить такие абстракции этим языком не представляется возможным).
Можно более развернутый пример где была бы видна работа этого самого event-loop'a? То есть несколько разных запросов и проч. Я постараюсь аналог накидать на Go. (ну и словесное описание задачи тоже было бы хорошо увидеть)
Использовать interface{} мне приходится к сожалению часто (ибо вшитых в язык контейнеров не хватает, а любой библиотечный контейнер работает исключительно через interface{}), что ухудшает самодокументированность кода (вот тут объявлен список, какие элементы будут в него класть? а не ясно!) и увеличивает вероятность ошибки (периодически то тут то там все же сыпятся ошибки приведения типов из interface{}, в том числе в сторонних либах, увы).
А в Go этот код будет просто в самой Goрутине (при этом потоков новых плодиться не будет — это ж горутина).
PS. Немного тупой вопрос, но на всякий случай, чтобы до конца понимать что делает приведенный выше код — чем это отличается от обычного синхронного тупого кода на си, где http_client_fetch будет обычным блокирующим вызовом? Я же правильно понимаю, что эти две строчки будут, грубо говоря, в main'e?
Для асинхронщины в Go есть да, goroutine + каналы, больше ничего и не нужно (если вдруг чего-то не хватает — интересно было бы послушать чего именно). Это конечно не так здорово как потоки в erlang'e, но в принципе достаточно.
Если бы я больше предпочитал динамическую типизация, вероятно я взял бы python (но подозреваю что в этом случае я бы проиграл в плане производительности ну и интерпретатор со всеми либами пришлось бы с собой таскать).
А так да, для нашего случая (для этой конкретной части проекта) наилучшим решением оказался Go.