Вспоминается мне, когда я сел пробовать Раст, переписывая на него маленькие кусочки важные мне с проектов на питоне, горшке, то столкнулся с какой то дичью. А именно - нужен был потоковый парсинг xml, очень много, вычитывать все файлы в память очень затратно.
Что стандартные библиотеки на go, что на питоне справлялись с этим отлично.
Может я конечно не нашел того же в stdlib раста, но 3 года назад я пошел искать библиотеки для этого. И мне кажется я сошел с ума тогда.
Каждый реализует этот парсинг по своему, кто то даёт возможность вернуть токен, кто то нет, вот тут скопируйте-перекопируй, тут не используй указатель, а тут возвращай копию того что ты ожидал.
В общем, я понимаю что "растовчане" могут по делу напихать мне, но честно говоря экосистема раста меня до сих пор отталкивает.
Он правда что прекрасен, когда пишешь что-то, что не требует использования чужих реализаций. Но отсутствие какого-то единого стиля очень сильно отталкивает.
Так, а теперь важный вопрос, как отключить встроенный форматтер json который наконец то подъехал, но в ужасном виде? А то теперь открываешь во вкладке что-то с application/json и там этот кошмар. Любое расширение делает лучше :\
Ну, лично я думаю что в 23 году уже да, должно быть стэком джуна хотя бы на базовом уровне "щупал, игрался". В конце концов популярность вебсокетов и SSE никуда не пропадает.
Это спорный вопрос про уровень специалистов. Я знаю людей из крупных компаний в РФ, которые имеют в компании статус сеньора с соответствующей зп, но не умеют в БД, никогда даже для себя не пробовали брокеры сообщений и т.п. Так что субъективщина.
Хотя я согласен, это были бы не самые критические навыки, на которые я бы смотрел на собеседовании, но много говорит про любознательность кандидатов.
Ладно, это был скорее рофл, но не в обиду. Воспринимайте скорее как общий вывод-шутка на основе того, что люди с частным мнение дают такой стэк - это не плохо. Плюс-минус такая же ситуация с роадмапами фронта и т.д.
Не поймите не правильно, я не хочу обидеть или задеть, каждый имеет право писать тут и т.п., я вообще считаю что за подобные статьи ставить минусы не нужно, т.к. тут нет никаких ошибок и т.п.
Но всё такие с таким громким заголовком хотелось бы видеть больший список технологий и раскрытия темы, а не краткое PS.
Типа, а почему только postgres? mariadb вроде же жива. ClickHouse в конце концов, хоть это и немного другое, но всё же актуальное.
Какие-нибудь (любые) технологии для очередей типа RabbitMQ; А что там со всякими Redis? Есть альтернативы, но давайте считать редиску абстрактной базой.
Да и тему актуальных серверов бы лучше раскрыть, банально перечислив их не только в PS, указав плюсы и минусы.
Еще раз - мой комментарий был просто шуткой, но не над вами, в свое время такие статьи мне были полезны всё равно, как минимум потому что подсвечивали технологии которые и я тогда не знал.
Ох... Честно говоря это спорная библиотека, выше правильно написали, что вы поставите большое количество кода в проект.
С другой стороны, если вы не такой перфекционист, то вполне. Она затыкает многие неудобные вещи, для которых придется копипастить костыли. Лично оттуда использую функции связанные с вами браузера. Например то же копирование в буфер - там уже сделана обработка и легаси и современная.
А вот например из реализацию fetch я как то совсем не прочувствовал.. ну вот зачем мне сразу реф получать? Может мне надо обработать ещё объект, скормить его в конструктор класса и получить что-то со своими методами. В общем, выглядит крайне тяжеловесно и не понятно зачем оно.
В целом, я бы грубо оценил так, если вы будете с пользой использовать хотя бы 10-15% функционала библиотеки, благо так есть много повседневно полезного, то вероятно оно стоит того, чтобы тащить в зависимости. В ином случае посмотрите исходники - все полезнее будет и вам и проекту.
Надеялся прочесть о реальных кейсах в бою, примерами реализации для кэша и может чего ещё, а прочёл кучу воды...
Если кто хочет напихать минусов, то хотя бы в в ответ напишите, где тут хоть какие то описания для чего его использовать то? Какие то рассуждения об одном и том же на всю статью.
Мне кажется тот факт, что для выполнения JS в адресной строке браузера, нужно обязательно разделять точкой с запятой - это уже ответ о желательности использования точки с запятой
Но всё же если решили переводить проект на свежую версию вебпака... то возможно тут какая-то проблема с нежеланием использовать как минимум более простой инструмент.
Возможно кто-то распишет примеры, где вебпак делает какие-то супер специфичные штуки, которые не может/не умеет вите - это было бы без иронии интересно.
Просто пока смотрю на это как на yarn2 - все ждали, он вышел, никто не понял зачем и как, и все забили. опять же, может я и ошибаюсь, но на релизе того же yarn2 это было что-то загадочное и непонятно как было пришивать это для проектов на vue том же и т.д. Потом еще полгода пытался найти какие ни будь гайды где люди разобрались - пустота. Хотя концепция вендоринга зависимостей лично мне нравится.
Дополню себя же. Мне кажется, расту нужно ещё 2-3 года, чтобы определились какие-то стандартны для интерфейсов библиотек, линтеров и т.п.
Пока что это ЯП который очень хорош внутри, но кататься на котором не очень приятно.
Вспоминается мне, когда я сел пробовать Раст, переписывая на него маленькие кусочки важные мне с проектов на питоне, горшке, то столкнулся с какой то дичью. А именно - нужен был потоковый парсинг xml, очень много, вычитывать все файлы в память очень затратно.
Что стандартные библиотеки на go, что на питоне справлялись с этим отлично.
Может я конечно не нашел того же в stdlib раста, но 3 года назад я пошел искать библиотеки для этого. И мне кажется я сошел с ума тогда.
Каждый реализует этот парсинг по своему, кто то даёт возможность вернуть токен, кто то нет, вот тут скопируйте-перекопируй, тут не используй указатель, а тут возвращай копию того что ты ожидал.
В общем, я понимаю что "растовчане" могут по делу напихать мне, но честно говоря экосистема раста меня до сих пор отталкивает.
Он правда что прекрасен, когда пишешь что-то, что не требует использования чужих реализаций. Но отсутствие какого-то единого стиля очень сильно отталкивает.
Тоже не понял почему не Pinia в случае vue, но да ладно
Понимаю что решение не универсальное, но по поводу конфигов, мы давно забили на всякие toml, yaml и берём обычный json.
Благо отформатировать есть всегда в чем, всем знаком, стандартные библиотеки для паркинга есть во всех популярных ЯП.
По поводу этого апдейта очень рад. Потому что горилла не столько библиотека, сколько просто декоратор расширяющий стандартную либу.
ИМХО, из реально имеющих смысл библиотек/фреймворков есть только 2 - стандартная, либо с батарейками гориллы и fasthttp.
Вроде как русский язык уже висит в dev где-то.
Когда завезут в стабильный релиз уже другой вопрос.
https://github.com/mozilla/firefox-translations-models
Задам вопрос лучше, исходя из примера выше.
А чем это лучше и удобнее ванильного js?
В примере нет никакой реактивности, специфичный синтаксис есть, но непонятно зачем.
Так, а теперь важный вопрос, как отключить встроенный форматтер json который наконец то подъехал, но в ужасном виде? А то теперь открываешь во вкладке что-то с application/json и там этот кошмар.
Любое расширение делает лучше :\
dbeaver, поддерживает кучу БД в бесплатной версии, вполне косортный, но не без нюансиков
Ну, лично я думаю что в 23 году уже да, должно быть стэком джуна хотя бы на базовом уровне "щупал, игрался". В конце концов популярность вебсокетов и SSE никуда не пропадает.
Это спорный вопрос про уровень специалистов. Я знаю людей из крупных компаний в РФ, которые имеют в компании статус сеньора с соответствующей зп, но не умеют в БД, никогда даже для себя не пробовали брокеры сообщений и т.п. Так что субъективщина.
Хотя я согласен, это были бы не самые критические навыки, на которые я бы смотрел на собеседовании, но много говорит про любознательность кандидатов.
Ладно, это был скорее рофл, но не в обиду. Воспринимайте скорее как общий вывод-шутка на основе того, что люди с частным мнение дают такой стэк - это не плохо. Плюс-минус такая же ситуация с роадмапами фронта и т.д.
Не поймите не правильно, я не хочу обидеть или задеть, каждый имеет право писать тут и т.п., я вообще считаю что за подобные статьи ставить минусы не нужно, т.к. тут нет никаких ошибок и т.п.
Но всё такие с таким громким заголовком хотелось бы видеть больший список технологий и раскрытия темы, а не краткое PS.
Типа, а почему только postgres? mariadb вроде же жива. ClickHouse в конце концов, хоть это и немного другое, но всё же актуальное.
Какие-нибудь (любые) технологии для очередей типа RabbitMQ; А что там со всякими Redis? Есть альтернативы, но давайте считать редиску абстрактной базой.
Да и тему актуальных серверов бы лучше раскрыть, банально перечислив их не только в PS, указав плюсы и минусы.
Еще раз - мой комментарий был просто шуткой, но не над вами, в свое время такие статьи мне были полезны всё равно, как минимум потому что подсвечивали технологии которые и я тогда не знал.
Ну короче, всё как и 5-8 лет назад, кто учится выдыхайте - старые ответы со стаковерфлоу еще актуальны
Ох... Честно говоря это спорная библиотека, выше правильно написали, что вы поставите большое количество кода в проект.
С другой стороны, если вы не такой перфекционист, то вполне. Она затыкает многие неудобные вещи, для которых придется копипастить костыли. Лично оттуда использую функции связанные с вами браузера. Например то же копирование в буфер - там уже сделана обработка и легаси и современная.
А вот например из реализацию fetch я как то совсем не прочувствовал.. ну вот зачем мне сразу реф получать? Может мне надо обработать ещё объект, скормить его в конструктор класса и получить что-то со своими методами. В общем, выглядит крайне тяжеловесно и не понятно зачем оно.
В целом, я бы грубо оценил так, если вы будете с пользой использовать хотя бы 10-15% функционала библиотеки, благо так есть много повседневно полезного, то вероятно оно стоит того, чтобы тащить в зависимости. В ином случае посмотрите исходники - все полезнее будет и вам и проекту.
Ну да, все серверы пишутся же на ноде..
Так и не понял в чем особенность реализации в отличие от gRPC, какой то набросок документации.
Одно удовольствие читать такой качественный код питона. Для начинающих очень полезно как пример.
Надеялся прочесть о реальных кейсах в бою, примерами реализации для кэша и может чего ещё, а прочёл кучу воды...
Если кто хочет напихать минусов, то хотя бы в в ответ напишите, где тут хоть какие то описания для чего его использовать то? Какие то рассуждения об одном и том же на всю статью.
Мне кажется тот факт, что для выполнения JS в адресной строке браузера, нужно обязательно разделять точкой с запятой - это уже ответ о желательности использования точки с запятой
Ну с этой точки зрения согласен.
Но всё же если решили переводить проект на свежую версию вебпака... то возможно тут какая-то проблема с нежеланием использовать как минимум более простой инструмент.
Возможно кто-то распишет примеры, где вебпак делает какие-то супер специфичные штуки, которые не может/не умеет вите - это было бы без иронии интересно.
Просто пока смотрю на это как на yarn2 - все ждали, он вышел, никто не понял зачем и как, и все забили. опять же, может я и ошибаюсь, но на релизе того же yarn2 это было что-то загадочное и непонятно как было пришивать это для проектов на vue том же и т.д. Потом еще полгода пытался найти какие ни будь гайды где люди разобрались - пустота. Хотя концепция вендоринга зависимостей лично мне нравится.
А потом мы просто выкидываем это всё, ставим vite и забываем об этой конфигурационной диче