Встал совершенно странный вопрос, выбора бюджетной платформы для разработки веб приложение на VPS-сервере. Пока облачные маркетологи заливают радугу в уши пользователей, VPS-решения до сих пор остается самым дешевым и бюджетным способом реализовать «сайт на коленке». И несмотря на то, что в многих головах - память «стала очень дешевая» и «экономить на ней не имеет смысла», в действительности в бюджетной среде виртуальных серверов этот вопрос остается важен и тут статично типизированные языки должны нам помочь (в отличие от скриптовых собратьев, которые и так жрут тучу памяти, да еще и клонируются по процессам). И так поехали:GolangМне показалось жрет значительно меньше ОЗУ и в целом нет никакой виртуальной машины (что дополнительное ОЗУ). Компиляция в бинарник со всеми зависимостями (да и сам бинарник это плюс). Асинхронное программирование под капотом, пишешь как обычно и сразу все асинхронно и нет никаких бестолочных калбэков, промиссов или асинков (или упаси такой бред мозга, как реактивное программирование). Ну и конечно возможность писать процедурный код со структурами с небольшими возможностями работы с объектами, то есть никакого поражения ООП мозга (алгоритмы отдельно, данные отдельно). Язык созданный чисто под веб (где радует своими батарейками для этого), в отличие от котлина, где начиная гуглить попадаешь в какой-то андроид ад. Нет какой-то привязки к одной IDE. Библиотеки чаще представляют решения какой-то одной задачи, а не попытку сделать из всего фреймворк (не щадя память, ведь в кровавом она не важна)KotlinДженерики. Наследие джавы и миллион готовых решений (чаще продуманных и не редко кривых, но все же их очень много, это плюс). Так же есть устоявшиеся стандарты в либах (например логер, менеджер зависимостей), в общем, огромнейшая инфраструктура. Более приятный синтаксис, хотя го настолько печален, что тут даже у джавы дизайн синтаксиса по-лучше будет (хотя местами котлин то же вызывает WTF-эффект, но все же разработка под всем этим удобнее). Мне думается, чисто субъективно, jvm производительнее и имеет кучу рычагов чтобы поиграть с этой производительностью, для каждого приложения индивидуально. У джавы более адекватное сообщество (хоть иногда с поражением мозга спрингом), а вот у котлина беда какая-то (из-за засилья андроид-малолеток, которые просто оккупировали его, как в свое время в веб в php).
>>1135408 (OP)PHPHP/thread
Ты уже создал этот тред на Лоре, пиздуй туды, на дваче нет 'экспертов
>>1135435Лучше скажи где еще есть живые ИТ-форумы
>>1135445Да нет толком, сейчас уже все загибается, хз может как в соц сетях сидят. На дваче плохо относятся к go и котлин.По сути , в чем лучше разбираешься , на том и пишешь а остальное все холивары от лукавого , везде есть плюсы и минусы. Вон на лоре уже чел писал , что спринг бут много оперативки живет и уже на бюджетный сервер 512 не запилить а go будет норм летать, но и кода придется больше писать, т.к на Go нет фреймворков
>>1135455эээ... Linux Org загибается?)
>>1135408 (OP)Совсем ебнулся? Пайтон\руби\нода. /thread, блядь, ебанутый.
>>1135408 (OP)Стоимость vps - кроха по сравнению со стоимостью разработки.> Golang> ПлюсыВ большинстве своём это его минусы.> Kotlin/Java> ПлюсыПеречисленные плюсы они являются оными только в руках компетентных спецов, стоимость месяца работы которых больше, чем ты вложишь в vps за всю жизнь проекта.Писать надо чём умеешь/хочешь научиться.
>>1135483Если речь идет о бюджетном VPS, значит автор сознательно хочет сэкономить на обслуживание - да?!Что вы все как одни кричите "разработка дороже, время программиста дороже!!! Память дешевая" Откуда вы этого вообще набрались?? Кто вас этому там учит??Я напишу приложение за 2-4 недели, а потом мое время кодинга там будет минимально (почти не будет), а вот за железо я буду платить каждый месяц. И если проект мне приносит 200$ я же не хочу на него тратить 150$, потому что "время разработчика дороже и память ненужна".
Rust/thread
>>1135408 (OP)Если хоститься на VPS, значит скорость приложения неважна. Почему же выбирали из двух неподходящих языков? Дань моде? Идеальный язык для вебприложения - php. Если нужна асинхронность - python.
>>1136070Почему не важна? Не, ну я так то понимаю, просто мне думается у вас какое-то свое предвзятое отношение к VPS (наверное то, что производительность значительно меньше бюджетного дедика)?
>>1135521Кстати, поддвачну вот этого господина. Если есть какой-никакой головной мозг и есть необходимость писать нечто быстрое - то Раст идеален. Го попроще, если нет скиллов - лучше на нем. Котлин - вообще какой-то странный выбор, jvm сожрет свою виртуалку, виртуалки соседей и еще добавки попросит, а пока оно сконпелируется, все дедлайны пройдут. В мире андроида - да, там оно рулит до поры до времени.
>>1140085> Если есть какой-никакой головной мозг и есть необходимость писать нечто быстрое - то Раст идеален.Только для веба он сыроват. Все нормальные фреймворки написаны с использованием макросов 2.0, которые доступны только в ночнушке. Сами разработчики раста обещали допилить их к концу года (кстати тогда же должна выйти оптимизированная 11 жавка с вальгалой).
>>1140085Бизнес логику на расте? Серьезно? Спасибо что не С++Да, jvm и традиционные библиотеки рили могут съест все (это, на самом деле, решает).
>>1140271Ну по условию задачи ОПа-хуя тора-диционные языки типа похапе или пайтона пролетают по производительности, а так, конечно же, лучше на них при прочих равных. Из современных языков подходят Го или Раст, каждый со своими преимуществами и недостатками, там уже от задачи плясать надо. У нас в Авито в последнее время популярный Го вытесняет легендарную похапешечку с бжкенда.
>>1140507>а так, конечно же, лучше на них при прочих равныхБизнес логика на динамикодрисне всегда хуевая идея.
>>1140520Чаще всего это как раз нормальная идея. Дрисня получится или не дрисня - это уже от кривизны рук разработчика зависит.
>>1140085Кстати, хороший критерий на говнокодера - у этих обычно jvm всё отжирает.
>>1140711Это не зависит от кодерских скиллов. Даже если джавист внезапно пряморук - он вынужден обмазываться либами и фреймворками, написанными криворуками. Да и gc в джаве живет своей жизнью.
>>1135445ТостерRSDNStackoverflow на русскомсотни их>>1135408 (OP)> Мне думается, чисто субъективно, jvm производительнее штоблядь
>>1140740Скажем, положительно коррелирует. Потому что говнокодер, as is, в том числе, как лемминг, тащит решения используемые другими леммингами. Даже если это и не нужно для самой задачи. Речь об оверинжениринге и расплате за него.
>>1140751>штоблядьПрогретая jvm (а значит скомпилированная и оптимизированная) выдает результаты на уровне сишки и подобныхhttps://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext В реале отставание от си происходит либо из-за ГЦ (в приложениях где паузы критичная штука) либо где-то только 1,5 раза (что норм, потому что писать бизнес-логику, реальную и большую на С++ это ужасно, но можно конечно). Так что не надо судить по джаве только обмазавшись андроидом, джава в этом примере даже го в 3 раза обгоняет (мы не будем брать во внимание такие огрызки созданные специально для тестов - как fasthttp и rapidoid).Ну то есть, если бы память не решала, я бы конечно обмазался jvm-языками (и может джавой, с норм IDE она годная)
>>1141044>Прогретая jvm (а значит скомпилированная и оптимизированная) выдает результаты на уровне сишки и подобных>джава в этом примере даже го в 3 раза обгоняетЭто не сравнение языков, это сравнение компиляторов и конкретных версий фреймворков/либ и бенчмарков, написанных для них.За 5 минут не нашёл ни одного упоминания компилятора или версии чего-либо, заглянул и на их гитхаб, и в их мануал/доки, нихуя.
>>1141068>это сравнение компиляторовНу вот приехали. Особенно сравнивают компилятор, когда там сравнивают интерпретируемые языки?Это, по-моему, единственное сравнение чего-то рабочего (полноценного какого-то ПО - то есть веб сервера) в условиях где это ПО требует реальной производительности (то есть, авторы должны быть заинтересованы, чтобы сервер был производительным, в отличие, скажем, от десктопного ПО, где можно и забить слегка)>За 5 минут не нашёл ни одного упоминания компилятораЕсли ты за минут не смог сделать 3 клика до макфайла, то что ты делаешь /pr разделе?https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/C/libreactor/Makefile
>>1141116>Ну вот приехали. Особенно сравнивают компилятор, когда там сравнивают интерпретируемые языки?ты подебил>Если ты за минут не смог сделать 3 клика до макфайла, то что ты делаешь /pr разделе?Молодец, ты нашёл, gcc-6 - это 5 версий от .0 до .4 . Теперь найди версию компилятора для всего остального (и нет, я не конкретно о сях-крестах говорил).Скорее всего, они берут из реп:https://www.techempower.com/blog/2018/02/14/framework-benchmarks-round-15/>We are working to update the entire suite to Ubuntu 16 LTSТак, понятно, значит щас там 14 LTS. Открываем список пакетов для 14 LTS:https://packages.ubuntu.com/trusty/devel/Ёбаный насрать, там GCC 4.8.Если ты знаешь, где можно найти эту информацию в виде списка или прямого текста "мы берём компиляторы/интерпретаторы по принципу..." - в студию, искать не хочу. "На уровне или всего в 1,5 раза медленее" - это не совсем "производительнее".Пис.
>>1141151Окей, расскажи нам, что за новую технологию оптимизации завезли в новый GCC и насколько она "рвёт" GCC 4.8??Даже если мы прикрутим 10-20% (что будет чистой ложью), мы все равно увидим, что показатели джавы по прежнему высокие (достаточно высокие и прям упорствовать до первой позиции нам и не нужно, нам нужно получить то, что при достойной разработке - мы получим достойную производительность).То есть, разрабатывать на джаве достаточно удобнее чем на С++ и производительность при этом получается тоже достойная (тут речь про сложную бизнес логику в неком большом приложении).
>>1141151>Если ты знаешь, где можно найти эту информацию в виде списка или прямого текста "мы берём компиляторы/интерпретаторы по принципу..." Не погружался туда глубоко, есть там и немного подкрученные моменты (если пошерстить сорцы, так же есть и неоднозначные решения), но на этом мои изыскании закончились.А так мне нравятся эти бенчмарки, глупо конечно сравнивать по ним языки, но на этих тестах гораздо важнее видно другое, например моменты, когда некие супер легкие фреймворки (например sparkjava) на самом деле и не такие и легкие как кажутся. Надеюсь это выльется в какое-то соревнование http серверов, когда разработчики не только будут аутировать на свой код, но и писать достойные сервера (жалко только эти тесты не покрывают весь http (или хотя бы большую часть), так как там много огрызков-серверов, которые в этих тестах участвовать не должны по определению)
>>1141183...под серверами я так же имею ввиду и фреймворки
>>1141172> разрабатывать на джаве достаточно удобнее чем на С++Достаточно спорное утверждение.
>>1140271> Спасибо что не С++На D проще будет.
>>1135455Спринг бут жрет где-то 30-40мб оперативки. Дальше все жрет твое приложение, а не фреймворк.
>>1141220У меня куча вопросов:1) Под нагрузкой 30-40мб или ты со старта ГЦ запустил (не покрутив в нагрузке)?2) Он же каждый твой сервис-объект проксит, это дополнительная память. И судя по тестам это все проседает до скриптовых языков по производительности (то есть реально как питоновский flask или чуть быстрее чем питоновская джанга (меньше чем в два раза там)).3) Я честно не понимаю что там можно на 40 мегов написать (если без примесей, то спринг, по сути, тупо IoC-контейнер и автолокатор)?
>>1141252>сервис-объект прокситЭти 100 байт уже не вернуть.
>>1141257Эх если бы в джаве байты считали...Скорее всего там тонна абстракции вокруг одного бина. Если они подобие сервис-локатора то в 40 метров засунуть умудрились.Я не удивлюсь если какая-нибудь питоновская джанга будет весить меньше в разы.
>>1141262Клоун, ты бы меньше удивлялся, а больше писал код, в том числе на разных языках и платформах.
>>1135455>на Go нет фреймворковСхуяли нет? Даже для Rust есть https://rocket.rs/
>>1141274Не бомбит? Очень информативный пост.
>>1141297Нет, не бомбит. Но я не уверен, что до тебя дошел смысл моего сообщения. Помимо призыва, там еще подразумевался вывод от полученного опыта.
>>11412521. Расходы на память фреймворком никак не связаны с нагрузкой. Нагрузка идёт в твою бизнес логику и это расходы твоего кода и твоего приложения. И считал их не я, их считали авторы Spring Boot. 2. Спринг ничего не будет проксировать, пока ты не попросишь. А если ты просишь - то это твоя логика, а не фреймворк. Фреймворк просто даёт тебе возможность не писать эти прокси руками. А ещё: прокси по интерфейсу займет какие-то смешные байты, у тебя должны быть тысячи бинов, если не сотни тысяч, чтобы это сказалось на памяти.3. Спринг - да, всего лишь IoC контейнер и AOP фреймворк в ядре. Spring Boot - достаточно большая надстройка над спрингом с кучей функционала от автоматизации подтягивания конфигов до встроенного томката. Можешь почитать документацию и сорсы артефакта spring-boot ради интереса. И если ты будешь использовать спринг как IoC-контейнер и автоаллокатор, то жрать он будет ровным счётом нихуя.Короче: жрёт не спринг, жрёт твой код.
Какая сладкая боль джявиста ИТТ. Прямо как у одной из команд у меня на работе, которая после джвух лет еботни с плачем переписывает свое поделие на Го, попутно охуевая от того, сколько проблем при этом просто растворяется в воздухе. А до этого тоже копротивлялись и вопили вот ровно все те же самые мантры, что и местный джявист. Мне немного грустно, потому что вместе с джявой из компании уходит славный источник лулзов.А ты, ОП, давай пиши на Котлине. Нам нужны лулзы.
>>1141301Ссори, но какие-то подмены понятий.1. Хочешь сказать, что фреймворк в процессе работы больше ничего не аллоцирует? Немного фантастически звучит, но допустим.2. Спринг же все твои бины проксирует, ну и опять же, не веру что там нету мета данных каких-то, по-любому там так же кэшируется рефлексия.Какой-то докладчик, тоже заливал в уши, что вот прокси объекты за счет рефлексии медленнее только в два раза (там в наносекундах), но на практике спринг проседает до питона (хотя томкат достаточно шустрый в этих масштабах).>3. Спринг - да, всего лишь IoC контейнер и AOP фреймворк в ядре. Spring Boot - достаточно большая надстройка над спрингом3. Ох, как это все громко звучит, как будто на Марс человека отправили. Спринг бут - это тупо адаптированный слой пред-настроек. То что любой питоност/пхп/js мержит (объединяет) предустановленный массив настроек с массивом настроек пользователя у джавистов это "биг дил" (хотя и выглядит так потому, что делается все это через классы-настройки)
>>1141301>Короче: жрёт не спринг, жрёт твой код.Только что ты или твой товарищ говорил что спринг отжирает 30-40мб. Это же ппц дофигища для пустого приложения, а теперь ты говоришь что джава либы хорошие, а виноват я сам. Ну ё-мое...К сожалению, джава реально не плохой язык, но вот то что там пишут вызывает огромные сомнения и лишь реально подтверждает лурковский стереотип о джава разработчиках, у которых сервис локатор с заготовленными предъустановками вылевается в 40 мегов.
>>1141301>до встроенного томката>2018>томкат
>>1141379Проснись, хеллоуворлды на джаве жрут 20 мб.>>1141418Так и живём. Хотя вот вышел спринг 5 и спринг бут 2, там подвезли реактивную альтернативу старому mvc с томкатом, по идее должно быть на порядок легче. >>11413731. А зачем ему что-то аллоцировать? Все биндефинишны распарсены, все бины созданы, дальше работает твое приложение. 2. Прости, ты какой-то бред пишешь. Ещё раз: прокси создаёт не спринг, прокси заказываешь ты. Если ты ничего не попросишь - в контексте будет лежать голый инстанс твоего класса. А при чем тут метаинфа я вообще не понимаю. 3. Это не биг дил. Потому он и в пункте "от". Ну и где вы баттхерт увидели я хз. Я же не агитирую никого использовать этот стек. Но не надо надумывать ему проблемы на пустом месте.
>>1141476>Проснись, хеллоуворлды на джаве жрут 20 мб.Это ложь, даже чистый томкат после сборки метро 15, а jetty embedded может быть 5-8мб.>Так и живёмЕще раз убеждаюсь, что ты не до конца понимаешь стэк спринга, но активно говоришь об этом. Хоть томкат и по дефолту, он меняется там парой строк, спасибо и тому же спринг-буту (даже асинхронный undertow можно всобачить, правда спринг от тормознутости это почти не спасет)>Это не биг дил. Потому он и в пункте "от". Не понял, какой еще "от"?? И это не меняет того факта, что они просто добавили предварительные дефолтные настройки и все. >прокси создаёт не спринг, прокси заказываешь тыЧто ты там заказываешь постоянно, я все не пойму. Ты вообще в курсе, как там под капотом работает и то что все инжекты это не твои инстансы, а спринговые прокси (и скорее всего поэтом там все так адово тормозит и жрет ОЗУ)?
>>1141529>Это ложь, даже чистый томкат после сборки метро 15, а jetty embedded может быть 5-8мб.Запускать их пробовал?>Еще раз убеждаюсь, что ты не до конца понимаешь стэк спрингаЯ отлично понимаю стек спринга. И я знаю, что там и как меняется.>Не понял, какой еще "от"?? И это не меняет того факта, что они просто добавили предварительные дефолтные настройки и все.Нет, не всё. В буте дохуя всего.>Что ты там заказываешь постоянно, я все не пойму.Прокси.>Ты вообще в курсе, как там под капотом работает и то что все инжекты это не твои инстансы, а спринговые прокси (и скорее всего поэтом там все так адово тормозит и жрет ОЗУ)?Нет, это так не работает. Инжектится то, что лежит в контексте. Будет там прямой инстанс класса или прокся - зависит от тебя. Пример: https://pastebin.com/0yuCjyPCВ логе будет:myController bean class: class com.example.Application$MyControllermyService bean class: class com.example.Application$MyServicemyTransactedService bean class: class com.example.Application$MyTransactedService$$EnhancerBySpringCGLIB$$11508ef1Т.е. проксёй закрылся только тот сервис, который обёрнут аспектом для транзакций. И ты сам лично попросил это сделать, поставив аннотацию.
>>1141529>Это ложь, даже чистый томкат после сборки метро 15, а jetty embedded может быть 5-8мб.>может быть>может быть>может бытьМожет быть ты не будешь строить предположения в том, в чем не разбираешься?
>>1141558У тебя ctrl + v заело? Или просто бомбит и нужно было что-то написать такое, чтобы задело (ничего в следующий раз получиться)?>Может быть ты не будешь строить предположения в том, в чем не разбираешься?Вот как раз я снова попал на джуно-андройщиков, которые не понимают как устроен спринг и вообще как работает их джава. И получается, то у них томкат захордкожен, то хеллоу ворды под 20мб (когда не зная о JMM думают, что резервирование хипа это и есть реальное потребление памяти приложения). И то что спринг реально не используется инстансы напрямую, а заворачивает каждый в свою абстракцию (которые и называются прокси-объектами).И ведь еще и спорят.
>>1141825На сообщение выше ответь, прокси-даун.
>>1141827Тот пост выше как раз тебе и адресован, андрючник
>>1142016 Не туда воюешь, дружок, и да бомбануло тебе таки.мимо >>1141825 проебавшийся с ответом >>1141537
>>1142026Лол, опять проебался. Нахуй этот тупой тред, даже мотивации следить за ниткой нет.
>>1142028>опять проебался>мотивации нет.
>>1142026Тебе и ответил тоже (да вообще всем андрюшникам).Как можно дискутировать с человеком о джаве если он путает аллокацию приложения и резервирование хипа джавы? Да я запускал эти все приложения, НО в профайлере!Как можно дискутировать с человеком, который не в курсе как реализуются бины в спрингу?? Что блядь за фраза Будет там прямой инстанс класса или прокся - как можно дискутировать с человеком, которые путает ООП-паттерн с реализацией технической абстракции над бинами в приложении??Вот Как?! Карл?!
>>1142328фикс> с технической реализацией абстракции над бинами
>>1142328Нет никакой абстракции над бином. Ты хуйню несёшь.
>>1142491И не было никакого бина и спринга
>>1142728Полно Вам, голубчик, баловаться, грешно это. Да и нет у Вас никакой шляпы.
>>1135408 (OP)Так что ты выбрал?
>>1143992pikachuuu
>>1135408 (OP)Бери Erlang.
>>1135520За 2 недели ты туду лист со списком студентов напишешь, которому будет похер на производительность.
