Information
- Rating
- Does not participate
- Location
- Ян де нова о-ва
- Date of birth
- Registered
- Activity
Specialization
Fullstack Developer, Software Architect
Lead
Java
Docker
React
TypeScript
Java Spring Framework
Designing application architecture
High-loaded systems
А само явление заключается в том, что есть много языков программирования и раз каждый жив, значит у него есть ниша, где он лучше других.
Не соглашусь. Иначе не было бы смысла вообще создавать go.
Каждый язык имеет свои сильные и слабые стороны. Один хорош для одних целей, другой предпочтительнее для других. Каждый имеет свою нишу.
Это легко можно увидеть на примере — человек X потратил много лет на изучение ассемблера.
У него стоит задача написания веб сайта.
Что будет для него эффективнее — писать сайт на ассемблере или на .NET?
Я думаю, .NET будет лучшим выбором.
Здесь я столкнулся с похожей ситуацией — увидел класс задач, который решается на go настолько удобнее, что несмотря на мой опыт на java я теперь предпочитаю для таких задач go.
Но на go таки вышло быстрее. Причем очень существенно.
По двум причинам. Во-первых, вы уже все для себя решили, а во-вторых меня не интересует профессиональное мнение человека, который родился в тот год, когда я написал свой первый профессиональный код — часть АСУТП для Сургутской ГРЭС.
Статья не о скорости языка, а о скрости разработки на языке.
Обычно в таких случаях берутся (неудобные) инструменты (VisualVM, например), слабые места изучаются и оптимизируется.
Но в этот раз мне попалась статья об аналогичных инструментах в Go.
Мне показалось, что инструменты настолько превосходят java аналоги, что результат будет достигнут намного быстрее.
Так оно и получилось.
А go не знаю совсем. Это не меняет дело?
Но у меня нет хорошего кода на ява, который делает то же самое. Он мне не был нужен.
Я утверждал лишь, что создание такого сервера на go занимает меньше времени и сил.
Как наличие (плохого) кода на java и хорошего на go может подтвердить или опровергнуть моё утверждение?
Допустим я скажу, что аналогичная задача на яве заняла у меня X дней, а на go — Y (где Y<X), вас это убедит?
На самом деле, каждый приведенный факт можно поставить под сомнение. Кажды новый факт будет лишь разжигать холивар.
Проблема совсем не в фактах, а в неаккуратном позиционировании моей статьи. Многие тут посчитали, что я хвалю go и ругаю java, приводя в качестве (слабого) аргумента некую сомнительную, как вы сказали «success story». Я сам дал повод так понять эту статью неаккуратной расстановкой акцентов.
Где-то уже писал, что статья не про то. Она про: «ребята, смотрите, go гораздо менее требователен к вашему времени и усилиям по крайней мере на некоторых видах задач. Если ваши задачи схожи, то Go стоит попробовать. Возможно, вы получите некоторый profit.»
Мне нравится критерий, который сформулировал Grief — язык тем лучше, чем больше смысла я вижу на одном экране.
При том, что код писал не я и я — не гений, а среднестатистический специалист.
Хотя его концепции мне понравились.
Думаю, большинство комментаторов уместно поинтересовались бы — чего это автор тут пиарится, вместо того, чтобы говорить дело.
Смысл статьи коротко можно выразить так — «Люди, смотрите, есть такие задачи, которые на go получается решать намного быстрее, приятнее и эффективнее, чем на java. Будет свободное время — гляньте сами. Время окупится.»
Проект был всего лишь иллюстрацией. Но если вы, или кто-то другой действительно интересуетесь этим проектом, я отпишу тут подробнее.
Дополнительно запускался и «нормальный» клиент для субъективной оценки поведения игры под этой нагрузкой.
По уму для хабра статью надо было перделать и писать примерно так: Вот уже 14 лет мы пробуем новые языки, чтобы не пропустить технологическую волну. До сих пор, ни один язык не выигрывал у явы в главном для нас параметре — в скорости разработки. Так было, пока не появился go.
Этот самый go выиграл по этому параметру на таком-то проекте. Если ваш проект похож, обратите внимание на go.
Тогда бы и холивара было бы поменьше.