Да

да ты айтишник, бинарная логика в порядке))

я тут вас почитал, пока докеры разворачивались, и вот что подумал

завтра пятница, а это хороший повод выпить!

стоп

сегодня пятница???

как

Сегодня да

Сегодня в Питере митап эмбедщиков

эмбед хорошо, интересно посмотреть какие сейчас там тренды. а с piterpy видосов так и нет

https://www.zephyrproject.org/

о, знакомые лица

Говорят, срачик здесь

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

Пиздят как дышат

Смищно

Даже я знаю слова "connection pooler"

вот и я чёт так подумал.

Он там штатный вполне заебись работает

не будем им рассказывать?

Не стоит

Не, зачем

Не надо

давеча тут один чел утверждал что руби в 3 раза медленее питона, откуда они это берут?

это нормально. у них в паспорте дата совпадает с выходом первого альбома группы демо.

там всё хорошо

один с пеной у рта мне доказывал что си быстрее питона. на моё: "да. и что?" он сказал: "вот! и всё!"

железно, чо %)

ну так то руби действительно медленнее и питона и пхп

вот здесь какие-то чуваки регулярно делают тесты на перфоманс: http://benchmarksgame.alioth.debian.org/

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

но не в 3 раза)

ну в 3 раза - это не так много, на самом деле

а у них руби откомпелённый или из бинарников?

и опять-таки, что сравнивать. какие-то вещи может и в 3 раза. это же все от задачи зависит

да вот оно, да https://benchmarksgame.alioth.debian.org/u64q/ruby.html

в среднем там от 20% до 70% где-то отставание от питона

там пхп в лидерах. чем я был сильно удивлен. быстрее питона и руби

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

все приуныли чето. 10 минут прошло уже, а какашками никто не закидал еще :)

обед. рано какашками кидаться

вот после....

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

советую почитать о грядущем ruby 3.0

ну если они что-то из этого реализуют, то будет круто, безусловно: http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3

а пока что только очевидные вещи говорят. JIT, нормальные потоки и т.д. это и так все понимают, но воз и ныне там :)

обед. рано какашками кидаться

а я ещё трезв... чо там 50 грамм вискаря :(

а пока что только очевидные вещи говорят. JIT, нормальные потоки и т.д. это и так все понимают, но воз и ныне там :)

надеюсь у python дела идут лучше)

вот смотрите

советую почитать о грядущем ruby 3.0

ссыль срочно! хочу третий руби

я же ссылку выше кидал

она на пол экрана должна быть у тебя видна )

> @ad0ne надеюсь у python дела идут лучше) почему? )

что - почему?

почему надеюсь? или почему лучше?

почему надеешься я имею ввиду

что рубистам это даст

я околого года копаюсь в руби и рельсах, сделал три проекта на рельсах, одного бота для телеграмма на рубях, знаю SQL(PosgtreSQL/PostGiS)/ html/css/js/ Vue js/angular немного. чисто коммерческих проектов на руби не было

это был сарказм

я таки джун?

я таки джун?

ты сам себя кем считаешь?

надеюсь у python дела идут лучше)

какая разница, если golang ?

http://get-a-wingman.com/wp-content/uploads/2015/11/was-that-sarcasm.jpg

какая разница, если golang ?

=)

тссс

> знаю SQL(PosgtreSQL/PostGiS) Hash join от nested loops чем отличается?

?

не знаю постгрес, но подзреваю что сложностью алгоритма

А что это за слова такие, вообще

Откуда они

на практике два вложенных цикла это квадратическая сложность

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

> знаю SQL(PosgtreSQL/PostGiS) Hash join от nested loops чем отличается?

хеш join хеш таблицу строит для выборки

а nested loops вложенный цикл

Логично

Казалось бы, причём тут PostgreSQL.

А зачем нужно два алгоритма?

видимо это Результат explain

Казалось бы, причём тут PostgreSQL.

И правда

таки хеш быстрее чем перебор на больших таблицах

таки хеш быстрее чем перебор на больших таблицах

А граничные условия какие?

нужно чтобы хеш индекс был

это оптимизация запросов

нужно чтобы хеш индекс был

Так так

чтобы искало не перебором

Проигрываю.

это оптимизация запросов

Ну - когда хэш джойн плохо?

лучше чем nested loop

чтобы искало не перебором

Не искало

А мэтчило

раз так в N

Ладно, трейд-оф то в чем хэш джойна?

хэш оперативку жрёт это же очевидно

хэш оперативку жрёт это же очевидно

Да

хэш оперативку жрёт это же очевидно

Да там хуйня.

Ну что же

Пожалуй, все вы вместе - не джун