Go for IT. Часть первая

Это вы на чистом Гоу библиотеки написали, а есть ещё биндинги: go-lang.cat-v.org/library-bindings
Там и мой, кстати, есть. Биндинг к GD.

И godashboard.appspot.com/

Еще пример — я долго пользовался sr, а потом написал goreplace поиграться и потому, что питон бегает по диску и матчит файлы регекспами в 5 (в среднем) раз медленнее.

О, знакомый аватар! Забавная штука выходит: когда-то зафолловил ваш твиттер, «чтобы не забыть», но это касалось питона и js, а теперь опять в круге моего интереса — Go. Погляжу как goreplace написан, на первый взгляд недурный код:)

Минусы за что не знаю, но предположу, что ваш комментарий восприняли за своеобразный троллинг или стёб. Как фразу «а чего бы не изобрести до кучи и карманный стеллар-конвертор»?

Если по сути, то весьма затруднительно трансляция кода PHP в GO — у языков слишком разные архитектура и подходы к решению задач. В лучшем случае вы получите код того же качества, какой получается при переводе книги Google Translate. И правка займёт времени больше, чем переписывание того же кода с нуля и ручками.

Просто для примера. В PHP динамическая типизация, а в Go — строгая. И это лишь первый камень. Кроме того вы забываете о том, в каком мире мы живём. Никого на рынке особо не волнуют проблемы отстающих. Если у нас в руках есть инструмент, обеспечивающий преимущество, то зачем нам плодить себе конкурентов, упрощая им вход в сегмент?

Django показатель скорости разработки сайтов на ней)))

Честно говоря у меня руки чесались написать код вебсервера и роутера на пайтоне исключительно используя built-in. Но к своему стыду я совершенно забыл как это делается. Поэтому и взял paste с минимальной надстройкой — вряд ли кто-либо из питонистов усомнится в зрелости этого проекта или заподозрит Ian Bicking в криворукости :)

Хотя заюзан webapp2. Надо попробовать tornado например.

Тоже ломаю голову и мучаю Golang-nuts. Хотя в реальной ситуации с такими нагрузками встречаться почти не приходится, всё же хочется большей предсказуемости.

И спасибо за участие.

http {

   tcp_nodelay  on;
   accept_mutex off;
   access_log   off;

   server {
        location ~ ^/(.+)$ {
           return 200 "Hello, $1!";
        }
   }
}

И сменить ab на что-нибудь другое. Медленный ab с вышеприведенным конфигом легко станет узким местом.

Вряд ли проблема в сборщике мусора. Скорее в планировщике.

Кстати, я недавно делал статью о производительности горутин. И в качестве вывода могу сказать, что выделение очень быстрой функции (например если она работает быстрее чем 10-кратное вычисление sqrt(13)) при GOMAXPROCS > 1 действительно снижает производительность.

По крайней мере, в определениях функций / блоков кода фигурных скобок там нет, а это уже существенно.

Регулярка ничего не меняет, но вы не поняли меня.

from gevent import http
import re
root = re.compile('^/$')

def callback(request):
    if root.match(request.uri):
        request.add_output_header('Content-Type', 'text/html')
        request.send_reply(200, "OK", '<b>hello world</b>')
    else:
        request.add_output_header('Content-Type', 'text/html')
        request.send_reply(404, "Not Found", "<h1>Not Found</h1>")

print 'Serving on 8088...'
http.HTTPServer(('0.0.0.0', 8088), callback).serve_forever()

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

Поэтому и предлагаю продолжить на более серьезном материале — вы подаете статью, а я пытаюсь побить Go на python :) Будет весело.

нет, не тоже самое

Porsche — это Запорожец + реактивный двигатель?

MySql и Sphinx, Apache и nginx

Кота и камень, апельсин и мандарин?
По-поводу

GO разве не тоже самое, что PHP + Zend?

Совсем не понял.
И, да. Питону тыщу лет, руби не нравится синтаксисом, Java нравится, но писать на ней вебаппы нед сил, так что Go для меня оптимальный выбор. Молодой, шустрый с красивым синтаксисом. Тыкаю палочкой его уже пару недель, думаю о том где бы выгоднее применить.

Я с недавних пор хочу себе сервис, являющийся универсальным оповещателем. Например, существует много способов получения контента:
1) Зайти на сайт и посмотреть, нет ли чего новенького.
2) RSS.
3) Twitter.
4) Email.
…
Следить за всем этим многообразием тяжело, и даже если удастся собрать себе подборку того, что действительно полезно — то нужно все равно проверять N источников каждый день (заходить на почту, в RSS-ридер, в Twitter и на некоторые сайты).
Хотелось бы сервис, который позволял бы настраивать «маршруты» оповещения о новом контенте, например:
1) Если на сайте NNN.com появилась новая статья — запостить в твиттер новую запись.
2) Если в заданном RSS появилась новая запись — прислать мне email.
3) Создать RSS ленту из записей заданного твиттера.
И т.п. Таким образом человек может проверять одно место на выбор (создать себе twitter-аккаунт, за которым следить, завести отдельную почту или проверять одну RSS-ленту), в котором будет собрана вся интересующая его информация (по крайней мере ссылки на нее).
Не знаю правда, на сколько интересен данный сервис может быть для всех остальных. Но нагрузку он должен генерировать сам по себе очень неплохую (постоянный pulling). Ну и масштабируемую архитектуру тут несложно придумать и реализовать.

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

А Go позиционируется чисто как серверный язык? А то странно получается — есть Google, у него есть ОС, есть ЯП, но этот ЯП в этой ОС не используется.

Ну, про Gentoo/Arch я упомянул в заботе о более продвинутых хаброюзерах чем я. У меня Ubuntu на десктопе и Debian на сервере. Про deb пакеты со всеми зависимостями я даже не заикаюсь (это был бы вообще идеал), но очень бы хотелось избежать компиляции на сервере и какой-то инструмент получения зависимостей (названия-версии либ и т. п.), чтобы на сервер можно было бы ставить только рантайм, скомпилированный на другой машине (на крайний случай можно виртуалку с целевой ОС поднять), без компилятора.

Честно говоря, не ожидал другого ответа. Одна риторика с привкусом маркетинга и ничего по существу. Разумеется для разного типа задач или вследствие сложившейся практики, нужны разные языки — для расчетов фортран, для системного программирования С/С++, в банках COBOL и т.д. Любой проффесиональный разработчик со стажем обычно владеет палитрой языков и освоение нового языка — не большая проблема. Проблема возникает, когда новичкам, подсовывают проприетарные разработки, до того как они (новички) получают кругозор на базе накопленного сообществом опыта. Возникает не только вопрос зачем но и кому это нужно. Например кому было нужно изучение MFC? Или J#? И где теперь асы этой чудо технологии? А по поводу создателей языка — зачем они это сделали вопрос 10й, вы же не зовете нас ставить Plan 9 в качестве ОС? И должны ли мы сказать спасибо за UTF-8? Вопрос, когда у языка будет стандарт и кто будет за него отвечать.

сорри, за опечатки.

С достаточно высокоуровневыми фреймворками он может, думаю, покуситься и не только на хайлоад, но и на типичные ниши php/python/ruby/java/C# в вебе. Причём, по идее, для выполнения одних и тех же задач на сравнимом уровне абстракции ему потребуется меньше ресурсов (cpu и mem) как для нативно компилируемого языка со статической типизацией, которым никто из «конкурентов» не является.

:) Или написать в блог «Я негодую», литературно оформить своё открытое письмо и собрать подписи. Уверен придут к комментарии многие, чтобы разделить свою злость.

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

Полностью согласен с последним абзацем.
Вообще Абельсон и Сусман выразились по этому поводу.
По поводу Java'ы — она на моей памяти, тоже создавалась как cross платформенный С++, с учетом недостатков С++.

имхо C# писалось MS как свой велосипед и им в итоге и стало.
Ни адекватной кроссплатформенности ни полной скорости C++ в нём не получилось…

Я уже делал пару приложений чисто на nginx + модули и не сказал бы что было долго.

Ничего себе fix :(

Кстати, если почитать внимательно ветку по проблеме, то оказывается, что утечка памяти имеет место быть и на 64-битной ОС

Это issue 909, и пока он не закрыт.

Ничего страшного. Смотрите под другим углом — у какой реализации не бывает проблем с long-live или memory-leaks? Ну и если почитать issue вниимательно, то проблема происходит при определённых условиях, мягко говоря редких для web-dev. Причём это тот самый случай, когда программист использует Go калькой другого языка, не учитывая его специфики.