[s.lobanov]

vop

ну вроде как очевидно, что речь идёт про nohup + &

[Sonne]

GO не рекомендуют запускать демоном самостоятельно. И вообще:

 

Starting processes in unix systems (notably linux, but Mac OS and

FreeBSD also follow this) is fairly simple: fork() and immediately

exec() in the child process. If you do anything but call exec() in the

child process you risk deadlocking your program due to multithreading

interactions. Having a program daemonize itself requires doing stuff

other than plain exec() in the child process.

 

As a result, the classroom "fork, setsid, fork again" algorithm is not

applicable if your program is operating in a multithreaded

environment. Unfortunately, Go pretty much always operates in a

multithreaded environment, because modules can define init() and start

goroutines before your main() executes.

 

The current state of the art in systems like upstart, systemd (linux)

and launchd (Mac OS), is to write your program without daemonizing

features, and assume that the system management software will start

your process already daemonized.

 

In other words, don't include daemonization into your program;

instead, when you're ready to deploy it, configure the system

management daemon (sysvinit, upstart, systemd, launchd, windows

services) to start your program with the correct daemonization

procedure.

[s.lobanov]

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

[Ivan_83]

Я за это java и js и люблю, т.к. почти не задумываюсь о том, где оно потом будет работать (на винде, линуксе или где-то ещё),

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

 

чем уродские #ifdef WIN32 и #ifdef __linux__ . не должно быть это в коде прикладного ПО, всё это должно быть спрятано глубоко в либах

У меня оно так и случилось, почти полностью :)

Только на венду я забил ибо много чего там не будет работать или вообще нет.

 

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

Я некоторые приложения специально делаю однопоточными, ибо смысла в потока нет.

Яркий пример: ssdpd - трудно представить какой должна быть сетка и сколько там должно быть клиентов чтобы положить в полку одно ядро на простой обработке юдп пакетов.

[s.lobanov]

Я за это java и js и люблю, т.к. почти не задумываюсь о том, где оно потом будет работать (на винде, линуксе или где-то ещё),

Действительно, лучше не думать о том как оно греет воздух

 

Да пусть греет. Стоимость разработки и поддержки ПО на низкоуровневых языках в разы дороже стоимости cpu, памяти и электричества.

 

Я понимаю когда речь идёт про адский хайлод аля fb, netflix или что-то ещё, где есть смысл пилить что-то на C, но когда это всего лишь flow collector, то купить сервер помощнее и накодить на js дешевле выйдет. И через 5 лет не придётся думать почему же ссаный код на C не компилится или некорректно работает на каком-нибудь aarch64 под llvm.

 

Телеком это не программирование, телеком это бизнес

[Ivan_83]

Да пусть греет. Стоимость разработки и поддержки ПО на низкоуровневых языках в разы дороже стоимости cpu, памяти и электричества.

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

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

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

 

 

И через 5 лет не придётся думать почему же ссаный код на C не компилится или некорректно работает на каком-нибудь aarch64 под llvm.

Там и думать нечего, всё обычно написано.

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

За всё время было: 16 бит -> 32 бита, 32 бита -> 64 бита и всякие мелкие переезды заголовочников и их содержимого. Это лет за 30. Под вендой ещё юникод доставлял оч долго.

В целом, если код без хаков то проблем не будет или будет самый минимум.

[Sonne]

s.lobanov

 

Полностью согласен!

 

К вопросу о хайлоаде и производительности GO:

 

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

 

Неплохо для вот такой программы, которая проще многих других языков?

 

http.Handle("/", http.FileServer(http.Dir("nginx/html")))

[Sonne]

Да пусть греет. Стоимость разработки и поддержки ПО на низкоуровневых языках в разы дороже стоимости cpu, памяти и электричества.

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

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

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

 

Означает ли это, что писателей демонов на перле надо убивать?

 

Ты критикуешь написание системных программ на языке, который в 2 раза медленнее C, но в 10 раз более быстрый в разработке. И в тоже время пишешь системную программу на языке в сотни раз медленнее C и легендарными возможностями по запутыванию когда? http://forum.nag.ru/forum/index.php?showtopic=64849

 

Не сходится, возможно лишь одно из двух.

[pppoetest]

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

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

[NiTr0]

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

 

Неплохо для вот такой программы, которая проще многих других языков?

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

[pavel.odintsov]

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

 

Неплохо для вот такой программы, которая проще многих других языков?

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

 

Реалия мира такова, что 99% фич Nginx людям обычно нахрен не нужны. А сделать легкий и удобный веб-сервер Go позволяет с легкостью. Мне не нужны его ACL, рейт лимитеры, парсеры хидеров, анализаторы куки и еще 100500 прочего хлама. Мне нужно просто глянуть в Редис и отдать файл. Go решит эту задачу как говорится with flying colors. А с тем же Nginx дружить Redis затрахаешься. Да еще в итоге оно тормозить_будет_адово.

 

Да пусть греет. Стоимость разработки и поддержки ПО на низкоуровневых языках в разы дороже стоимости cpu, памяти и электричества.

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

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

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

 

Означает ли это, что писателей демонов на перле надо убивать?

 

Ты критикуешь написание системных программ на языке, который в 2 раза медленнее C, но в 10 раз более быстрый в разработке. И в тоже время пишешь системную программу на языке в сотни раз медленнее C и легендарными возможностями по запутыванию когда? http://forum.nag.ru/forum/index.php?showtopic=64849

 

Не сходится, возможно лишь одно из двух.

 

 

Все же не стоит путать Perl и NodeJS. Если первому уже за второй десяток лет и он есть в любом дистрибутиве unix/linux/freebsd и черт еще пойми чего и стабилен как камень. Тот же NodeJS - я лично собирать тупо не буду, потому что ни в одном дистрибутиве его нету (либо есть, но версии времен СССР). Мало того, оно постоянно меняется (сколько там раз уже разработчики поссорились?).

 

А Перл воткнул и оно работает. Как и баш и тот же питон (2й версии, ессна).

Изменено 25 февраля, 2016 пользователем pavel.odintsov

[NiTr0]

Реалия мира такова, что 99% фич Nginx людям обычно нахрен не нужны.

мультидоменность, url rewriting, per-IP ACL - не нужны?... вы вообще для чего веб-сервер используете? для одной странички-затычки что ли? :)

[pavel.odintsov]

Реалия мира такова, что 99% фич Nginx людям обычно нахрен не нужны.

мультидоменность, url rewriting, per-IP ACL - не нужны?... вы вообще для чего веб-сервер используете? для одной странички-затычки что ли? :)

 

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

[Ivan_83]

Сравнение стандартной библиотеки GO и уникально оптимизированного веб сервера Nginx на голых Cях показывает, что GO все го лишь в 2 раза медленее. Неплохо для вот такой программы, которая проще многих других языков?

Сравнение не корректное: у nginx полная обвязка на все случаи жизни а у ГО один страничка отдаваемый статически. В таком режим непосредственно ГО кода там кот наплакал, наверняка тот же хттп парсер сишный где то в кишках.

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

 

Означает ли это, что писателей демонов на перле надо убивать?

В целом да, но есть исключения :)

 

Ты критикуешь написание системных программ на языке, который в 2 раза медленнее C, но в 10 раз более быстрый в разработке. И в тоже время пишешь системную программу на языке в сотни раз медленнее C и легендарными возможностями по запутыванию когда? http://forum.nag.ru/...showtopic=64849

Я уже 100500 раз писал почему перл:

- потому что 99% времени демон тупо спит в recvfrom()

- потому что там основной тормоз работа с БД - именно сама бд

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

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

С тех пор я на перле ничего не писал, а до писал только fcgi прокладку/демона чтобы nginx мог перловые скрипты вызывать, как это умеет lighttpd.

 

 

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

SSDPd - вот именно благодаря nginx мне удалось не встраивать свой собственный веб сервер для обработки специфичных http-upnp запросов, я просто нарисовал всё что нужно в конфиге.

Писать плагины под nginx я не пробовал, но по виду сложного там ничего нет, всё уже давно вылизано, и поэтому левых плагинов овердохрена.

[vop]

Поискал у себя в коде #ifdef __linux__ и другую ерунду... Не нашел. Хмм... :) Неужели не знал о такой ахренительной фишке? :)

 

Да пусть греет. Стоимость разработки и поддержки ПО на низкоуровневых языках в разы дороже стоимости cpu, памяти и электричества.

 

А что по поводу стоимости рабочего времени, убитого на разбирательства, почему сопливый билинг на 1000 персон убивает сервер с 8 камнями и с 16 гигабузов памяти за три дня? :)

 

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

 

Подтверждаю - написанное на C работает лет 20.

[Sonne]

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

 

Неплохо для вот такой программы, которая проще многих других языков?

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

 

Ну для начала попробуйте на Nginx написать например ... коллектор netflow. А что? Вот так в легкую сравниваем язык програмировани и веб-сервер.

[pavel.odintsov]

Вместо холивара предлагаю потратить время с пользой и присоединиться удаленно хотя бы к конференции https://events.yandex.ru/events/cpp-party/25-feb-2016/ =)

[NiTr0]

Ну для начала попробуйте на Nginx написать например ... коллектор netflow. А что? Вот так в легкую сравниваем язык програмировани и веб-сервер.

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

[Sonne]

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

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

 

Perl way это когда абсолютно любую вещь можно сделать несколькими способами. Хотя, конечно он довольно структурирован в своей куче возможностей. Но именно Перл дает людям безграничную свободу, в том числе и возможность достич безграничного извращения.

 

Ну для начала попробуйте на Nginx написать например ... коллектор netflow. А что? Вот так в легкую сравниваем язык програмировани и веб-сервер.

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

 

Я надеюсь полегчало теперь? Потому что когда из человека столько выливается, внутри должно становиться легче :)

[Ivan_83]

Ещё одно.

Как распространяются го программы?

Исходник с инструкцией по сборке? - тогда придётся тянуть ещё и компелятор.

Бинарник - нах он сдался, мало ли какой там в лучшем случае говнокод.

 

С си относительно стандартно всё: стандартный набор для сборки приложений и инструкция на 3-5 строчек по сборке.

Перл просто ррррррраз и поехало. :)

 

 

Я надеюсь полегчало теперь? Потому что когда из человека столько выливается, внутри должно становиться легче :)

А не надо перед этим туда заливать :)

[Sonne]

Ещё одно.

Как распространяются го программы?

Исходник с инструкцией по сборке? - тогда придётся тянуть ещё и компелятор.

Бинарник - нах он сдался, мало ли какой там в лучшем случае говнокод.

 

Это же компилируемый язык. Значит нужен компилятор. Кстати в крайнем Дебиане (самый консервативный дистрибутив в линуксах IMHO) идет относительно свежий GO 1.3

 

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

 

С си относительно стандартно всё: стандартный набор для сборки приложений и инструкция на 3-5 строчек по сборке.

Перл просто ррррррраз и поехало. :)

Go точно так же. Сравни.

perl myscript.pl

go run myprog.go

 

На целое слово больше писать. Компиляция происходит быстрее, чем запускаются интерпретаторы скриптовых языков. И это тоже осознанное решение :) Компилятор еще до запуска вынесет мозг с проверкой и преобразованием типов. Зато после запуска программа сразу работает.

 

А 3-5 строчек приходится писать при работе с тулчейном, чтобы скомпилировать бинарник на любую архитектуру. Я, например, когда нибудь хочу написать агенты для системы мониторинга для mips роутеров. Даже не представляю как это сделать на perl или node.js

[s.lobanov]

вопрос удобности инсталляции/запуска это относится либо к очень сложному ПО (громоздким CRM, системам управления сетью и т.п.), либо к ненужному shareware/freeware(non-opensource)-шлаку типа всяких видеоконверторов, блокнотов, калькуляторов

 

кому нужен netflow-коллектор и вариантов 1-2 - поставит себе Go нужной версии или perl или node.js или на чём оно будет написано

[SyJet]

Ещё одно.

Как распространяются го программы?

Исходник с инструкцией по сборке? - тогда придётся тянуть ещё и компелятор.

Бинарник - нах он сдался, мало ли какой там в лучшем случае говнокод.

 

Это же компилируемый язык. Значит нужен компилятор. Кстати в крайнем Дебиане (самый консервативный дистрибутив в линуксах IMHO) идет относительно свежий GO 1.3

 

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

 

С си относительно стандартно всё: стандартный набор для сборки приложений и инструкция на 3-5 строчек по сборке.

Перл просто ррррррраз и поехало. :)

Go точно так же. Сравни.

perl myscript.pl

go run myprog.go

 

На целое слово больше писать. Компиляция происходит быстрее, чем запускаются интерпретаторы скриптовых языков. И это тоже осознанное решение :) Компилятор еще до запуска вынесет мозг с проверкой и преобразованием типов. Зато после запуска программа сразу работает.

 

А 3-5 строчек приходится писать при работе с тулчейном, чтобы скомпилировать бинарник на любую архитектуру. Я, например, когда нибудь хочу написать агенты для системы мониторинга для mips роутеров. Даже не представляю как это сделать на perl или node.js

На powerpc perl есть однозначно, а вот на mips - не в курсе.

[s.lobanov]

SyJet

Да почти всё "стандартное" и "популярное" ПО есть под mips, что есть в других дистрах. https://packages.debian.org/search?arch=mips&keywords=perl

[NiTr0]

На powerpc perl есть однозначно, а вот на mips - не в курсе.

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