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
Но даже и в этом случае у нас не возникло желания измерять это время, поскольку заметным оно не было.
Что касается GC, то по крайней мере в первой версии bean-ы жили все время жизни приложения.
Про il2cpp могу сказать что под WebGL проект, основанный на Suice собирался и работал без проблем. Значит, наверное, работает.
Коммитов мало, но это — урезанный клон google guice
Работает тоже отлично. Я его использовал.
Проблема банана и гориллы решается использованием Dependency Injection — все зависимости должны внедряться в конструктор, причем, в идеале, как интерфейсы.
Проблема хрупкого класса не являтся проблемой ООП. Это просто — антипаттерн. Такой же, как, например, GOD-object. Не надо так писать. А если почему-то надо, то стоит запретить наследование таких классов.
Вот тут , например, автор хорошо показывает, что стрелять себе в ногу можно и на функциональном языке. Было бы желание.
Например, вот это https://github.com/Disturbing/UnitySuice работает очень неплохо и решает проблему более удобно.
А вот смог бы я осилить Go первым или нет — фиг его знает. Именно поэтому очень инетересен опыт тех, кто пробовал.
Проблема в том, что у каждого своё — «правильно».
Вдруг это — особенность конкретного человека.
Потому что статья была не о проекте.
Что бы вы посчитали доказательством моих слов?
Да, это так. Это было частью эксперимента. Мне нужен был честный фидбэк на статью, а не на статью, которую написал «авторитетный чувак».
Я его получил. Теперь я лучше понимаю как надо и как не надо писать статьи на Хабр.
Полезный опыт.
Большинство людей тоже сможет его прочитать, но мы затратим на это слишком много усилий.
Язык — прежде всего инструмент. В идеале, человек должен иметь дело исключительно со сложностью своей задачи, а не с дополнительной сложностью, привносимой языком.
Из этого можно сделать вывод, что есть какие-то задачи, для которых go подходит лучше других языков. (Ну или, что google таки создал его зря, как следует не разобравшись).
А раз так, значит go отличается от других не только синтаксисом.
Цитирую свою же статью: Какие задачи лучше всего решать на go? Создание многопоточных высоконагруженных серверных решений, в которых потоки много коммуницируют между собой.
Соглашусь. Предостаточно. Здесь речь скорее о философии языка. О том, что с точки зрения того или иного языка важно (а значит включено в набор стандартных инструментов, хорошо продумано и документировано) или просто есть (и, чаще всего создано третьими сторонами).
На любом современном языке можно сделать всё что угодно.
Разница в том, на чем язык предлагает сосредоточиться в первую очередь. В go профилирование и борьба с race conditions это, если хотите — first class citizens. В java — просто часть огромной экосистемы.
Как не пойму, например и вот такой код на scala
И имено поэтому ни Perl ни Scala по данному критерию будут оценены не очень высоко.
Про сервер вы правы. Ранее я писал на java что угодно (начиная от web (бизнес системы) и кончая играми, Eclipse RCP или CORBA-SNMP gateway), кроме серверов реального времени, использующих Websocket. Этот сервер (а точнее — прототип) я написал очень быстро и без оглядки на performance. На этом этапе я определял что вообще должен делать этот сервер, по сути — проектировал игру. С технологией (библиотекой) я, кстати, действительно, ошибся.
Performance-ом собирался заняться на следующем этапе. Уже «предвкушал» приятную возню с VisualVM. Но наткнулся на описание профайлера в языке go (на который уже давненько с интересом посматривал). Описание понравилось. Решил сделать production вариант на go. Сделал. Опытом более чем удовлетворен.
Несущественная — за счет меньшего объема кода.
Если это так, расскажите подробнее, пожалуйста.
Я никаких проблем не вижу, но поскольку к моменту изучения go новичком не был, то мог что-то важное пропустить.
А вопрос для меня, действительно важный — думаю о более широком применении go в нашей компании.
В том числе и для юниоров.