Это как на ассемблере написать игру и на бейсике - скорость в первом случае будет в разы быстрее.Вы не видели код, который пишут "обезьянки одинаковой квалификации". Там такое бывает... Это раз. И заодно это ваше "обезьянки" показывает вашу "причастность и вовлеченность" в сферу, то есть говорит от том что вы в предмете ни в зуб ногой и все свои измышления строите на том что "ассемблер безусловно быстрее бейсика, по этому все надо писать на нем".
Отрицает важность быстродействия языка программирования, когда она неоспорима.Вау, в 21 веке кто-то еще верит в "неоспоримость" чего-либо??? Даже если вам еще нет 20 лет - это самая большая глупость. Банальный пример - калькулятор на визуал бэйсике и на ассемблере - что быстрее и на чем делать правильнее? Ну, как коммерческий продукт?
вместо того чтобы отвечать на вопрос топикстартера уводить его в другое руслоДа вас никто не неволит хвататься за мои, либо еще чьи-то советы и бежать исправлять проблемы там где они есть, вместо того чтобы решать те, которых нет, ради бога... Возможно я даже своими крамольными высказываниями пытаюсь лишить парочку голангеров теплого местечка, а вы им уже обещали... Я привык советовать инструмент под задачу, а не "есть голанг, он быстрый, пофиг что проблема не в коде". Вы бы привели конкретную задачу - ну, типа "есть расчет графа неопределенной вложенности, надо найти самое короткое расстояние между произвольными узлами, пхп делает это медленно, че делать?". Вооот тогдаааа получите максимально верный и четкий ответ, а так создается впечатление что вы даже не знаете в каких местах затык, тупо пытаетесь средствами программной среды покрыть ВСЕ недостатки приложения.
как в случае с авито, то поддержка параллелизма может заметно убыстрять работу приложения относительно языков без данной поддержки.Где-то может дать профит, а где-то нет, а где-то может дать, но это может быть неоправданно по сложности и надежности...
Можете примерный код дать как это автоматизировать ?Что именно? Как str_replace() написать?
баги, связанные с не полностью описанными use casesСкилл дебага +10
Для таких в аду стоит отдельный котёл.))
проблем в течение довольно продолжительного времени быть не должно.поржал от души, дырявое решето с кривой архитектурой и миллиардом плагинов, один другого кривее, но проблем быть не должно... ессстесственно!
Нет. Во первых нифига не по быстрому, во вторых движок в привычном нам сегодня понимании там отсутствовал, изначально все писалось процедурной лапшой, что конечно на тот момент было более "быстрым" кодом. И кроме того - они сохранили стек пхп, при этом поменяли среду исполнения на бинарную, не без потерь в удобстве разработки. Кроме того - почитайте что вынудило их это сделать, и это вовсе не код, а больше вот что-то как тут:
То есть из области - "сам себе хранилище / поиск / кеш", отсюда и тормоза в этих местах, отсюда и необходимость в ускорении всего что шевелится... В нормальных структурах веб приложений ЯП - большей частью прослойка между хранилищем и пользователем, с несложной логикой, вся скорость работы как раз и основана на специально обученных алгоритмах хранения и выборки. Да, есть куски где нужно напрячь электромозги, например ресайз картинок или конвертация видео, но вот это как раз чаще всего можно выделить в отдельные потоки внешним приложениям, причем как раз это суть те же микросервисы с фасадом на пыхе/питоне/етц, существуют мильон лет как. Большинство остальных операций выполняются в разы быстрее чем запросы из базы на 10М строк. Пример обратный ФБ и ВК - букинг.ком. У них до сих пор во многих местах все работает на перле. И норм. Так как в бд все суперзатюнено, местами суперденормализовано и пипец как закешировано. Но вот на перле (на перле, Карл!), и все шустро работает.