Люди занимаются какой-то ерундой. Гораздо лучше было бы добавить в GET и DELETE поддержку body, сначала в стандарт, а потом потихоньку в браузеры, серверы, фреймворки и так далее. В статье говориться, что вроде как будет проще что бы все поддерживали новый метод, но мне кажется, что повсеместная поддержка нового метода будет не раньше поддержки IPv6.
Что лучше в этом случае делать? Забить на HTTP-методы с их семантикой и всегда использовать POST в API и GET для статического контента.
Итак, опрос StackOverflow, показывает что С++ вырос, но не на 3, а на 1-1,5% в зависимоти от категории, но там и Rust вырос, и С# и JS. Это ни о чем не говорит, тут задается вопрос о том, пользуются ли языками. Я пользуюсь С++, но большую часть времени пишу на TypeScript. В голосовании я бы поставил две галочки, но тут важен объем кода, а не просто изпользование языка. А таких данных нет.
Многие кто пишут на Rust, так или иначе касаются С/С++, потому что это же БАЗА. Безвыходная база, которую избегают если можно, но не всегда можно.
Что есть в поддержку моего утверждения? Например вот эта статистика, где показано количество новых репозиториев по основному языку: https://www.chartkite.com/github-archive Здесь отчетливо видно, как растет Rust по отношению к C++ и TypeScript по отношению к JavaScript. Там наверняка есть огромное влияние мусорных репозиториев, так как пришла эпоха LLM, но дефолтный язык для LLM это Python, вряд ли обыватель будет что-то вайбкодить на C++/Rust.
Какое однобокое мышление. Видимо кроме прикладных вещей ничего другого и не делали.
Однобокое мышление у тех, кто пишет только низкоуровневый код и ничего другого не знает.
Все существующие сейчас высокоуровневые языки программирования были изначально написаны на С++. Как и с какого перепугу вы можете называть С++ плохим?
C++ это база, потому что это более менее удачный язык, который первым занял нишу, но мы движемся вперед, сложность софта растет, парадигмы програмирования развиваются. Про “раскрутку компилятора” слышали? Если бы c++ был идеалом на нем так бы и писали.
А вы просто взяли и приравняли его к С. Типа он низкоуровневый.
Я ничего не приравнивал. Я просто знаю, что многие прошивки пишуться на Си. Си выбирают потому что уже есть примеры и тулчейн под Си, а для С++ нет, или например не хотят тащить в проект абстракции С++. Еще как оказалось на Си проще найти спецов чем на С++ и Rust. А если все звезды сходяться, специалисты находяться, тулчейны и библиотеки имеются, то тогда берут Rust. А еще, если надо взаимодействовать с ОС, то оказывается, что WinAPI прибито гвоздями к Си, Winrt к с++, а в macos к Objective-C/C++ и раст туда никак не вкрутить. Но если оказываться, что добрые люди написали нужные обертки, то раст становиться самым приоритетным выбором (опять же если команда умеет в него).
А если C# и С++ на одной IDE работают?
Я еще со времен Visual Studio 2005 заметил, что внезапно IntelliSense работает лучше на C# чем на С++. Время идет IDE прокачивается, но все равно C++ в этом плане отстает от C#, потому что DEFINE и TEMPLATE это просто подставление текста в шаблон. А у C# есть Generics, которые проще понимаются IDE.
А медленной разработка может быть только по причине кривых рук и узкого лба, ну или когда человек изучил Python и возомнил себя невероятно гениальным программистом.
Если в С++ нужно думать об высвобождении памяти, а в C# не нужно, то уже этого достаточно что бы считать что разработка на C# быстрее. Теперь сравните сколько времени надо убить на настройку CMake и MsBuild/Nuget? Вспомним что IDE хуже. А что насчет кучи строк каши в выводе компилятора, когда вы неправильно вызвали шаблон? А что насчет ошибок работы с памятью, вот на C# у нас вылетит exception мы видит стектрейс, а на с++ оно даже может не крашнуться и продолжить работу некорректно. Ах, я забыл, что я не отношусь к тем людям, кто пишет код сразу и без багов.
когда человек изучил Python и возомнил себя невероятно гениальным программистом
Python - это мусор, я не спорю. Зачем Python если есть божественный TypeScript и Bun.
Особенно смешно, как вы толкаете все в одну кучу про узкие места и интеграцию с ОС
Ну вот в моем мире, есть большая часть кода которую пишут на C#/JS и она работает отсилы 10% времени и маленькая часть кода на C++/Rust, которая работает 90% времени и в итоге мы приходим к компромиссу скорости разработки и ресуросоемкости приложения. А еще надо взаимодействовать с ОС, а API OC прикрученно к Си/ObjC/C++.
про js который к С++ не имеет вообще никакого отношения! Это разные вселенные!
Ну так и С# тогда тоже не имеет отношения, про что статья? Я вот прекрасно пишу node-addons и на C++ и на Rust, и даже было дело, что собирал объектный файл на Swift и линовал его к С++ коду. Но делал я это из нужды, потому что не мог вызвать API OC по-другому.
А С++ это как раз тот самый случай когда на нем должен работать кодер, Программист с большой буквы, который пишет и умеет писать программный код на низком уровне, в связке с железом, драйверы и прочее. Без framework-ов, без очистки памяти на автомате, с полным контролем на самом низком уровне.
Помимо написания кода, а точнее войны с компилятором, есть еще вещи типа: алгоритмы, структуры данных, архитектура, базы данных, деплой, мониторинг. И вот я большую часть времени не пишу код, а генерирую его LLM занимаюсь побочными вещами, потому что написание кода это маленькая части работы. Когда я работаю с С++ написание кода это все мое время.
Это все разные задачи и называть основу, базу, исходник - плохим, это как стрелять себе в голову. То, что лежит в основе программного мироздания не может быть плохим априори.
Очень жаль, что никто не говорит на латыни, это же база. А если серьезно, то да, С++ плохой, и понимание в чем он плохой делает меня сильнее. И поэтому, я избегаю его там где это возможно, а там где без него никак, пытаюсь понять спасет ли меня там Rust, и окончательно отчаевшишь иду выбирать между MinGW, MSVC и Clang.
C++ плохой язык. Доказательством этого является то, что на нём пишут все меньше. С++ все ещё используется в тех нишах, где ему не придумали нормальные альтернативы.
Проекты высокого уровня пишут на языках со сборщиком мусора. Многие проекты низкого уровня выбирают чистый Си или же Rust.
На c++ очень медленная скорость разработки из-за отсутствия стандартизированного набора инструментов, ультра сложным подключением библиотек и слабой поддержкой IDE (проблемы всплывают с define и template).
C++ это язык с небезопасной памятью, что усложняет разработку, если есть возможность дать больше ресурсов приложению, с чем пользователь может смириться, но при этом съэкономить колоссальные средства на разработку.
Как правило c++ используется для узких месть, которые нужно ускорить, или же плотной интеграции с ОС. P-invoke позволяет делать это для C#, node-addons и wasm – для js.
Если говорить про тот же C#, то там есть много способов ускориться без p-invoke, например структуры, указатели и unsafe-код, System.Runtime.Intrinsics или те же Span.
Нужно грамотно понимать, место того или иного языка и технологии. С++ это необходимое зло, для тех задач, где ему (пока ещё) нет альтернативы.
Все смешалось в кучу. Я так понимаю, ключевая проблема в том, что интерфейсы не существуют в runtime и нельзя сделать DI / “late binding”, что бы зависимость резолвилась по типу-интерфейса, а не по классу-имплементации.
В моей картине мира JSDoc — это просто инструмент для генерации HTML-документации. А вот проверку типов делает tsc. И тот же WebStorm использует TypeScript Language Server для валидации типов, которые описаны как JSDoc-комментарии.
P.S. Смысл дискуссии в том, чтобы расширять свою картину мира.
JSDoc работает на основе движка TypeScript и всегда выступает в роли догоняющего. У него менее выразительная система типов, более слабая поддержка IDE, более медленная работа, хуже вывод типов. Код с JSDoc попросту объёмнее (больше потребление токенов LLM).
Теперь приходим к тому, зачем всё это: для отказа от транспиляторов и сурс-мап. Это означает: больший размер бандла (нет минификации и удаления неиспользуемого кода), необходимость тащить node_modules на прод, отсутствие полифилов и невозможность использовать самые свежие фичи.
С TypeScript процесс разработки понятен и предсказуем: один раз настроил — и всё работает, а голый JS — это риск. Что, если потребуется использовать React и JSX? Что, если окажется, что бандл слишком большой? Что, если нужно пошарить код между бэком и фронтом? Кто даст понять, что на фронте нет Buffer, но есть Uint8Array?
Копирование в консоль браузера? Что мешает прогонять код через https://www.typescriptlang.org/play/ . Кстати, даже на голом JS придётся убрать у функций ключевое слово export. Вероятно, юнит-тест может решить 90% задач, для которых захотелось скопировать код в консоль. А ещё есть bun repl и https://www.typecell.org/ .
P.S. А сравнение с Java вообще неуместно, это принципиально разные экосистемы и принципы работы.
P.P.S. Я бы вообще отправил Java на свалку, потому что есть C# (упс, опять корпорация зла), который уже 10 лет (с выхода .NET Core) набирает обороты. У C# единый набор инструментов, а не холивары про Maven vs Gradle vs Ant. У C# есть настоящие Generics и Dynamic Language Runtime. А у Java только заявления про то, что он единственный пригодный язык для Ынтырпрайза.
P.P.P.S. Ну а если всё-таки попробовать сравнить TS и Java, то для backend у TS есть преимущества, такие как быстрый холодный старт (естественно после минификации), devDependencies, позволяющие всем разработчикам пользоваться одинаковыми версиями инструментов, возможность шарить код между фронтом и бэком, более выразительная система типов, меньше бойлерплейта, и, конечно же, отсутствие многопоточности: около нулевая вероятность гонок данных. Да, это минус, когда речь идет о high-load.
В современной экономике преобладает потребление услуг. Пусть будет суперавтоматизированное производство сельскохозяйственной и промышленной продукции. Что делать с услугами? Ну допустим водителей заменит автопилот. Что насчёт парикмахеров, сантехников, строителей, стоматологов, хирургов, няней? Там прямой ручной труд, который не поддается автоматизации.
Когда появятся антропоморфные-роботы способные работать со штоборезом, тогда можно будет это обсуждать, а сейчас это всё сказки.
JS - мультипарадигменный, истинное искусство, правильно применять те или иные подходы, и неизменяемость, и pure-functions. А отсутствие поддержки в языке решается на ревью и линтерами.
На практике не особо нужно фп в полной мере, а лишь некоторые подходы.
Если нужно научиться программированию то лучше брать C#. Он проще Java потому что все экосистема унифицирована, нужен только dotnet cli.
Ну а если цель работу найти, то надо учить JS во всем его многообразии и сложностях, создат парочку сложных пет проектов и крутануть опыт на Милда. Это несколько лет постоянной практики и самообучения.
Ни какие курсы за пару месяцев по этому пути не проведут, да и качество курсов оставляет желать лучшего. Главное что нужно знать, курсы ни как не помогают с трудоустройством, даже если они об этом заявляют. Нужно иметь упорство и хватку, которые позволят самостоятельно обучиться на бесплатных материалах в интернете и использовать LLM не для написания кода, а как репетитор который помогает стать лучше.
Сейчас это не самая благоприятная профессия что бы начинать. Начинать нужно только в том случае если есть сверхспособности, умение впитывать материал лучше, чем другие.
Отличная статья и отличная инициатива. Вообще было бы неплохо комитету TC39 смотреть на популярные пакеты и вносить новые фичи в язык. Уже надоело писать Promise.delay руками на каждом проекте.
Насколько же это красиво. Трекинг идущий полным ходом, но при этом враждебный куки-баннер, который не дает никакой регулировки анонимности и защиты данных пользователя. Спасибо законодателяем, что обязали все добавить это дерьмо.
На самом деле, можно решить проблему, обязав всех сайтоводов не куки баннеры встраивать, а использовать что-то по аналогий с RSS. При этом, они могу встраивать рекламу, в текст самой статьи и её сложно будет вырезать рекламо-резкой. Все кто технически грамотны и так используют фильтры реклами и из-за RSS не уменьшиться доход.
Расходимся, лицензия минимум на 10 разрабов, цены не говорят, демки нет. Видео с описанием возможностей нет. Только заявления: мы круты, мы для корпоратов.
Люди занимаются какой-то ерундой. Гораздо лучше было бы добавить в GET и DELETE поддержку body, сначала в стандарт, а потом потихоньку в браузеры, серверы, фреймворки и так далее. В статье говориться, что вроде как будет проще что бы все поддерживали новый метод, но мне кажется, что повсеместная поддержка нового метода будет не раньше поддержки IPv6.
Что лучше в этом случае делать? Забить на HTTP-методы с их семантикой и всегда использовать POST в API и GET для статического контента.
Утверждение основано на моих ощущениях. Там кто-то внедряет на Rust (https://security.googleblog.com/2021/06/rustc-interop-in-android-platform.html), тут кто-то призывает отказаться от С++ (https://habr.com/ru/news/699142/). Объективных данных по языкам программирования мало. Надо парсить гитхаб, желательно самому гитхабу, что бы они захватили еще и приватные репо.
Итак, опрос StackOverflow, показывает что С++ вырос, но не на 3, а на 1-1,5% в зависимоти от категории, но там и Rust вырос, и С# и JS. Это ни о чем не говорит, тут задается вопрос о том, пользуются ли языками. Я пользуюсь С++, но большую часть времени пишу на TypeScript. В голосовании я бы поставил две галочки, но тут важен объем кода, а не просто изпользование языка. А таких данных нет.
Многие кто пишут на Rust, так или иначе касаются С/С++, потому что это же БАЗА. Безвыходная база, которую избегают если можно, но не всегда можно.
Что есть в поддержку моего утверждения? Например вот эта статистика, где показано количество новых репозиториев по основному языку: https://www.chartkite.com/github-archive Здесь отчетливо видно, как растет Rust по отношению к C++ и TypeScript по отношению к JavaScript. Там наверняка есть огромное влияние мусорных репозиториев, так как пришла эпоха LLM, но дефолтный язык для LLM это Python, вряд ли обыватель будет что-то вайбкодить на C++/Rust.
Однобокое мышление у тех, кто пишет только низкоуровневый код и ничего другого не знает.
C++ это база, потому что это более менее удачный язык, который первым занял нишу, но мы движемся вперед, сложность софта растет, парадигмы програмирования развиваются. Про “раскрутку компилятора” слышали? Если бы c++ был идеалом на нем так бы и писали.
Я ничего не приравнивал. Я просто знаю, что многие прошивки пишуться на Си. Си выбирают потому что уже есть примеры и тулчейн под Си, а для С++ нет, или например не хотят тащить в проект абстракции С++. Еще как оказалось на Си проще найти спецов чем на С++ и Rust. А если все звезды сходяться, специалисты находяться, тулчейны и библиотеки имеются, то тогда берут Rust. А еще, если надо взаимодействовать с ОС, то оказывается, что WinAPI прибито гвоздями к Си, Winrt к с++, а в macos к Objective-C/C++ и раст туда никак не вкрутить. Но если оказываться, что добрые люди написали нужные обертки, то раст становиться самым приоритетным выбором (опять же если команда умеет в него).
Я еще со времен Visual Studio 2005 заметил, что внезапно IntelliSense работает лучше на C# чем на С++. Время идет IDE прокачивается, но все равно C++ в этом плане отстает от C#, потому что DEFINE и TEMPLATE это просто подставление текста в шаблон. А у C# есть Generics, которые проще понимаются IDE.
Если в С++ нужно думать об высвобождении памяти, а в C# не нужно, то уже этого достаточно что бы считать что разработка на C# быстрее. Теперь сравните сколько времени надо убить на настройку CMake и MsBuild/Nuget? Вспомним что IDE хуже. А что насчет кучи строк каши в выводе компилятора, когда вы неправильно вызвали шаблон? А что насчет ошибок работы с памятью, вот на C# у нас вылетит exception мы видит стектрейс, а на с++ оно даже может не крашнуться и продолжить работу некорректно. Ах, я забыл, что я не отношусь к тем людям, кто пишет код сразу и без багов.
Python - это мусор, я не спорю. Зачем Python если есть божественный TypeScript и Bun.
Ну вот в моем мире, есть большая часть кода которую пишут на C#/JS и она работает отсилы 10% времени и маленькая часть кода на C++/Rust, которая работает 90% времени и в итоге мы приходим к компромиссу скорости разработки и ресуросоемкости приложения. А еще надо взаимодействовать с ОС, а API OC прикрученно к Си/ObjC/C++.
Ну так и С# тогда тоже не имеет отношения, про что статья? Я вот прекрасно пишу node-addons и на C++ и на Rust, и даже было дело, что собирал объектный файл на Swift и линовал его к С++ коду. Но делал я это из нужды, потому что не мог вызвать API OC по-другому.
Помимо написания кода, а точнее войны с компилятором, есть еще вещи типа: алгоритмы, структуры данных, архитектура, базы данных, деплой, мониторинг. И вот я большую часть времени не пишу код, а
генерирую его LLMзанимаюсь побочными вещами, потому что написание кода это маленькая части работы. Когда я работаю с С++ написание кода это все мое время.Очень жаль, что никто не говорит на латыни, это же база. А если серьезно, то да, С++ плохой, и понимание в чем он плохой делает меня сильнее. И поэтому, я избегаю его там где это возможно, а там где без него никак, пытаюсь понять спасет ли меня там Rust, и окончательно отчаевшишь иду выбирать между MinGW, MSVC и Clang.
C++ плохой язык. Доказательством этого является то, что на нём пишут все меньше. С++ все ещё используется в тех нишах, где ему не придумали нормальные альтернативы.
Проекты высокого уровня пишут на языках со сборщиком мусора. Многие проекты низкого уровня выбирают чистый Си или же Rust.
На c++ очень медленная скорость разработки из-за отсутствия стандартизированного набора инструментов, ультра сложным подключением библиотек и слабой поддержкой IDE (проблемы всплывают с define и template).
C++ это язык с небезопасной памятью, что усложняет разработку, если есть возможность дать больше ресурсов приложению, с чем пользователь может смириться, но при этом съэкономить колоссальные средства на разработку.
Как правило c++ используется для узких месть, которые нужно ускорить, или же плотной интеграции с ОС. P-invoke позволяет делать это для C#, node-addons и wasm – для js.
Если говорить про тот же C#, то там есть много способов ускориться без p-invoke, например структуры, указатели и unsafe-код, System.Runtime.Intrinsics или те же Span.
Нужно грамотно понимать, место того или иного языка и технологии. С++ это необходимое зло, для тех задач, где ему (пока ещё) нет альтернативы.
Да очевидно, что нужно заниматься AI-assisted кодингом, что бы фиксить галлюцинации и иногда откровенную тупость LLM.
А новичкам как-будто вообще не надо сюда лезть, потому что рынок и так переполнен. Дайте существующим специалистам спокойно выйти на пенсию.
Все смешалось в кучу. Я так понимаю, ключевая проблема в том, что интерфейсы не существуют в runtime и нельзя сделать DI / “late binding”, что бы зависимость резолвилась по типу-интерфейса, а не по классу-имплементации.
Есть вот такая штука, использует надстройку над компилятором: https://github.com/wessberg/DI
Но и на классическом TS это можно сделать, просто для каждого интерфейса нужно сделать symbol-дескриптор. https://inversify.io/docs/introduction/dependency-inversion/
В моей картине мира JSDoc — это просто инструмент для генерации HTML-документации. А вот проверку типов делает tsc. И тот же WebStorm использует TypeScript Language Server для валидации типов, которые описаны как JSDoc-комментарии.
P.S. Смысл дискуссии в том, чтобы расширять свою картину мира.
JSDoc работает на основе движка TypeScript и всегда выступает в роли догоняющего. У него менее выразительная система типов, более слабая поддержка IDE, более медленная работа, хуже вывод типов. Код с JSDoc попросту объёмнее (больше потребление токенов LLM).
Теперь приходим к тому, зачем всё это: для отказа от транспиляторов и сурс-мап. Это означает: больший размер бандла (нет минификации и удаления неиспользуемого кода), необходимость тащить node_modules на прод, отсутствие полифилов и невозможность использовать самые свежие фичи.
С TypeScript процесс разработки понятен и предсказуем: один раз настроил — и всё работает, а голый JS — это риск. Что, если потребуется использовать React и JSX? Что, если окажется, что бандл слишком большой? Что, если нужно пошарить код между бэком и фронтом? Кто даст понять, что на фронте нет Buffer, но есть Uint8Array?
Копирование в консоль браузера? Что мешает прогонять код через https://www.typescriptlang.org/play/ . Кстати, даже на голом JS придётся убрать у функций ключевое слово export. Вероятно, юнит-тест может решить 90% задач, для которых захотелось скопировать код в консоль. А ещё есть bun repl и https://www.typecell.org/ .
P.S. А сравнение с Java вообще неуместно, это принципиально разные экосистемы и принципы работы.
P.P.S. Я бы вообще отправил Java на свалку, потому что есть C# (упс, опять корпорация зла), который уже 10 лет (с выхода .NET Core) набирает обороты. У C# единый набор инструментов, а не холивары про Maven vs Gradle vs Ant. У C# есть настоящие Generics и Dynamic Language Runtime. А у Java только заявления про то, что он единственный пригодный язык для Ынтырпрайза.
P.P.P.S. Ну а если всё-таки попробовать сравнить TS и Java, то для backend у TS есть преимущества, такие как быстрый холодный старт (естественно после минификации), devDependencies, позволяющие всем разработчикам пользоваться одинаковыми версиями инструментов, возможность шарить код между фронтом и бэком, более выразительная система типов, меньше бойлерплейта, и, конечно же, отсутствие многопоточности: около нулевая вероятность гонок данных. Да, это минус, когда речь идет о high-load.
Ну надо же как-то привлечь внимание. Серваке сами себя продавать не будут.
Зачем js-doc, если есть TS? Есть транспиляторы, есть сурсмапы. Это все выглядит как превозмогания ради мнимой борьбы с корпорацией зла.
Вероятно стоит смотреть в сторону https://www.pwabuilder.com/
В современной экономике преобладает потребление услуг. Пусть будет суперавтоматизированное производство сельскохозяйственной и промышленной продукции. Что делать с услугами? Ну допустим водителей заменит автопилот. Что насчёт парикмахеров, сантехников, строителей, стоматологов, хирургов, няней? Там прямой ручной труд, который не поддается автоматизации.
Когда появятся антропоморфные-роботы способные работать со штоборезом, тогда можно будет это обсуждать, а сейчас это всё сказки.
JS - мультипарадигменный, истинное искусство, правильно применять те или иные подходы, и неизменяемость, и pure-functions. А отсутствие поддержки в языке решается на ревью и линтерами.
На практике не особо нужно фп в полной мере, а лишь некоторые подходы.
Если нужно научиться программированию то лучше брать C#. Он проще Java потому что все экосистема унифицирована, нужен только dotnet cli.
Ну а если цель работу найти, то надо учить JS во всем его многообразии и сложностях, создат парочку сложных пет проектов и крутануть опыт на Милда. Это несколько лет постоянной практики и самообучения.
Ни какие курсы за пару месяцев по этому пути не проведут, да и качество курсов оставляет желать лучшего. Главное что нужно знать, курсы ни как не помогают с трудоустройством, даже если они об этом заявляют. Нужно иметь упорство и хватку, которые позволят самостоятельно обучиться на бесплатных материалах в интернете и использовать LLM не для написания кода, а как репетитор который помогает стать лучше.
Сейчас это не самая благоприятная профессия что бы начинать. Начинать нужно только в том случае если есть сверхспособности, умение впитывать материал лучше, чем другие.
Отличная статья и отличная инициатива. Вообще было бы неплохо комитету TC39 смотреть на популярные пакеты и вносить новые фичи в язык. Уже надоело писать Promise.delay руками на каждом проекте.
Насколько же это красиво. Трекинг идущий полным ходом, но при этом враждебный куки-баннер, который не дает никакой регулировки анонимности и защиты данных пользователя. Спасибо законодателяем, что обязали все добавить это дерьмо.
На самом деле, можно решить проблему, обязав всех сайтоводов не куки баннеры встраивать, а использовать что-то по аналогий с RSS. При этом, они могу встраивать рекламу, в текст самой статьи и её сложно будет вырезать рекламо-резкой. Все кто технически грамотны и так используют фильтры реклами и из-за RSS не уменьшиться доход.
Это мне их продажники так сказали.
Меня довольно часто выручала эта штука:
https://rxjs.dev/api/operators/shareReplay
Расходимся, лицензия минимум на 10 разрабов, цены не говорят, демки нет. Видео с описанием возможностей нет. Только заявления: мы круты, мы для корпоратов.
Горшочек не вари