Как и многие другие минусы go это является также и плюсом. Я именно за это люблю go. То, что в других языках где-то или под капотом или выше в иерархии обработается, здесь обрабатывается прямо там, где возникло и в максимально простом и понятном виде. При чтении и отладке нужно держать в голове меньше других контекстов - а это дорогого стоит. Учитывая, что сама разработка составляет примерно 10% времени жизни проекта, а поддержка, развитие, чтение кода и разбор инцидентов ВСЕГДА в разы больше времени забирают, то принцип "напиши кучу бойлерплейта здесь явно, чтобы потом читателю было легче" мне кажется правильным. Не то, чтобы с великим удовольствием, но с осознанием, что это важно и нужно - этот механический набор кода делаю. И без всякого раздражения.
Богатство синтаксиса и тип приложений - ортогональные вещи. На 1С пишут системы учета, а синтаксис там самый бедный из всего, что имеется. Синтаксис Go и его бедность - это на самом деле как недостаток, так и преимущество. Если смотреть со стороны скорости запила фичи - то кому то покажется, что недостаток. Если со стороны дальнейших многолетних поддержки и развития системы - то это сплошные преимущества. Читаемость и простота кода позволит с меньшей когнитивной нагрузкой годами обеспечивать нужное качество разработки.
hdparm нужно запускать без кэширования: "sudo hdparm -t-direct /dev/nvme0n1p2" - будут реальные результаты чтения. Также, dmesg выдает результаты загрузки ядра, и там внутри можно найти строки, в каком режиме поднят NVME. У меня при загрузке с NVME так: [ 4.773173] pci 0004:41:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link) А при загрузке с Micro-SD так: [ 6.932612] pci 0004:41:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link) Если в вашем логе - первый вариант, то это PCI-E 1.0 x1. И это 200 Мб/с максимум.
Orange Pi 5 построен на Rk3588s - а это радикально урезанный NVME. В данном случае - 1 (одна) линия PCI-E 2.1. Максимально достижимая производительность SSD на нем - 400 Мб/сек(350-380 реально). Причем в существующем ядре linux от rockchip 5.10.110...5.10.160 существует баг: если система загружается с NVME - то стандарт PCI-E сбрасывается на 1.0, а это 200 Мб/сек. Данное ядро используют и официальные linux, и armbian, и ubuntu от Joshua Riek. Я решил проблему так: изготовил Micro-SD с образом Ubuntu Joshua и залил его же на NVME. Загружаюсь с Micro-SD, а rootfs монтирую из раздела NVME - в итоге получается на нем PCI-E 2.1, жить можно))
Когда на tauri появится хотя бы одна вакансия в hh (в отличие от десятков и сотен на flutter) - появится хоть какой-то смысл в вопросе "Зачем использовать tauri"
Встречался с такой задачей часто на больших таблицах. Безусловно, должен быть join. С масштабируемостью in (...) - начинаются проблемы от 10к+ элементов, к тому же где-то этот массив в памяти надо разместить. Ну и P должен быть проиндексирован, а иначе Nested loops.
Этот синьорЦарь не виноват, ему дали строгие интерфейсы, разрешили наследование реализации, насыпали дженериков — вот он и написал библиотеку, в которой порезвился в compile-time, оверинжинирил по полной, попрятал в реализации грабли, да так что первый же мидлкузнец уволился.
Мне кажется мораль такова:
Не наследуй реализацию! Типизация интерфейсов должна быть утиная, чтобы не было соблазна валидировать на типах. Вообще не занимайтесь мета-программированием на типах, кривая дорожка заведет неизвестно куда.
Получается, кузнец ушел на Кипр в Go? Или в Rust? Криптоподковы на нем очень знатные, но на типах можно порезвиться пожестче. Непонятно.
Интереснейшая статья, спасибо. Подробный анализ от человека непосредственно "с полей", внимательно прочитал, во многом мои ощущения подтвердились. Похожее мнение у Attila Vágó в его статье "I Am Falling Out Of Love With Flutter" на медиуме.
Ограничения. Она сделана как "слегка приоткрытый закрытый продукт". Сравните с Community версиями нормального мэйнстрима — VS, например, которая по сути ничем не отличается от полноценной версии.
Зависимость от "доброй" воли 1С, которая может эту самую лицензию отобрать — а четких правил нет. Мы знаем историю с лицензированием 1С, когда даже честно купленные продукты переставали работать. Проблема 01.02.2021 знакома?
Я понимаю, что мое разочарование связано, в основном, с обманутыми ожиданиями.
Ожидания были, что появится Community-версия, такая как у всех. А появился совершенно не соответствующий названию продукт, полностью в стиле закрытой 1С.
Извините, но по этой статье можно сделать вывод, что вы абсолютно не разбираетесь в том, о чем пишете. Ни в 1С, ни в резервировании, ни в том, как вести учет.
Я искренне надеюсь, что курсы otus ведут гораздо более компетентные специалисты.
Полностью поддерживаю. Пробежался по другим статьям автора. Их уровень производит удручающее впечатление.
Непонятно даже, как объяснить автору в комментариях, где ошибка. С чего начать — с самых азов 1С, с оперативного учета или основ SQL? Поскольку даже в таких вопросах обнаруживается отсутствие системных знаний.
Не раскрыт вопрос: кому это "нам" не хватает настолько экзотических возможностей?
Если имеются в виду разработчики и архитекторы 1С — то нам совершенно точно не хватает только произвольного индексирования регистров накопления (но это касается всех прикладных объектов). В платформе много проблем, но регистры накопления — одна из самых беспроблемных вещей, что там есть.
Если по вопросу неотрицательных остатков у меня просто возникло недоумение (что??), то по поводу распределения глаза начали вылезать на лоб (вы вообще понимаете, что такое ORM и реляционные СУБД?), а по поводу точки актуальности в Заключении вы нагородили такой сонм логических и терминологических ошибок ("Функциональное" проведение???), что, честное слово, можно ответить только словами Филиппа Филипповича про советы космического масштаба и космической же глупости...
Ну, true-разработчикам ничего не мешает и при таких ограничениях делать из справочника регистр накопления (видел лично), а также из справочника — документ (внезапно, типовой 1С Документооборот: Справочник.ДокументыПредприятия).
Мне кажется, автор имел в виду не просто необходимость как-то расширить базовый Справочник, скажем, а общую бедность языка и фреймворка.
Нет никакого ООП, нет функционального программирования, нет хотя бы функций высшего порядка. Нет вообще ничего, у нас примитивнейший бэйсик!
Приведу конкретный пример. Мы не можем создать некий общий виджет, скажем "Согласование документа" с кучей кнопочек/менюшек, отображением состояния и прочего, инакпсулировать в него все обработчики, а потом просто кидать его на формы нужного документа, как это было бы в нормальном языке на современном фреймворке.
Вместо этого на формы нужных документов кидаем целую группу элементов копипастой, в коде формы делаем кучу отсылок и обработчиков всего этого опять таки копипастой, а в общих модулях делаем некий общий API. И такое дублирование — везде, не только в формах.
Поэтому нам приходится поддерживать 10 млн строк кода в ERP вместо 1 млн.
Асинхронность в виде колбеков пришла в 1С в 2013. Недостатки известны были всем, кроме фирмы 1С, видимо. Даже .Net уже перешел к тому времени на псевдосинхронность. Подзадержался только js.
Недавно, в 2020, в 1С наконец-то добавили псевдосинхронность. Теперь подождем еще лет 10, пока лапша из колбеков в БСП и типовых конфигурациях будет переписана.
Таким образом, временной лаг по сравнению с мэйнстримом составляет 5...15 лет.
Как и многие другие минусы go это является также и плюсом. Я именно за это люблю go. То, что в других языках где-то или под капотом или выше в иерархии обработается, здесь обрабатывается прямо там, где возникло и в максимально простом и понятном виде. При чтении и отладке нужно держать в голове меньше других контекстов - а это дорогого стоит. Учитывая, что сама разработка составляет примерно 10% времени жизни проекта, а поддержка, развитие, чтение кода и разбор инцидентов ВСЕГДА в разы больше времени забирают, то принцип "напиши кучу бойлерплейта здесь явно, чтобы потом читателю было легче" мне кажется правильным.
Не то, чтобы с великим удовольствием, но с осознанием, что это важно и нужно - этот механический набор кода делаю. И без всякого раздражения.
Богатство синтаксиса и тип приложений - ортогональные вещи. На 1С пишут системы учета, а синтаксис там самый бедный из всего, что имеется.
Синтаксис Go и его бедность - это на самом деле как недостаток, так и преимущество. Если смотреть со стороны скорости запила фичи - то кому то покажется, что недостаток. Если со стороны дальнейших многолетних поддержки и развития системы - то это сплошные преимущества. Читаемость и простота кода позволит с меньшей когнитивной нагрузкой годами обеспечивать нужное качество разработки.
Обоснуйте
К первой сборке нужен еще молоток - забивать E5-2667v3 в LGA1151...
hdparm нужно запускать без кэширования: "sudo hdparm -t-direct /dev/nvme0n1p2" - будут реальные результаты чтения. Также, dmesg выдает результаты загрузки ядра, и там внутри можно найти строки, в каком режиме поднят NVME. У меня при загрузке с NVME так:
[ 4.773173] pci 0004:41:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)
А при загрузке с Micro-SD так:
[ 6.932612] pci 0004:41:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0004:40:00.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)
Если в вашем логе - первый вариант, то это PCI-E 1.0 x1. И это 200 Мб/с максимум.
Orange Pi 5 построен на Rk3588s - а это радикально урезанный NVME. В данном случае - 1 (одна) линия PCI-E 2.1. Максимально достижимая производительность SSD на нем - 400 Мб/сек(350-380 реально). Причем в существующем ядре linux от rockchip 5.10.110...5.10.160 существует баг: если система загружается с NVME - то стандарт PCI-E сбрасывается на 1.0, а это 200 Мб/сек. Данное ядро используют и официальные linux, и armbian, и ubuntu от Joshua Riek. Я решил проблему так: изготовил Micro-SD с образом Ubuntu Joshua и залил его же на NVME. Загружаюсь с Micro-SD, а rootfs монтирую из раздела NVME - в итоге получается на нем PCI-E 2.1, жить можно))
Есть позиции с 1 по 10. Есть с 21 по 50. А где самая мякотка с 11 по 20?
Когда на tauri появится хотя бы одна вакансия в hh (в отличие от десятков и сотен на flutter) - появится хоть какой-то смысл в вопросе "Зачем использовать tauri"
Встречался с такой задачей часто на больших таблицах. Безусловно, должен быть join. С масштабируемостью in (...) - начинаются проблемы от 10к+ элементов, к тому же где-то этот массив в памяти надо разместить. Ну и P должен быть проиндексирован, а иначе Nested loops.
В пресс-релизе скромно умолчали про самое главное — удаление flatpak.
Этот
синьорЦарь не виноват, ему дали строгие интерфейсы, разрешили наследование реализации, насыпали дженериков — вот он и написал библиотеку, в которой порезвился в compile-time, оверинжинирил по полной, попрятал в реализации грабли, да так что первый жемидлкузнец уволился.Мне кажется мораль такова:
Не наследуй реализацию! Типизация интерфейсов должна быть утиная, чтобы не было соблазна валидировать на типах. Вообще не занимайтесь мета-программированием на типах, кривая дорожка заведет неизвестно куда.
Получается, кузнец ушел на Кипр в Go? Или в Rust? Криптоподковы на нем очень знатные, но на типах можно порезвиться пожестче. Непонятно.
Ваш технический прогресс:
Как вы постите котеек — На блокчейне, али без?
— Йес!
Интереснейшая статья, спасибо. Подробный анализ от человека непосредственно "с полей", внимательно прочитал, во многом мои ощущения подтвердились. Похожее мнение у Attila Vágó в его статье "I Am Falling Out Of Love With Flutter" на медиуме.
Я понимаю, что мое разочарование связано, в основном, с обманутыми ожиданиями.
Ожидания были, что появится Community-версия, такая как у всех. А появился совершенно не соответствующий названию продукт, полностью в стиле закрытой 1С.
а кто не может управлять — пишет статьи, как обустроить
вселенную1СВ удивительном мире мы живем.
Кто может работать — работает. Кто не может — учит.
Полностью поддерживаю. Пробежался по другим статьям автора. Их уровень производит удручающее впечатление.
Непонятно даже, как объяснить автору в комментариях, где ошибка. С чего начать — с самых азов 1С, с оперативного учета или основ SQL? Поскольку даже в таких вопросах обнаруживается отсутствие системных знаний.
Не раскрыт вопрос: кому это "нам" не хватает настолько экзотических возможностей?
Если имеются в виду разработчики и архитекторы 1С — то нам совершенно точно не хватает только произвольного индексирования регистров накопления (но это касается всех прикладных объектов). В платформе много проблем, но регистры накопления — одна из самых беспроблемных вещей, что там есть.
Если по вопросу неотрицательных остатков у меня просто возникло недоумение (что??), то по поводу распределения глаза начали вылезать на лоб (вы вообще понимаете, что такое ORM и реляционные СУБД?), а по поводу точки актуальности в Заключении вы нагородили такой сонм логических и терминологических ошибок ("Функциональное" проведение???), что, честное слово, можно ответить только словами Филиппа Филипповича про советы космического масштаба и космической же глупости...
Ну, true-разработчикам ничего не мешает и при таких ограничениях делать из справочника регистр накопления (видел лично), а также из справочника — документ (внезапно, типовой 1С Документооборот: Справочник.ДокументыПредприятия).
Мне кажется, автор имел в виду не просто необходимость как-то расширить базовый Справочник, скажем, а общую бедность языка и фреймворка.
Нет никакого ООП, нет функционального программирования, нет хотя бы функций высшего порядка. Нет вообще ничего, у нас примитивнейший бэйсик!
Приведу конкретный пример. Мы не можем создать некий общий виджет, скажем "Согласование документа" с кучей кнопочек/менюшек, отображением состояния и прочего, инакпсулировать в него все обработчики, а потом просто кидать его на формы нужного документа, как это было бы в нормальном языке на современном фреймворке.
Вместо этого на формы нужных документов кидаем целую группу элементов копипастой, в коде формы делаем кучу отсылок и обработчиков всего этого опять таки копипастой, а в общих модулях делаем некий общий API. И такое дублирование — везде, не только в формах.
Поэтому нам приходится поддерживать 10 млн строк кода в ERP вместо 1 млн.
Асинхронность в виде колбеков пришла в 1С в 2013. Недостатки известны были всем, кроме фирмы 1С, видимо. Даже .Net уже перешел к тому времени на псевдосинхронность. Подзадержался только js.
Недавно, в 2020, в 1С наконец-то добавили псевдосинхронность. Теперь подождем еще лет 10, пока лапша из колбеков в БСП и типовых конфигурациях будет переписана.
Таким образом, временной лаг по сравнению с мэйнстримом составляет 5...15 лет.