Если бы вы сейчас занялись веб-разработкой, то что выбрали бы: Ruby или Go?

А в чем проблема, кстати, написать репл для яп со статической типизацией? В хаскеле, например, есть какое -то говнецо.

Дак и для go давно есть.

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

Поэтому не стоит кричать с пеной у рта что мой ЯП самый лучший :) Лучших нет и никогда не будет.

не стоит кричать с пеной у рта что мой ЯП самый лучший

Да, но тут идет речь про язык, который конвертирует данные из БД в текстовый формат -_-. Тут производительности не только за глаза, но и за уши тоже.

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

Да, но тут идет речь про язык, который конвертирует данные из БД в текстовый формат -_-.

Тогда PHP достаточно. Ничего в этом зазорного нет :)

Да, но тут идет речь про язык, который конвертирует данные из БД в текстовый формат

А вот берем питон и го. Берем ab и тестируем. Пройдет ли тесты питон?

Берем ab

Что есть «ab»?

это утилита типа курла, в которой есть удобный интерфейс определения отклика.

достаточно

Можно быть fast-enough, но нельзя быть выразительным и функциональным -enough

это утилита типа курла

А, точно.

Apache benchmark

Пройдет ли тесты питон?

Т.е. победа в хеловорлд для тебя значима, я понимаю.

Разница между писать на го и питонрм не большая. А производительность оооч большая.

Разница между писать на го и питонрм не большая.

Питон конечно не самый выразительный язык, но хз.

А производительность

Я никогда не видел, чтобы производительность упиралась в обработку результата БД - этого не бывает.

Потому я бы не использовал ни питон, ни го. Я бы использовал максимально выразительный и удобный fast-enough язык.

Ну вот тут же описано же. Если бы вы сейчас занялись веб-разработкой, то что выбрали бы: Ruby или Go? (комментарий)

Потому я бы не использовал ни питон, ни го

Питон просто конфетка в сравнении. Go будто специально сделали максимально топорным. Ну это можно понять, но синтаксис зачем такой вырвиглазный? Хотя многим нравится, может это я что-то не догоняю. Меня уже один только fmt.Println вогнал в тоску и демотивировал.

Я бы выбрал Python.

Но это ведь очевидная чушь. Очевидная потому, что мы знаем очень высоконагруженные проекты и на руби, и на питоне, и даже на пхп.
А объясняется все просто: узкое место всегда БД, особенно в высоконагруженном проекте (где нужно 50 серверов). И никакой единственный сервер на го здесь не поможет.

Вот смотри на сколько это очевидно.
Предположим го быстрее руби в 10 раз. Го выполнит метод за 0.001с, руби за 0.01с, а бд они оба будут ждать 0.5с (или 1с, или 4с). И где разница? Зато с го будешь месяц трахаться, а на руби за пару дней запилишь. Вот и весь выбор.

Я бы Go, ибо компилируемость, скорость исполнения. Руби уже надоел.

Предположим го быстрее руби в 10 раз

Go быстрее Ruby в ~50 раз, кроме того в Go встроенные горутины которые позволяют не занимать треды во время ожиданий БД, внешних сервисов и всего что в сети. Как видишь разница - огромная. Один Application Server на Go покроет 30-50 на твоих Ruby.

Горутин можно породить миллионы, сколько тредов в Ruby ты можешь иметь? вот тебе и ответ.

++ памяти жрет в десятки раз меньше, так что Ruby это такое же legacy как PHP, а новые проекты надо делать на новых технологиях которые дают новые плюшки.

Go
В нем нет классов, наследования и традиционного полиморфизма.

как на таком языке можно писать что то сложней хелловорда?

сколько тредов в Ruby ты можешь иметь

не знаю руби, просто интересуюсь: а разве там нет сопрограмм?

не знаю руби, просто интересуюсь: а разве там нет сопрограмм?

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

как на таком языке можно писать что то сложней хелловорда?

слишком толсто, посмотри на ядро линукса, C еще более беден.

посмотри на ядро линукса

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

Мне лень тебе давать ссылку на гитхаб, где ты можешь ознакомиться с продуктами/решениями на Go которые сложнее хелловорда

html5

горутины

В руби есть фиберы, прикинь.

Go быстрее Ruby в ~50 раз

Выводит надпись хеловорлд - это да.

В руби есть фиберы, прикинь.

что суть есть тред, который она занимает

нет

Выводит надпись хеловорлд - это да.

любые операции - это да.

Fibers are not actors and Ruby doesn’t have a native Actor model implementation but some people wrote some actor libs on top of fibers. A fiber is like a simplified thread which isn’t scheduled by the VM but by the programmer. Fibers are like blocks which can be paused and resumed from the outside of from within themselves. Fibers are faster and use less memory than threads as demonstrated in this blog post. However, because of the GIL, you still cannot truly run more than one concurrent fiber by thread and if you want to use multiple CPU cores, you will need to run fibers within more than one thread. So how do fibers help with concurrency? The answer is that they are part of a bigger solution. Fiber allow developers to manually control the scheduling of “concurrent” code but also to have the code within the fiber to auto schedule itself.

что нет?

а, еще и GIL == уг.

Фиберы это те же твои горутины. Вот тебе картинка их 2010г.

http://image.slidesharecdn.com/oscon-2010-100722164157-phpapp01/95/no-callbac...

It's the same as Threads, really. MRI implements Threads itself, YARV implements them as POSIX/Windows Threads, JRuby implements them as JVM Threads, IronRuby implements them as CLI Threads. Rubinius originally implemented them itself and later switched to implementing them as POSIX/Windows Threads.

Fiber's тебе рулить надо, CSP это с шедулером. Ну ты второй вариант не пробовал никогда, поэтому не понимаешь в чем разница.

Fiber's тебе рулить надо

Что значит мне. Я заюзаю либу, так, что все это будет выглядеть как обычный линейный код.

ну заюзай либу на рельсы, что бы все операции через fibers производились.

А ну да, не сможешь, там же на каждый реквест свой воркер.

Поэтому ни скорости от Go, ни легкости в порождении миллиона коннектов ты не получишь.

rack-fiber_pool она называется.

EventMachine-based server (e.g. thin or rainbows)

Если бы вы сейчас занялись веб-разработкой, то что выбрали бы: Ruby или Go? (комментарий)

библиотек вокруг нее с гулькин нос

С гулькин нос руби - это сколько в масштабах го? ^_-
Примерно больше некуда?

Выводит надпись хеловорлд - это да

Ну толсто уже. Языки разные. Разработка на Go возможно не будет такой быстрой как на вашем Ruby/Rails, но профит от статической типизации будет виден сразу.

Что будет на вашем Ruby если вы забыли написать юнит-тест на какой-то кусок кода ? Этот кусок тащится в продакшен и даст о себе знать через пару месяцев. А потом начинается неделя «приятного» дебага.

Что мы имеем на Golang ? Компилятор на этапе сборки проекта поведает нам о 90% возможных ошибок. И это хорошо. Переменную объявили и не используем, ошибка. И это тоже хорошо.

Я не говорою что в проектах на golang писать юнит-тесты не надо, надо. Но в руби проектах это просто жутко необходимо.

Потом в Ruby есть GIL. И это причина всех бед. Автор языка хоть и пытается его выпилить но ничего не получается. Это факт.

Смотрим далее, большинство рубистов тоже не дураки, и как я сейчас часто слышу переписывают некоторые части проектов на golang. Это тоже факт.

Далее. Я постоянно читаю как рубисты бьются головой об стену при апдейте рельс и сопутствующих библиотек. За уже 1.5 года активной разработки на golang проектов различного масштаба я такого не встречал. Это тоже факт.

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

В итоге грамотный инженер для нового проекта будет выбирать более стабильно разивающийся язык и экосистему. Все мы знаем что закон Мура уже не действует. Тактовая частота процессоров не растет. Отсюда современные приложения просто обязаны нормально работать на многоядерных архитектурах. И нам нужен язык где бы мы очень легко и просто могли работать с потоками и прочим. На горизонте видим Erlang, Java и Golang. Про Rust не знаю что у него там. Дальше думайте сами.

И да монолитность бинарников на golang несомненный плюс. Нам не нужно устраивать танцы с бубном по установке интерпретаторов и библиотек к ним. Я беру бинарник и просто запускаю на сервере. Ну а если и docker есть то жизнь просто сказка.

Ах да, совсем забыл. Железо сейчас дешевое, но все же. Я не хочу чтобы hello world приложение у меня кушало 300 Мб памяти просто так. Это привет тебе Ruby. Твои запросы стали уровня Java. Но если от нее хотя бы есть несомненный профит, то от тебя его увы неприлично мало.

Как то так.

Java.

Компилятор на этапе сборки проекта поведает нам о 90% возможных ошибок.

Ошибки несоответствия типам - это не 90% ошибок. Эти ошибки вообще редко встречаются, и не долго правятся.
Иначе говоря все это не за чем. Своего рода суеверие в мире программистов, мол если типизация соблюдена - значит программа работает верно, ага..

Go быстрее Ruby в ~50 раз ... памяти жрет в десятки раз меньше

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

А объясняется все просто: узкое место всегда БД, особенно в высоконагруженном проекте.

Уоу. А веб это всегда только темплейты, переливание в БД, или отдача статики?

Я вот участвовал в создании сервиса, который хитро обрабатывал картиночки с котиками. Так там и вовсе ни о какой БД, как основном потребителе, речь и не шла. Как думаешь, кто быстрее и дешевле ворочал пиксели, и при этом еще и экономя память, рубины или го? И таких примеров я могу назвать достаточно.

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

А веб это всегда только темплейты, переливание в БД, или отдача статики?

Да.

рубины или го?

си?

Но зачем тогда уже биндинги, когда ты можешь на одном языке сделать всё эффективно (при весьма широком классе задач), и без лютых оверхэдов?

Отвратительная архитектура.
Веб-приложение должно состоять из небольших сервисов.

У нас сейчас пишут сервис распознавания документов, пишут на c++, делая биндинги к питону, встраивая сервисом в общую систему. Предлагаешь делать биндинги к го ^_-

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

Зачем для ворочанья пикселей(байтодроч) взяли язык с гц? Поди си и сипипи имеют библиотеки нужные и скорость выше

А мне казалось стартапам важнее быстрее выкатить продукт, занять нишу. Если бы фейсбук пилили из расчета максимальная производительность а не быть первыми, то не было бы щас фейсбука.

https://news.ycombinator.com/item?id=10135825

Закатывайте этот Elixir обратно. Ну это же смешно.

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

Причем тут golang, если этим занимается IDE ? К слову Emacs c go-mode отлично все показывает.

Уже занимаюсь. Выбрали Ruby, не я выбирал, но пока не жалеем.