> Допустим я скажу, что аналогичная задача на яве заняла у меня X дней, а на go — Y (где Y<X), вас это убедит?
Вы вообще не понимаете, что такое «объективность» чтоли?
>ребята, смотрите, go гораздо менее требователен к вашему времени и усилиям по крайней мере на некоторых видах задач.
Менее требователен по сравнению с чем? Как сравнивали, чем мерили и т.д.
Эта фраза и есть «досужие домыслы».
Вы даже поправляя «позиционирование» статьи, лучше не делаете. Даже в этих каментах вы не понимаете, что делаете и продолжаете разжигать холивар на ровном месте.
Холивара было бы поменьше, если такие статьи (саксес стори) по Go были более объективными.
А так они все как под копирку. Одни досужие домыслы и притягивания за уши. Без какой либо конкретики.
Добавьте сюда, по вкусу: вранье, передергивание или откровенное нубство в сравниваемой технологии (в данной статье про Java).
И получите типичный холивар.
Напишите нормальную статью. С примерами похожих задач.
Вот так делали на Java (и это должен быть реальный пример на современных подходах и библиотеках).
А вот так мы сейчас делаем на модном Go.
С описанием и цифрами. Что улучшилось в процессах. Что улучшилось в коде. Что там с багами и поддержкой. Что с рефакторингом и т.д.
Все вам огромное спасибо скажут.
А то вот таких вот домыслов «вилами по воде» в каждом бложике миллион.
Они ничего не улучшают, а только хуже делают.
Ибо оставляют больше вопросов, чем дают ответов.
А в отсутствии реальных фактов, люди начинают сплетничать и фантазировать на тему как оно там может быть…
> Akka (она кстати поверх Netty работает)
Чушь полная. По верх Netty работают как раз примеры которые привел автор: VertX и Play.
Что лишь в очередной раз показывает в нем профана в Java мире.
В Akka же по верх Netty работает только кластер. Т.е. обмен данными между нодами.
И то это выпилят постепенно. Т.к. в Akka уже есть своя отличная реализация сокетов, модуль Akka.io.
Люди, проснитесь уже наконец, оглянитесь во круг, на тот адок что происходит в ИТ.
Ну какие нахрен тяжелые игры и обрабокта видео?
У меня один хром часто 3-4Гб отъедает… Я хз куда винда жрет память, но для нормальной разработки (не говносайтики из пары страниц клепать) 8Гб сейчас это минимум. Все остальное это тормоза и потеря времени.
Я конечно понимаю, что мне тут щас навтыкают «Да я на 2Гб поисковый кластер гугла програмлю».
На все эти понты есть одна хорошая фраза «Кому и кобыла невеста».
Все нормальные разработчики понимают, как важна память и как она может расходоваться во время разработки.
Это вам так кажется. Или хочется чтобы так было.
А у людей все по другому. Никто не делит авторов так.
Карма это оружие в борьбе с несогласными. Хороший способ заткнуть рот тому, кто не нравится по любой причине.
Если пост неудачен, или камент спорный, то автор дебил и ему надо обязательно в карму это отметить.
Это преимущественное поведение.
При чем люди чаще ставят минус чем плюс за любое несогласие с их мнением.
В результате мы видим куда планомерно скатывается хабр.
Всякая фигня заплюсована, а интересные, но спорные, мнения нещадно минусуются, со всеми вытекающими…
Справедливости ради «можно якобы вообще забыть про SQL» это девиз всех средств абстрагирования от БД.
Будь то ОРМ или FRM или еще что.
Но в Slick, на самом деле не сложно разобраться.
Главное не делать сразу большие глаза и не кричать с порога «сложнааааааа», как это любят делать многие.
Поняв основные принципы проблем потом практически не возникает.
Спасибо за материал. Очень его не хватает по Slick.
>и дождёмся её выполнения с помощью Await.result(databaseFuture, 1 second)
Пометьте пожалуйста, что это только для примера. И в реальном проекте это плохая практика.
А то мне приходилось работать с проектом, где из асинхронного Slick, делали синхронный при помощи Await.result.
Люди на столько привыкли к хиберу, что не могли понять, как можно с БД работать асинхронно.
Это очень условное утверждение. Формально приложение есть, но по факту, там походу теперь только баланс можно смотреть. Например при переврде с карты, надо ввести cvv код. Но поля для его ввода просто нет. Можно долбиться очень долго и непонимать, почему платеж отклоняют.
Оно не обновлялось ооооочень давно. Уже пару лет висит надпись «Мы разрабатываем новую крутую версию. Уже очень скоро, будет готово».
Походу они забили на это приложение…
Потому что этой проблемы раньше не было. Но после появления новой web версии отвалился WP клиент. Кстати, этот же глюк был и в web версии, но его поправили за несколько дней.
Скажите, а почему ваши продукты все еще ориентированы на 32bit системы?
ToolBox запускает 32бит версию, по умолчанию тоже 32бита зпускается.
И если это можно поменять как-то, то в комплекте jre только 32 бита и это уже не изменить.
С чем это связано? У вас основная ЦА сидит на старом железе с 3Гб оперативки?
P.S. Это случайно не та самая ГРЭС где 2 раза крупные аварии были? Совпадение? ))
Золотые слова.
Я бы современным web-разработчикам ставил машины с 1Гб и целерон, чтобы они на себе чувствовали какое говно они делают.
Вы вообще не понимаете, что такое «объективность» чтоли?
>ребята, смотрите, go гораздо менее требователен к вашему времени и усилиям по крайней мере на некоторых видах задач.
Менее требователен по сравнению с чем? Как сравнивали, чем мерили и т.д.
Эта фраза и есть «досужие домыслы».
Вы даже поправляя «позиционирование» статьи, лучше не делаете. Даже в этих каментах вы не понимаете, что делаете и продолжаете разжигать холивар на ровном месте.
А так они все как под копирку. Одни досужие домыслы и притягивания за уши. Без какой либо конкретики.
Добавьте сюда, по вкусу: вранье, передергивание или откровенное нубство в сравниваемой технологии (в данной статье про Java).
И получите типичный холивар.
Напишите нормальную статью. С примерами похожих задач.
Вот так делали на Java (и это должен быть реальный пример на современных подходах и библиотеках).
А вот так мы сейчас делаем на модном Go.
С описанием и цифрами. Что улучшилось в процессах. Что улучшилось в коде. Что там с багами и поддержкой. Что с рефакторингом и т.д.
Все вам огромное спасибо скажут.
А то вот таких вот домыслов «вилами по воде» в каждом бложике миллион.
Они ничего не улучшают, а только хуже делают.
Ибо оставляют больше вопросов, чем дают ответов.
А в отсутствии реальных фактов, люди начинают сплетничать и фантазировать на тему как оно там может быть…
Чушь полная. По верх Netty работают как раз примеры которые привел автор: VertX и Play.
Что лишь в очередной раз показывает в нем профана в Java мире.
В Akka же по верх Netty работает только кластер. Т.е. обмен данными между нодами.
И то это выпилят постепенно. Т.к. в Akka уже есть своя отличная реализация сокетов, модуль Akka.io.
Ну какие нахрен тяжелые игры и обрабокта видео?
У меня один хром часто 3-4Гб отъедает… Я хз куда винда жрет память, но для нормальной разработки (не говносайтики из пары страниц клепать) 8Гб сейчас это минимум. Все остальное это тормоза и потеря времени.
Я конечно понимаю, что мне тут щас навтыкают «Да я на 2Гб поисковый кластер гугла програмлю».
На все эти понты есть одна хорошая фраза «Кому и кобыла невеста».
Все нормальные разработчики понимают, как важна память и как она может расходоваться во время разработки.
А у людей все по другому. Никто не делит авторов так.
Карма это оружие в борьбе с несогласными. Хороший способ заткнуть рот тому, кто не нравится по любой причине.
Если пост неудачен, или камент спорный, то автор дебил и ему надо обязательно в карму это отметить.
Это преимущественное поведение.
При чем люди чаще ставят минус чем плюс за любое несогласие с их мнением.
В результате мы видим куда планомерно скатывается хабр.
Всякая фигня заплюсована, а интересные, но спорные, мнения нещадно минусуются, со всеми вытекающими…
Будь то ОРМ или FRM или еще что.
Но в Slick, на самом деле не сложно разобраться.
Главное не делать сразу большие глаза и не кричать с порога «сложнааааааа», как это любят делать многие.
Поняв основные принципы проблем потом практически не возникает.
>и дождёмся её выполнения с помощью Await.result(databaseFuture, 1 second)
Пометьте пожалуйста, что это только для примера. И в реальном проекте это плохая практика.
А то мне приходилось работать с проектом, где из асинхронного Slick, делали синхронный при помощи Await.result.
Люди на столько привыкли к хиберу, что не могли понять, как можно с БД работать асинхронно.
И совсем необязательно брать материалы 8 летней давности для обучения.
Дыр везде полно, на флеше свет клином не сошелся. Но почему-то активно полоскают только флеш)
Это очень условное утверждение. Формально приложение есть, но по факту, там походу теперь только баланс можно смотреть. Например при переврде с карты, надо ввести cvv код. Но поля для его ввода просто нет. Можно долбиться очень долго и непонимать, почему платеж отклоняют.
Оно не обновлялось ооооочень давно. Уже пару лет висит надпись «Мы разрабатываем новую крутую версию. Уже очень скоро, будет готово».
Походу они забили на это приложение…
Потому что этой проблемы раньше не было. Но после появления новой web версии отвалился WP клиент. Кстати, этот же глюк был и в web версии, но его поправили за несколько дней.
Это вот кстати хороший показатель, почему flash популярен и почему html5, за столько лет развития, еле еле смог заменить видосики на ютубе.
— Странно, у меня точно такая же нога и не болит
ToolBox запускает 32бит версию, по умолчанию тоже 32бита зпускается.
И если это можно поменять как-то, то в комплекте jre только 32 бита и это уже не изменить.
С чем это связано? У вас основная ЦА сидит на старом железе с 3Гб оперативки?