Вы путаете две вещи «я не пытался профайлить именно этот проект» (да, не пытался. Примерно знал во что оно выльется) и «я не пытался профайлить в java вообще» (такой опыт был, иначе не о чем было бы говорить)
Не только он. Существенная экономия была достигнута за счёт профилирования и за счёт ловли race conditions.
Несущественная — за счет меньшего объема кода.
Я правильно понимаю, что у вас был опыт наблюдения за новичком, который пытался начинать с go?
Если это так, расскажите подробнее, пожалуйста.
Я никаких проблем не вижу, но поскольку к моменту изучения go новичком не был, то мог что-то важное пропустить.
А вопрос для меня, действительно важный — думаю о более широком применении go в нашей компании.
В том числе и для юниоров.
Но Go и Java суть одно и тоже, просто синтаксис разный.
Не соглашусь. Иначе не было бы смысла вообще создавать go.
Каждый язык имеет свои сильные и слабые стороны. Один хорош для одних целей, другой предпочтительнее для других. Каждый имеет свою нишу.
Продуктивность складывается из вашего опыта и знаний и удобства и мощности языка (в том числе, применительно к конкретной задаче).
Это легко можно увидеть на примере — человек X потратил много лет на изучение ассемблера.
У него стоит задача написания веб сайта.
Что будет для него эффективнее — писать сайт на ассемблере или на .NET?
Я думаю, .NET будет лучшим выбором.
Здесь я столкнулся с похожей ситуацией — увидел класс задач, который решается на go настолько удобнее, что несмотря на мой опыт на java я теперь предпочитаю для таких задач go.
Я просто не вижу смысла спорить с вами о своём профессиональном уровне.
По двум причинам. Во-первых, вы уже все для себя решили, а во-вторых меня не интересует профессиональное мнение человека, который родился в тот год, когда я написал свой первый профессиональный код — часть АСУТП для Сургутской ГРЭС.
Java не тормозит. Тормозил мой неоптимальный код и неверно выбранная серверная библиотека.
Обычно в таких случаях берутся (неудобные) инструменты (VisualVM, например), слабые места изучаются и оптимизируется.
Но в этот раз мне попалась статья об аналогичных инструментах в Go.
Мне показалось, что инструменты настолько превосходят java аналоги, что результат будет достигнут намного быстрее.
Так оно и получилось.
Вы хотите от меня доказательств заведомо ложного тезиса вида «На java нельзя создать такой же быстрй сервер, как на go». Можно. Я думаю, он даже будет поддерживать несколько бОльшее количество клиентов.
Я утверждал лишь, что создание такого сервера на go занимает меньше времени и сил.
Как наличие (плохого) кода на java и хорошего на go может подтвердить или опровергнуть моё утверждение?
Вы пишите о вранье, передергивании и нубстве и тут же требуете цифр, примеров и фактов.
Допустим я скажу, что аналогичная задача на яве заняла у меня X дней, а на go — Y (где Y<X), вас это убедит?
На самом деле, каждый приведенный факт можно поставить под сомнение. Кажды новый факт будет лишь разжигать холивар.
Проблема совсем не в фактах, а в неаккуратном позиционировании моей статьи. Многие тут посчитали, что я хвалю go и ругаю java, приводя в качестве (слабого) аргумента некую сомнительную, как вы сказали «success story». Я сам дал повод так понять эту статью неаккуратной расстановкой акцентов.
Где-то уже писал, что статья не про то. Она про: «ребята, смотрите, go гораздо менее требователен к вашему времени и усилиям по крайней мере на некоторых видах задач. Если ваши задачи схожи, то Go стоит попробовать. Возможно, вы получите некоторый profit.»
Я бы сказал, что важна не краткость, а низкий уровень шума и простота восприятия.
Мне нравится критерий, который сформулировал Grief — язык тем лучше, чем больше смысла я вижу на одном экране.
При том, что код писал не я и я — не гений, а среднестатистический специалист.
Несущественная — за счет меньшего объема кода.
Если это так, расскажите подробнее, пожалуйста.
Я никаких проблем не вижу, но поскольку к моменту изучения go новичком не был, то мог что-то важное пропустить.
А вопрос для меня, действительно важный — думаю о более широком применении go в нашей компании.
В том числе и для юниоров.
А само явление заключается в том, что есть много языков программирования и раз каждый жив, значит у него есть ниша, где он лучше других.
Не соглашусь. Иначе не было бы смысла вообще создавать 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 — язык тем лучше, чем больше смысла я вижу на одном экране.
При том, что код писал не я и я — не гений, а среднестатистический специалист.
Хотя его концепции мне понравились.