• Принципы свободного рынка в понимании США
    0
    Ко всем евреям обращаться предлагаете, или только к израильтянам?
  • Docker — это игрушка или нет? Или всё-таки да?
    0
    Не решает, конечно. Потому меня статья на тему «Ansible лучше чем Docker» так и смутила.
  • Docker — это игрушка или нет? Или всё-таки да?
    0
    Всегда считал, что лучше скадывать вещи в шкаф Docker, чем раскидывать их по разным стульям Ansible/Chef/Puppet.
  • Docker — это игрушка или нет? Или всё-таки да?
    +1
    «Х нужно только тогда, когда нужно, и никогда больше»

    У нас был монолит на Ruby on Rails, 150K строк кода, который не только лишь все могли у себя запустить. Потому что кто-то проапдейтил OSX, и вот уже какой-то Ruby Gem засивящий от C++ кода слетел. Docker все эти проблемы тоже отлично решил.
  • Docker — это игрушка или нет? Или всё-таки да?
    +1
    Да даже для JVM приложений Docker полезен. Не факт, что где-то будет установлен Maven/Gradle и правильная версия JDK.
  • Современный PHP — прекрасен и продуктивен
    0
    Два года их уже обещают, если не больше.
  • Beego — это уже не Go
    +1
    Внутренние методы != приватные

    Возвращаемся к тому, что в Go в целом нет private method, только package private. Если не использовать Beego, конечно, с которым все будет private.
  • Beego — это уже не Go
    0
    То есть у меня в целом нет цели убеждать любить DDD кого-то, с кем я не работаю :)
  • Beego — это уже не Go
    0
    Возвращаемся к тому, что разделение по доменам не отменяет разбиение на модели и view.

    Если под «крупным сайтом» подразумевается какое-нибудь монолитное приложение, а не набор микросервисов, делим его на модули. Каждый модуль — domain. Ко всему есть подход. Но если DDD не нравится — заставить его полюбить не смогу, да и не нужно :)

    А по поводу конкретного фрейморка — авторы никуда особо не целились, а тупо скопировали то, что было в Ruby on Rails.
  • Beego — это уже не Go
    0
    Мы как-то перескочили на написание игрушек и собственных фреймворков.
  • Beego — это уже не Go
    0
    По такому принципу в папке orders вообще не должно ничего лежать. Или у вас бывает, когда заказы хотят что-то увидеть?

    Конкретный заказ должен видеть скорее всего тот, кто его выполняет. Но в целом, может быть ситуация, когда в одном package'е будет несколько моделей.

    значит список папок — это, по сути, список вьюшек, в которых иногда лежат модели

    Domain — это не view.
    Если посмотреть на те проекты, с которыми я сейчас работаю, у меня в domain'е будет скорее всего аналог controller'а, а может и не один, и какой-то набор service class'ов, причем произвольное количество слоев, в зависимости от сложности.
  • Beego — это уже не Go
    0
    как только нужно что-то монструозно большое, я думаю что на Go, что на Java, что на .NET будут и фасады, и микросервисы, и вся эта братия

    Безусловно. Нет в Go никакой магии, хоть некоторые в нее и веруют.

    Так они на любом языке хорошо пишутся

    Не совсем. В Java до последнего времени не было удобного HTTP Client «из коробки», к примеру. Какой-нибудь command line на Python'е потребует предустановленный интерпретатор, в то время как в Go получаем единый бинарник «из коробки», опять же.
  • Beego — это уже не Go
    0
    И куда бы вы отнесли какие-то совмещенные вьюшки? Ну типа таблица orders <=> users.

    Зависит от того, где это будет применяться. Скорее всего пользователь хочет видеть свои заказы, а не наоборот.

    в какую из ваших папочек вы бы закинули табель результатами, где по вертикали — список учеников, а по горизонтали — список уроков?

    Табель — вообще отдельный domain, который я бы занес в какую-нибудь /grading
  • Beego — это уже не Go
    0
    У Go есть одно хорошее применение — инфраструктура. Какая нибудь command line utility или reverse proxy на нем действительно пишутся хорошо. Все остальное — так себе.
  • Beego — это уже не Go
    0
    можно закрыть глаза на временное отсутствие нормальных DDD фреймворков


    Не думаю, что временное.
  • Beego — это уже не Go
    0
    Боюсь предположить, как знания внутреннего устройства процессора помогут написателю кода на какой-нибудь Java, которому нужно туда-сюда гонять JSON'ы по сети.
  • Beego — это уже не Go
    0
    С чего бы? Количество классов в обоих примерах одинаковое, зависимости те же.
  • Beego — это уже не Go
    0
    Вот как тут более на показ выставить предметную область?

    Вместо:
    root/
    --controllers/
    ----userController
    ----orderController
    --models/
    ----user
    ----order
    --views/
    ----user.view
    ----order.view


    Можно иметь
    root/
    --user/
    ----user
    ----userController
    ----user.view
    --order/
    ----order
    ----orderController
    ----order.view


    У себя я семантику апи реализовывал как json на вход

    А как быть с семантикой внутри приложения? В том же JavaScript'е хотя бы namespacing при импорте нормальный:
    import { UsersController } from './api/v1/usersController.js'

    В Go так не выйдет.
  • Beego — это уже не Go
    0
    Go очень легко продавать менеджменту — «низкий порог входа, нанимаем джунов, concurrency, 100K RPS, все дела».
  • Beego — это уже не Go
    +1
    У GoKit неплохие примеры на эту тему:
    github.com/go-kit/kit/tree/master/examples/shipping

    Тут вопрос, насколько узка область сущностей.
  • Beego — это уже не Go
    0
    Писать fullstack приложения на Go, как это предлагает делать Beego, явно не стоит.
  • Beego — это уже не Go
    +1
    это практически одинаковые процессы, отличающиеся нюансами предметной области

    Так предметную область и надо выставлять на показ.

    И в чем проблема в поддержании версий апи живыми?

    Проблема не в поддержании API, проблема в том, что теряется вся семантика.

    А насчет кодогенерации, то что есть в Beego гораздо помягче Dagger'a

    С Dagger не работал. Там тоже приходится сгенерированный код коммитить?
  • Beego — это уже не Go
    +1
    То, что так сделано в стандартной библиотеке — не значит, что это хорошая практика.
  • Beego — это уже не Go
    –3
    В Go в целом нет такой вещи, как private method, все package private.
  • Цена TypeScript
    0
    А «полноценные дженерики» они в каком языке есть? В C#? :)
  • Kotlin Native: следите за файлами
    0
    REPL в том же Go сильно не хватает, да.
  • Kotlin Native: следите за файлами
    0
    Мне как раз на днях попалась хорошая статья по теме:
    medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692
  • Kotlin Native: следите за файлами
    0
    Спасибо, действительно элегантней :)
  • Kotlin Native: следите за файлами
    0
    Проверил, ты прав, теперь и IntelliJ позволяет создавать Kotlin/Native проекты. Еще пару месяцев назад такой возможности не было.
  • Kotlin Native: следите за файлами
    0
    Так большинство утилит будет сделано какой-нибудь другой компанией.
    Есть же PR, есть fork в конце-то концов.
  • Kotlin Native: следите за файлами
    0
    Тут все относительно: с каким языком сравнивать и куда именно нужно входить.

    Если сравнивать с каким-нибудь C/C++, действительно начать писать на нем проще.
    Если же писать на нем какой-нибудь concurrent код, то не все так однозначно. А с написанием business logic там все вообще очень плохо.
  • Kotlin Native: следите за файлами
    0
    Debug везде примерно одинаковый, не? Или ты про REPL?

    А GOPATH вот недавно только профиксили. Не прошло и 8и лет, ага.
  • Kotlin Native: следите за файлами
    0
    По началу не понял связи, в интерпретируемых языках ведь так же можно получить exception. Но видимо ты о ситуации, когда утилита есть, а исходников нет?
  • Kotlin Native: следите за файлами
    +3
    Даже не знаю, что меня смущает больше: разделение на «скриптовые» и «интерпретируемые», или то, что Java причисляется к «интерпретируемым».

    But I'll bite. Какую альтернативу предложишь?
  • Kotlin Native: следите за файлами
    0
    Для JVM у Kotlin действительно все прекрасно. Но вот JetBrains уже пару релизов экспериментируют с кроссплатформенностью. Скорее всего видят там какой-то потенциал.
  • Kotlin Native: следите за файлами
    +2
    Тысячи разных filewatcher'ов, на любой вкус и цвет. Цель была все же разобраться что предоставляет (и не предоставляет) Kotlin Native, а не написать еще один.
  • За что я не люблю Go
    0
    Ответ можно свести к «Все просто, только все очень сложно.»

  • За что я не люблю Go
    0
    В Go проще запускать coroutine'ы, но сложно их контролировать. Такие вещи как join, cancel, await, timeout — все сложны в реализации и требуют кучи кода. В Kotlin это все реализовано куда приятней.
  • За что я не люблю Go
    0
    Вообще-то, как верно заметил powerman чуть ниже, разницы между coroutine'ами в Kotlin и goroutine'ами в Go практически никакой. И там и там cooperative scheduling.
  • Если вы подумываете начать писать на Go, то вот что вам следует знать
    0
    Проблема в том, что многие executives действительно в это верят.