честной продвинутой реализацией многопоточных и многопроцессных приложений доступных из коробки, низкие накладные расходы на обработку большого числа входящих запросов с применением Goroutine (~4.5 кб, соответственно, посчитай сколько можешь поднять горутин именя всего 4gb на апсервере) — первый приоритет. Второй — прогрессивный синтаксис языка: единообразный легкочитаемый чужой код который в принципе невозможно (или крайне сложно) сделать лапшеобразным. Откуда знаю. к Go в рабочих проектах прибегал всего дважды 1. Практический кейс (указал в первом приоритете) 2. Интерес, дабы получить текущий статус развития языка по прошествии нескольких лет 3. Фидбек от знакомых коллег из хайлоад проекта полностью переписанного с пыха на го (lazada).
дискуссия была очень полезной 1 по уязвимостям. я думаю что защита может быть даже выше. пока возможных дыр не вижу 2 с аналогами не ясно не думаю что есть в полной мере аналоги 3 да система не для класных спецов. она по сути для разработок срелнего и низкого уровня. проверяется и автоматизируется все что можно. вы знаете какие бывают програмеры и ка\кие сайты лепят 4 да разработчики должны быть классными но не все а 2-3 . остальные работают под их руководством 5 зачем им это нужно? участие в хорошем проекте всегда окупается. на западе много сайтов где выставляются open source проекты. в россии я таких не нашел но желающие участвовать в open source есть я видел обявления
И все же, зачем? Какие проблемы решает? На кой черт нужен толстый клиент в браузере? Чтобы нужно было 32 гига памяти, дабы 10 вкладок прокормить?
сейчас запущу пару своих проектов и в июле этой темой займусь конкретно. кстати для ускорения бд хочу сделать журналируемое хранилище на базе sqllite+mongodb работающее в паре с mysql
конечно зачем это главный вопрос. я писал- хорошо все делать на одном языке и в одном месте. это node.js но работающий с любым сервером и самыми популярными js frameworks. плюс всякие дополнительный проверки и визарды. память совершенно не увеличивается а значительно уменьшается. из всяких библиотек оставляем только использеумые функции и значительно их облегчаем. рабочий сайт долежн быть крайне защищенным эффективным и легким
большое спасибо за советы. буду дерхать вас в курсе. я получил то что хотел но и гавна га меня вылили не одну бочку. убедили меня чть я идиот шизофреник и наркоман
не ну обычно есть какое-то просто это удобный способ узнать человека у меня вот есть резюме на всякий случай https://drive.google.com/file/d/1YbBqIQ7Ey72aKTImEZuF8tDMIEmPFUH5/view?usp=sharing
Я писал одно приложение на версии 1.2/1.3, т.е. уже почти 4 года прошло примерно и не готов дискутировать по этому поводу. Не буду говорить про многословность языка там где не надо (постоянные if (err) вместо исключений, вместо обычной сортировки по возрастанию дока предлагала реализовать свои методы сравнения и т.д.), но две вещи меня тогда слегла взбесили: 1. Невменяемый GC, который мог внезапно остановить процесс и начать своё черное дело. Учитывая количество и постоянство обращений к приложению это было заметно, хоть и не критично. 2. Куцый менеджер зависимостей, который складывал всё в GOPATH, вместо проекта, что потенциально могло привести к проблемам. Но, как я уже сказал выше, проект был один, опыта в Go мало, да и сроки у него горели, т.ч. времени разобраться во всем детально не было. Может я наговнокодил, может уже всё поправили и пора освежить свои знания, хз. p.s. меня на самом деле заинтересовало, почему всё это понадобилось на начальном этапе. Не так уж много задач в вебе, где без таких решений не обойтись. @igordata --- Добавлено --- Мой таск был прост: нужно было чуть более продвинутое, чем обычно key-value хранилище, которое исходя из входящих данных, подбирало наиболее оптимальный результат(ы) и возвращало его. Проблема же была в том, что сам объем данных был довольно большой, данные нужно было постоянно актуализировать и количество запросов было чуть больше, чем выдерживал php и БД. Такой вот промежуточный "кэш" умеющий выбирать то что нужно вполне себе решил проблему, при этом довольно быстро и практически без затрат по ресурсам сервера. Но всё же это не частый случай, когда оно действительно надо.
https://php.ru/forum/threads/vnimanie-offlajn-posidelki-foruma-php-ru-2018.69602/ Тоже интересно зачем go понадобился. Напиши может мы тебя тоже переубедим.
у меня очень похожий случай, просто их где-то шесть типов таких узлов, некоторые из них ещё и занимаются только своими данными, не связанными с другими. Это прям микросервисы идеальные. Осталось только запилить. --- Добавлено --- так приглашение не требуется. ты ж тему видел. приходи. а я понял. это опечатка ты мне пишешь "на сходку приходи" видимо --- Добавлено --- вы меня можете переубедить на C#, Java, на C++ в крайнем случае. Но не более того. =) Мне нужны долгоиграющие типизированные микросервисы. А я бумагу возьму, нарисую вам кружочки и стрелочки, да.
Человека который согласился на go пригласи что бы познакомится... Времена меняются. Сервера другие. Может у тебя просто не было проектов с большой нагрузкой и это тебя пугает?
Я бы так не сказал. Но, допустим. Но Карл, нода и так работает с чуть ли не тысячами фреймворков и библиотек для JS. Для ноды этого добра в несколько раз больше уже, чем для клиентского JS. Причем множество либ и фреймов для ноды включает в себя ВСЕ множество клиентских либ! Куда уж больше? И что значит "с любым сервером"? С каким любым сервером? Что под сервером подразумевается, а то понятие это довольно широкое. Совершенно совершенно? А кто мейнтейнить будет потом эти порезанные библиотеки? Ты? А кто определяет используемость? Кто-то ту же жикверю держит только ради аякса, а кто-то ради анимаций, прстигспди. Благодаря чему? Как легким может быть толстый клиент? Он по определению монстр. Ммм..серверсайд на плюсах. Прототпирование длиною в жизнь, текущая память, падающие процессы..
Понятно. Но всё же весь проект исключительно на go я бы не стал делать. Для фронтовой части js-решения все же лучше ложатся. Кстати, почитал, GC они поправили в новых версиях, теперь он умнее и паузы не такие заметные. --- Добавлено --- А многое работает и там и там одинаково хорошо )
Все низкоуровневые языки одинаковые. Тот же php на c++ написан но что то я не вижу у людей рвения писать все с нуля. Да и разговоры о скорости это очень субъективно. От задачи зависит от реализации. Зачем мучать себя ради того что бы в будущем возможно сэкономить доллар...
нормального нет Работаю проект-менеджером, в основном контролирую всё. И по надобности пишу что-то. Показывать это я, конечно же, не стал бы. Нет таких серьёзных проектов, которыми я бы мог гордиться. Но могу, в принципе, прислать тебе то резюме, что есть. Плюс мб ты какую задачку по Go подкинешь, я сделаю, поучусь. А там может уже и на сходке встретимся.
если вы не согласны что хорошо делать на одном языке и в одном месте то тогда конечно темы для разговора нет. но уверяю вас многим менеджерам это понравится те сегмент рынка имеется. я в основном имею в виду наиболее популярные апача виртуальный хостинг или виртуальный сервер но работать система сможет вообще с любым веб сервером и сама система может быть тяжелой а сайт сделанный ею легким потому что реальный сайт генерируется препроцессором. на этом этапе провеояются уязвимости стандарт кодировавния валидность кода кроссбраузерность убираеются лишние функции оптримизируются картинки и тд. без препроцессора нельзя обеспечить безопасность и вообще темы нет и этот рабочий сайт будет совершенно обычным сайтом с серверной частью скажем на php (для asp тоже можно сделать) и клиентской частью на js и любимом фрейворке. --- Добавлено --- если node бы мог работать с любым сервером я все бы делал на его базе
Это они просто завидуют. И не хотят учить ничего нового. Если сможешь весь функционал Laravel перенести на nodejs framework собрать комьюнити раскрутить сделать его популярным востребованным я перейду. Sailsjs слабо развивается у тебя есть все шансы. Но скорее всего просто забросишь в самом начале. И кстати была попытка называлась trailsjs там даже орм и сервер выбирать можно было но его увы тоже забросили. Когда дело доходит до мелочей которые нужно создавать годами все бросают