Если Вы JavaScript для client-side используете, а Java — для backend, то это всё-таки 1 поезд, просто с двумя вагонами, можно ещё 3-й вагон SQL прицепить )
А вот если и то и то для backend, то интересно было бы послушать каким образом Вы это совмещаете.
До Rust и Go уже был написан D. Если с C++ понятно, что ломать обратную совместимость никто не хочет, то вот почему не захотели вкладываться в D непонятно…
Спасибо за подробный рассказ. По-моему у Вас вполне здравая позиция и выбор технологий по конкретным критериям. Только к чему переживать об упущенных поездах, на двух одновременно ехать всё равно не удобно. По-любому какой-то один будет основным.
Из трёх перечисленных я хорошо знаком только с Go. Но в Go скорее идёт компоновка старых и очень старых идей, чего-то реально нового там не видно.
Есть даже книжка «Communicating Sequential Processes. The First 25 Years» с материалами симпозиума от 2004 года.
В Rust, насколько я понимаю, из коробки реализована модель умных указателей. Но самим умным указателям тоже сто лет в обед.
По поводу зависимых типов, Idris — далеко не первый ЯП, в котором они используются. А тому же Coq уже больше 30 лет.
P.S. С другой стороны, если рассматривать отдельно взятого программиста, то Вы правы, тут идёт прогресс в мышлении по мере ознакомления с разными парадигмами и подходами. Но в рамках индустрии новых идей очень мало.
Хорошее замечание. На мой взгляд, тут скорее математически неправильная трактовка понятия асимптота. Всё-таки появление нового оборудования, типа квантовых компьютеров, может принести что-то новое и в программирование, но процесс идёт крайне медленно…
Там список для демонстрации непонимания самого понятия «альтернатива» со стороны тех, кто слишком подвержен хайпу. Если вчитаетесь, заметите, что в этот список свалено всё в одну кучу.
Каждый стоящий новый язык тянет за собой новую парадигму.
А можно парочку примеров?
Инструменты должны изначально писаться не под конкретный язык, выделять свои функционально независимые блоки в отдельные взаимозаменяемые модули
Это да. Но поддержку нового языка всё равно надо будет дописать, при этом не факт, что язык позволит использовать возможности такой IDE в полной мере.
В целом я согласен, что развитие инструментов должно продолжаться и там до асимптоты ещё далеко.
Именно такие статьи и побудили меня перевести эту, когда я её увидел… Люди часто забывают, что любая технология — это всего лишь инструмент со своей областью применения. А если выбирать из 3 примерно одинаковых инструментов, то выбор получится чисто субъективный.
Да, у IDE на Java всегда были приличные требования к железу.
Я подумывал заменить пример на Visual Studio для C#, но всё-таки решил оставить как в оригинале.
Статья немного провокационная… Бывает по разному, переключаться между технологиями вполне допустимо, если от этого есть практическая выгода. А прыгать между примерно одинаковыми вариантами — это уже непрофессионально.
В Вашем же примере речь скорее не о переключении, а об изначальном выборе технологий для проекта. И тут уже Ваша задача как профессионала обосновать свой выбор заказчику, если для его проекта Java идеально подходит.
Ну что ж, радует, что есть какой-то прогресс и в этой области.
Расширение крутое, но будет лучше, когда подобные возможности появятся в самом языке. Это, кстати, хороший вариант и обратную совместимость сохранить ещё на пару версий и параллельно новую согласованную stdlib сделать.
Когда в Go дело доходит до использования сторонних библиотек, то ситуация становится гораздо печальнее, чем в Java. Куча библиотек, которые делают примерно одно и то же, приходится реально вчитываться в код каждой, чтобы сделать адекватный выбор.
Да что там библиотеки… Попробуйте для начала веб-фреймфорк выбрать: awesome-go#web-frameworks
А вот если и то и то для backend, то интересно было бы послушать каким образом Вы это совмещаете.
Есть даже книжка «Communicating Sequential Processes. The First 25 Years» с материалами симпозиума от 2004 года.
В Rust, насколько я понимаю, из коробки реализована модель умных указателей. Но самим умным указателям тоже сто лет в обед.
По поводу зависимых типов, Idris — далеко не первый ЯП, в котором они используются. А тому же Coq уже больше 30 лет.
P.S. С другой стороны, если рассматривать отдельно взятого программиста, то Вы правы, тут идёт прогресс в мышлении по мере ознакомления с разными парадигмами и подходами. Но в рамках индустрии новых идей очень мало.
Это да. Но поддержку нового языка всё равно надо будет дописать, при этом не факт, что язык позволит использовать возможности такой IDE в полной мере.
В целом я согласен, что развитие инструментов должно продолжаться и там до асимптоты ещё далеко.
Я подумывал заменить пример на Visual Studio для C#, но всё-таки решил оставить как в оригинале.
В Вашем же примере речь скорее не о переключении, а об изначальном выборе технологий для проекта. И тут уже Ваша задача как профессионала обосновать свой выбор заказчику, если для его проекта Java идеально подходит.
Расширение крутое, но будет лучше, когда подобные возможности появятся в самом языке. Это, кстати, хороший вариант и обратную совместимость сохранить ещё на пару версий и параллельно новую согласованную stdlib сделать.
Да что там библиотеки… Попробуйте для начала веб-фреймфорк выбрать: awesome-go#web-frameworks