All streams
Search
Write a publication
Pull to refresh
26
0
Роман @softaria

User

Send message
Про ленивую инициализацию ничего сказать не могу, поскольку мы пользовались первой версией suice, где все было Eager.
Но даже и в этом случае у нас не возникло желания измерять это время, поскольку заметным оно не было.
Что касается GC, то по крайней мере в первой версии bean-ы жили все время жизни приложения.
Почему нет? Если там и есть какой-то overhead то только в момент создания bean-ов и внедрения зависимостей (то есть — один раз на каждый bean). Потом они точно также существуют и могут использоваться. Или я не понял ваш вопрос?
Специально производительность не замерял. Но заметного эффекта не оказывает.
Про il2cpp могу сказать что под WebGL проект, основанный на Suice собирался и работал без проблем. Значит, наверное, работает.
Основной проект там вот этот https://github.com/Disturbing/suice
Коммитов мало, но это — урезанный клон google guice
Работает тоже отлично. Я его использовал.
Основная ошибка автора — ни один язык сам по себе ничего не гарантирует. Парадигме надо следовать.

Проблема банана и гориллы решается использованием Dependency Injection — все зависимости должны внедряться в конструктор, причем, в идеале, как интерфейсы.

Проблема хрупкого класса не являтся проблемой ООП. Это просто — антипаттерн. Такой же, как, например, GOD-object. Не надо так писать. А если почему-то надо, то стоит запретить наследование таких классов.

Вот тут , например, автор хорошо показывает, что стрелять себе в ногу можно и на функциональном языке. Было бы желание.
Singleton-ы не всегда являются лучшим решением. Как вы смотрите на использование в Unity Dependency Injection?
Например, вот это https://github.com/Disturbing/UnitySuice работает очень неплохо и решает проблему более удобно.
Перенесут на другую свою файлопомойку?
Мне Go показался простым. Хотя привлёк не этим, а сдвигом «фокуса». Его авторы переосмыслили, что сегодня является важным в языке, а что — не очень. на мой взгляд, их вариант лучше подходит для решения актуальных задач.

А вот смог бы я осилить Go первым или нет — фиг его знает. Именно поэтому очень инетересен опыт тех, кто пробовал.

ему гораздо важнее решить задачу правильно, чем решить задачу в принципе.

Проблема в том, что у каждого своё — «правильно».
Поэтому у них есть своя ниша. Для которой они — прекрасны.
Спасибо. Интересный опыт. Хотя, данных для статистики недостаточно.
Вдруг это — особенность конкретного человека.
Вы так и не сформировали чёткой иллюстрации/описания вашего проекта.


Потому что статья была не о проекте.

Пока что никаких доказательств ваших слов никто не увидел.


Что бы вы посчитали доказательством моих слов?

у вас нет «кредита доверия» — вас никто не знает


Да, это так. Это было частью эксперимента. Мне нужен был честный фидбэк на статью, а не на статью, которую написал «авторитетный чувак».
Я его получил. Теперь я лучше понимаю как надо и как не надо писать статьи на Хабр.
Полезный опыт.
Чтобы читать такой код с большой скоростью и в промышленных объёмах, надо быть именно гением.
Большинство людей тоже сможет его прочитать, но мы затратим на это слишком много усилий.
Язык — прежде всего инструмент. В идеале, человек должен иметь дело исключительно со сложностью своей задачи, а не с дополнительной сложностью, привносимой языком.
Просто Google нужен был свой. Чтобы решать свои задачи.


Из этого можно сделать вывод, что есть какие-то задачи, для которых go подходит лучше других языков. (Ну или, что google таки создал его зря, как следует не разобравшись).
А раз так, значит go отличается от других не только синтаксисом.

Мне бы хотелось понять, что это за задачи.


Цитирую свою же статью: Какие задачи лучше всего решать на go? Создание многопоточных высоконагруженных серверных решений, в которых потоки много коммуницируют между собой.

Согласитесь, что в Java таких инструментов предостаточно?


Соглашусь. Предостаточно. Здесь речь скорее о философии языка. О том, что с точки зрения того или иного языка важно (а значит включено в набор стандартных инструментов, хорошо продумано и документировано) или просто есть (и, чаще всего создано третьими сторонами).
На любом современном языке можно сделать всё что угодно.
Разница в том, на чем язык предлагает сосредоточиться в первую очередь. В go профилирование и борьба с race conditions это, если хотите — first class citizens. В java — просто часть огромной экосистемы.
Именно для этого я уточнил, что условеный «я» — не гений. Не пойму я её.
Как не пойму, например и вот такой код на scala

object IsHCons1 {

  type Aux[L[_], FH[_[_]], FT[_[_]], H0[_], T0[_] <: HList] = IsHCons1[L, FH, FT] { type H[t] = H0[t] ; type T[t] = T0[t] }

  def apply[L[_], FH[_[_]], FT[_[_]]](implicit tc: IsHCons1[L, FH, FT]): Aux[L, FH, FT, tc.H, tc.T] = tc

  implicit def mkIsHCons1[L[_], FH[_[_]], FT[_[_]]]: IsHCons1[L, FH, FT] = macro IsHCons1Macros.mkIsHCons1Impl[L, FH, FT]

}


И имено поэтому ни Perl ни Scala по данному критерию будут оценены не очень высоко.
Достаточные навыки в чем-то не противоречат отношению к этом чему-то, как к сложному и неудобному.

Про сервер вы правы. Ранее я писал на java что угодно (начиная от web (бизнес системы) и кончая играми, Eclipse RCP или CORBA-SNMP gateway), кроме серверов реального времени, использующих Websocket. Этот сервер (а точнее — прототип) я написал очень быстро и без оглядки на performance. На этом этапе я определял что вообще должен делать этот сервер, по сути — проектировал игру. С технологией (библиотекой) я, кстати, действительно, ошибся.
Performance-ом собирался заняться на следующем этапе. Уже «предвкушал» приятную возню с VisualVM. Но наткнулся на описание профайлера в языке go (на который уже давненько с интересом посматривал). Описание понравилось. Решил сделать production вариант на go. Сделал. Опытом более чем удовлетворен.
Ответил ниже. Могу. Потому что неоднократно ранее делал это с другими проектами.
Вы путаете две вещи «я не пытался профайлить именно этот проект» (да, не пытался. Примерно знал во что оно выльется) и «я не пытался профайлить в java вообще» (такой опыт был, иначе не о чем было бы говорить)
Не только он. Существенная экономия была достигнута за счёт профилирования и за счёт ловли race conditions.
Несущественная — за счет меньшего объема кода.
Я правильно понимаю, что у вас был опыт наблюдения за новичком, который пытался начинать с go?
Если это так, расскажите подробнее, пожалуйста.
Я никаких проблем не вижу, но поскольку к моменту изучения go новичком не был, то мог что-то важное пропустить.
А вопрос для меня, действительно важный — думаю о более широком применении go в нашей компании.
В том числе и для юниоров.

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