|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
dakeiras Alexey Tomin пропущено... Груви ещё там- значит в игнор. С моей стороны аналогично про все проекты на Котлине. Я ж не продвигаю тут библиотеки на котлине. Пусть они удобные, но в java лишние dakeiras Alexey Tomin пропущено... Груви ещё там- значит в игнор. А слабо себя пересилить и попробовать Бобину 1 раз? Или страшно, что вдруг понравится?:) Зачем? Груви я не использую и не буду. Мне одного проекта хватило, в котором груви использовался в одном модуле. Я даже не лазил туда особо, но проблемы лезли оттуда во все стороны. На всякий случай- java-код тех же авторов проблем не создавал ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2020, 17:26 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
авторЗачем? Груви я не использую и не буду. Мне одного проекта хватило, в котором груви использовался в одном модуле. Я даже не лазил туда особо, но проблемы лезли оттуда во все стороны. На всякий случай- java-код тех же авторов проблем не создавал Независимо от контекста, у тут есть проблема с аналитическим ходом мыслей в данном конкретном случае. Вы делаете вывод о ВСЕХ проектах на основе ОДНОГО проекта с ОДНИМ модулем, написанным ОДНИМ программистом. Это вызвано обычно предвзъятостью к предмету:) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 12:00 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
dakeiras авторЗачем? Груви я не использую и не буду. Мне одного проекта хватило, в котором груви использовался в одном модуле. Я даже не лазил туда особо, но проблемы лезли оттуда во все стороны. На всякий случай- java-код тех же авторов проблем не создавал Независимо от контекста, у тут есть проблема с аналитическим ходом мыслей в данном конкретном случае. Вы делаете вывод о ВСЕХ проектах на основе ОДНОГО проекта с ОДНИМ модулем, написанным ОДНИМ программистом. Это вызвано обычно предвзъятостью к предмету:) Я сам пробовал груви. Динамический язык программирования кажется мне плохой идеей. Вы предлагаете ради небольшой библиотеки (пишется за недельку с многопоточностью) тащить многомегабайтный jar? Зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 12:18 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
Alexey Tomin dakeiras пропущено... Независимо от контекста, у тут есть проблема с аналитическим ходом мыслей в данном конкретном случае. Вы делаете вывод о ВСЕХ проектах на основе ОДНОГО проекта с ОДНИМ модулем, написанным ОДНИМ программистом. Это вызвано обычно предвзъятостью к предмету:) Я сам пробовал груви. Динамический язык программирования кажется мне плохой идеей. Вы предлагаете ради небольшой библиотеки (пишется за недельку с многопоточностью) тащить многомегабайтный jar? Зачем? из-за компиляции в класс на основе конфига при запуске приложения. Это даёт большой прирост производительности по сравнению с JSR223 (любой релизацией его). Насчёт динамического языка - Груви поддерживает статическую компиляцию и гибридную (на уровне класса). Я использую статическую по умолчанию, и там где надо - явно включаю динамическую через аннотацию метода. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 12:26 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
Беспокойство коллег я вижу вот в чем. Java - это ассемблер для JVM. И ее типы данных. И прочие сущности такие как class/enum/interface компилируются в сущности JVM в соотношении 1:1. Тоесть если ты кодер на Java - то у тебя есть 100% контроль над выходом. Ты всегда знаешь во что будет собран исходник. В груви у нас такой уверенности нет. По поводу типизации. Она - не родная в груви. Насколько я понимаю исторически груви создавался скриптовым языком для служебных целей. Как-то написание конфигов. Сценариев билда. Или модульных тестов. Типизация с помощью @TypeCheck. Насколько она глубока. Так-же как в С++? Haskell? Цена вопроса - подстраховаться от падения в релизе когда код уже собран но при этом компиллятор не уверен (не владеет на 100% информацией) о том что down casting отработает именно так как ожидалось. А падение в релизе - это падение нашей репутации. И как следствие уровня доверия заказчика. И потеря денег. Тоесть беспокойство коллег - это не чистая теория на тему где красивее код. А это вполне себе материальный интерес. Мы заинтересованы чтобы ошибок ClassCastException у нас не было и не было бы других подобных ошибок связанных с диапазоном (Range) целого например или с тонкими различиями между int и double. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 12:43 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
mayton Беспокойство коллег я вижу вот в чем. Java - это ассемблер для JVM. И ее типы данных. И прочие сущности такие как class/enum/interface компилируются в сущности JVM в соотношении 1:1. Тоесть если ты кодер на Java - то у тебя есть 100% контроль над выходом. Ты всегда знаешь во что будет собран исходник. В груви у нас такой уверенности нет. По поводу типизации. Она - не родная в груви. Насколько я понимаю исторически груви создавался скриптовым языком для служебных целей. Как-то написание конфигов. Сценариев билда. Или модульных тестов. Типизация с помощью @TypeCheck. Насколько она глубока. Так-же как в С++? Haskell? Цена вопроса - подстраховаться от падения в релизе когда код уже собран но при этом компиллятор не уверен (не владеет на 100% информацией) о том что down casting отработает именно так как ожидалось. А падение в релизе - это падение нашей репутации. И как следствие уровня доверия заказчика. И потеря денег. Тоесть беспокойство коллег - это не чистая теория на тему где красивее код. А это вполне себе материальный интерес. Мы заинтересованы чтобы ошибок ClassCastException у нас не было и не было бы других подобных ошибок связанных с диапазоном (Range) целого например или с тонкими различиями между int и double. класс на Груви: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74.
его декомпилированный класс на Яве: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303.
Отличий нет. (доп. код логирования добавлен BlackBox - это мой проект). Аналогично для enum и прочего. При статической компиляции Груви делает Ява код 1 в 1. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 12:53 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
насчёт ClassCastException - тут нужно быть внимательным даже при статической компиляции. Даже в Яве чистой. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 12:55 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
поверьте мне, как CTO я очень слежу чтобы стек был на хорошей платформе в долгосрочной перспективе. У Груви одна проблема сейчас - мало мейнтейнеров. Это риск, но не ретроспективный. Вопроса Groovy или Kotlin или Java нет. Вопрос JVM или Node.js. Node.js на голову выше JVM сейчас. Даже я бы сказал на порядок. Поэтому если будем переходить с Груви - то на Node.js (но это не раньше чем лет через 5). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 13:10 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
Ты "как CTO" иногда заметаешь такую интересную пургу. Node вообще не может конкурировать с Java на back-end по многим причинам. Их сферы применения слишком отличаются. Декомпилляция класса конечно интересна но ты и сюда умудрился запихнуть свою бобину. И что мы здесь ожидаем увидеть? Давай так. Мы не делаем никаких экспериментов пока не поставим задачу. Безсмысленная и безпощадная декомпилляция всякого разного нам не нужна. Лучше напиши рафинированный groovy-код но который имеет использование атомарных и объектных типов и их кастинги в разные стороны. Матрицу кастингов. И мы на ее посмотрим. И я (яж не упёртый) соглашусь с тем что Groovy генерит надёжный код. Моё видие Груви было сформировано лет 9 назад. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 13:35 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
mayton Ты "как CTO" иногда заметаешь такую интересную пургу. Node вообще не может конкурировать с Java на back-end по многим причинам. Их сферы применения слишком отличаются. Декомпилляция класса конечно интересна но ты и сюда умудрился запихнуть свою бобину. И что мы здесь ожидаем увидеть? Давай так. Мы не делаем никаких экспериментов пока не поставим задачу. Безсмысленная и безпощадная декомпилляция всякого разного нам не нужна. Лучше напиши рафинированный groovy-код но который имеет использование атомарных и объектных типов и их кастинги в разные стороны. Матрицу кастингов. И мы на ее посмотрим. И я (яж не упёртый) соглашусь с тем что Groovy генерит надёжный код. Моё видие Груви было сформировано лет 9 назад. вот без доп. AST трансформаций (без @BlackBox, @ToString и @Slf4j): Groovy: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66.
Java: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 16:16 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
авторВы предлагаете ради небольшой библиотеки (пишется за недельку с многопоточностью) тащить многомегабайтный jar? Зачем? 8МБ это многомегабайтный? А что тогда маломегабайтный? Jackson 2МБ занимает. Тоже предлагаете "не тащить" его? Тут выше Mayton сказал что у Явы своя ниша по сравнению с Node.js. Без библиотек "мнохамехабайтных" - я хочу знать - КАКОВА эта ниша тогда? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 17:01 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
У нас был параллельный топик. И мы обсуждали каменты создателя Node. Он что-то там жаловался плакал. Как Ельцин. Дескыть я устал я ухожу. Идите все вжопу а я домой. И там мы коснулись некоторых архитектурных features, которые node не поддерживает. В частности движок node был одно-процессный и потоки он не умел запускать. Его концепция потоков основана на асинк-события дисковой и сетевой подсистемы. К каким последствиям приводит остуствие потоков (Threads) для бизнес-приложений - подумайте сами. Возможно у Нод-щиков есть свой рецепт. И возможно они потоки эмулируют запуском процессов. (это по смыслу как будто из Java process builder вы вызвали еще один процес java). Но я думаю что они должны делать приложения на 100% event driven. И как-то там прорабатывать бизнес цикл сообщений чтоб гарантировать что процессинг будет короткий и не захватит вычислениями надолго. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 17:40 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
А ты не шутил насчет того что с груви на ноду переходить собрался? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 23:59 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
mayton А ты не шутил насчет того что с груви на ноду переходить собрался? я сейчас поработал на Vue.js и просто офигел. Насколько продуктивно. Сообщества больше на Ноде и экосистемы тоже больше. (чем на Яве). Ява это умирающая платформа - хоть и довольно медленно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 00:02 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
dakeiras, только надо учесть что js - это интерпритатор , и обработчик запросов а java - это приложение - со всеми вытекающими возможностями. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 06:34 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
dakeiras, А ты умеешь эту ноду оптимизировать? Но тоесть писать код так чтобы он быстро работал в релизе. В java оптимизирующему jit компилятору потратили более 20 лет на все улучшения. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 07:40 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
mayton Но тоесть писать код так чтобы он быстро работал в релизе. В java оптимизирующему jit компилятору потратили более 20 лет на все улучшения. Нода достаточно шустрая, но это больше за счёт того, что там не успели написать тонну библиотек, ормов и фреймворков сверху. То есть, чтобы работало быстро и не жрало ram на яве надо постараться, когда в ноде можно нашлёпать дефолтный код и он будет сносно работать. С другой стороны производительность простого стрингбилдера на js вгоняет в депрессию. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 07:55 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
dakeiras Node.js на голову выше JVM сейчас. Даже я бы сказал на порядок. Чем она на порядок выше? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 07:57 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
crutchmaster dakeiras Node.js на голову выше JVM сейчас. Даже я бы сказал на порядок. Чем она на порядок выше? Разработчики делятся на тех, кому зашли динамически-типизированные языки, и кому зашли статически-типизированные. А ещё функциональщики. Это как религия. Если зашла "динамика"- то ruby и js+nodejs это самое то. groovy - палиатив. Если "статика"- то java/scala/kotlin или c# (С++ и ассемблер не будем поминать). И от groovy тошнит. Просто dakeiras нашёл своё признание. Ну и хорошо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 08:16 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
Alexey Tomin нашёл своё признвание ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 09:06 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
crutchmaster dakeiras Node.js на голову выше JVM сейчас. Даже я бы сказал на порядок. Чем она на порядок выше? там регулярно в репозиторий npm какие-то бэкдоры пихают, где вы еще такое встретите? Или где еще можно два раза подряд собрать одно и то же и получить совершенно разный результат? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 09:40 |
|
Бобина 4.1.0
|
|||
---|---|---|---|
#18+
Андрей Панфилов crutchmaster пропущено... Чем она на порядок выше? там регулярно в репозиторий npm какие-то бэкдоры пихают, где вы еще такое встретите? Или где еще можно два раза подряд собрать одно и то же и получить совершенно разный результат? Класс. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 09:42 |
|
|
start [/forum/topic.php?fid=59&msg=39991085&tid=2120701]: |
0ms |
get settings: |
24ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
480ms |
get tp. blocked users: |
2ms |
others: | 310ms |
total: | 909ms |
0 / 0 |