enumerations в Свифте лучше того что Дарт умеет например

 

Да про протоколы треиты

 

Это стопудово

 

У меня большинство кода на перечислениях в айос

 

[
{
"type": "mention_name",
"text": "Vyacheslav",
"user_id": 197673163
},
" наследоваться от String или его имплементировать запрещено по performance considerations. когда было написано ",
{
"type": "code",
"text": "String"
},
" можно было знать, что это нативная строчка а не какая-то самодельная"
]

 

Ещё extension в разных местах очень хороши.

 

это есть и в котлине

 

те для вашего случая file-or-string вы сделаете какой-то trait типа Readable и потом делаете реализацию этого трейта для типа File и типа String, правильно я понимаю?

 

О performance condition только узнал когда это попробовал реализовать. Где про управление памятью можно прочитать. Как её на обе платформы сделали?

 

extension methods приедут, они в пайплайне - это следующий топик после non-nullable types.

 

[
"управление памятью у нас простое - это обычный garbage collection на всех платформах - ",
{
"type": "link",
"text": "https://medium.com/flutter-io/flutter-dont-fear-the-garbage-collector-d69b3ff1ca30"
},
""
]

 

Господи, первый человек, с кем можно о флаттер поговорить. хорошо, что null безопасность делаете. И extension. Будет хорошо.

 

Кстати, в мск будет конфа на эту тему?

 

Обычно Гугл проводит мероприятия по различным темам

 

Wrike вот организовывал свою собственную в Декабре. Мы пока ничего не планируем своего отдельного.

 

Понял. У меня последний базовый вопрос. А тема с асинхрощиной так и будет приоритетной для флаттера? Или Более классические архитектуры тоже нормально пилить?

 

В расте это вроде как чистой воды атд

 

[
"Про трейты спасибо, понятно в чем проблема. Я, кстати, не знаю есть ли механизм похожий на traits в language roadmap. В language team ишуй трекере (",
{
"type": "link",
"text": "https://github.com/dart-lang/language/issues"
},
") ничего не находится"
]

 

[
{
"type": "link",
"text": "https://github.com/dart-lang/language/issues/47"
},
"\n\nКстати\nНелегко же вам будет"
]

 

мне не совсем понятен вопрос - вопрос в том будет ли Дарт однопоточным?

 

Выкидывайте фронт и делайте многопоточность ??

 

Нет . Сейчас в приоритете архитектура типа blob на потоках. В мобилках всё-таки больше mv* модели

 

Будут ли какие-то альтернативы по архитектуре ?

 

ах ну это вопрос скорее к самим Flutter-овцам :)

 

или к community - мне кажется само community изобрело этот BLoC и теперь он всюду

 

так вроде же есть примеры архитектур на mv*

 

вроде ничего особо проблемного в этой фиче нет, вся работа во фронте большей частью

 

я вот наоборот не могу найти примера bloc с api и базой

 

Спасибо, понял

 

приходится ковырять чужое приложение

 

Ну как-то не особо. Там все через async, что делает неудобным MVC, например

 

можно без async делать, но это будет сказываться на произодительности

 

мвс прекрасно с асинками работает

 

Асинки влияют на архитектуру косьвенно, вы можете выбрать что нравится и использовать его. Флаттер не запрещает ничего явно

 

мне наоборот во флаттере нравится вся эта асинхронщина

 

особенно порадовал compute

 

Личное имхо. Она приводит к большим багам

 

заставляет мозг думать подругому ??

 

Вот дня 3-4 переводил главный экран приложения на асинхрощину из-за бага в кейчейне. Это очень мешает поддержке кода

 

Зачем пернусложнять проект на ровном месте

 

Код должен работать, а не вводить в ступор

 

потому что это делает приложение проще

 

дык это ведь баг в кейчейне а не проблема асинков? разве нет?

 

сейчас весь фронтенд на реактищине какой-то, это удобно

 

Баг багом. Проблема в том, что пришлось делать асинк. И асинк сам по себе усложнил

 

Это не так

 

Синхронно все делать удобней?

 

ну только если нет никакого интерактива, то не так

 

делать удобней, но работает не очень )

 

Есть многопоточность.

 

там свои проблемы будут

 

Работает оно понятно и предсказуемо

 

разные контексты

 

но она ничего не решает

 

Она не портит стек:)

 

Весь Эрикс, например, адски портит стек

 

Дебаггер просто перестает быть рабочим инструментом

 

То что тебе не удобно работать с асинком не значит что он внезапно стал плохим и надо его срочно заменить на многопоточность

 

В асинкеиты можешь отлаживаться только если у тебя пара человек в команде. И ты используешь логи

 

многопоточность и так есть

 

Ты путаешь причину и следствие

 

Я работаю с асинками постоянно на фронте и беке

 

и как-то без проблем с отладкой

 

В начале многопоточность. А асинк - это синтаксический сахар

 

можешь называть его сахаром, но это нормальная штука

 

Для джеес возможно

 

В мобилках все Лиды больших команд это выпиливают:)

 

Если ты точно и хорошо понимаешь как оно работает, то проблем не вызывает, а и даже имеет свои преимущества. Это не лучше или хуже чем многопоточность, оно другое

 

вообще не представляю как без асинхронности жить

 

Поэтому тренд Дарта в асинк смущает

 

Сколько людей на проекте поддерживает твой код? Мне так, просто интересно

 

а сколько надо?

 

Ты тоже видимо из джеес?

 

а какая разница?

 

го тоже не нравится?

 

там по сути та же асинхронщина технически

 

нет, но и мобильная разработка не основной мой хлеб, это просто хобби

 

Большая. В большой команде нужно что-то переиспользоваемое

 

То есть, один. Да одному можно пилить как хочешь

 

асинк переиспользуемый

 

если что

 

уверен что от го может быть взрыв мозга, там ещъ сложнее с горутинами

 

технически работают они примерно так же (с небольшими ньюансами)

 

ну у нас 5 на беке и 5 на фронте, и никаких проблем с асинхронщиной

 

как раз соль в нюансах

 

Как много ты работал в проде с асинками?

 

Фронт это веб

 

Ты на каком языке через async пишешь?

 

и что?

 

То, что у js нет альтернативы async

 

И бек я думаю что на ноде или на шарпе, если там асинк

 

?? да ладно? а как же раньше жили?

 

Раньше никак не жили. Для фронта ничего другого и нет

 

А что?

 

js вообще синхронный и однопоточный, если что

 

Вообще да

 

ну и приходилоссь городить костыли, пока не появился async/await

 

Ну вот я о том же. Что у тебя альтернатив нет. Вот и вся петрушка

 

как нет? пиши по старому, только приложение твоё будет неотзывчивое, зато понятное )

 

Скажи как много ты работал с асинком, чтоб мы могли реально оценить ты говорить реально о своем опыте в асинке или просто желания или незнания в этой теме.

 

либо представлять собой лапшу непонятную из колбеков

 

У нас то нет опыта в мультипоточном программировании

 

а у тебя?

 

Это не альтернатива

 

Я сейчас поддерживаю плюсовую либу на future и она у меня вызывает боль

 

А в js я webworker пробовал. Ибо это хоть как-то можно использовать

 

Ну плюсы сами по себе сложней ведь чем дарт/жс/шарп

 

Это проблемы без относительно языковых конструкций

 

Как бы может дело не совсем в future а в связке с плюсами

 

Что-то мелкое писать - нормально. Pet project шикарно.

 

в смысле?

 

Ну я тоже так по началу считал

 

ну у меня проект очень большой на асинках

 

и команда не из одного человека

 

Потому что это не альтернатива

 

Язык какой

 

Но ведь асинк - это проблемы без относительной привязки к языку, верно?

 

Ты говоришь, что использовать колбеки. Это не многопоточность

 

хорошо, я так понял ты из мира ios, ты реально делаешь dispatch_sync ?

 

везде?

 

Да но я говорю, что к тебя альтернативы нет.

 

Есть, еще есть пхп

 

async тоже

 

Там есть несколько вариантов реализации многопоточности. Но вообще да

 

убедил. В js вообще многопоточности нет

 

Выбор между callback и async я бы тоже выбрал async

 

Тут сложно спорить

 

ты можешь использовать в дарте изоляты

 

Я пока хз что это. Но обычные либы придётся переделывать

 

Невозможно писать что-то своё, принципиально отличающееся от общего code style

 

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

 

Спасибо:)

 

так сразу же сказали что он однопоточный )

 

мы вкурсе

 

Мы ж не говорим что это альтернатива, мы говорим что это нормальная штука

 

потому что от её наличия мало что меняется, если ты всё равно ждёшь результат работы, и не можешь бежать дальше

 

Я уверен, что ты классный разработчик, но давай на этом просто остановимся

 

простой пример, тебе надо. дёруть 2 апи эндпоинта и после успеха обоих показать резльтаты, ты это синхронно делать будешь?

 

судя по dispatch_sync да

 

Это можно сделать по-разному. Например, добавлять в очередь на выполнение.

 

Или делать всё синхронно в параллельном потоке

 

дык получится то же что и с асинком

 

ты откладываешь исполнение и ждешь результат

 

что с потоками, что с очередью

 

В моем случае свободы выбора больше

 

только это займёт времени больше, чем асинхронно выполняя оба запроса

 

[
{
"type": "link",
"text": "https://startflutter.com/"
},
"\nЕсть такая вещь но чисто с анимациями?"
]

 

это можно сделать на любом языке )

 

Ты понял, что написал?

 

конечно

 

Что больше времени займет

 

Ты асинку приоритет не дашь

 

И будешь обязан ждать выполнения в том же потоке

 

да, сначала ждёшь один запрос, потому другой, асинхронно они бегут уже оба

 

В зависимости от того, как ты это сделаешь

 

Ты это можешь одновременно делать, конечно, омг

 

одновремено синхронно?

 

все ио операции асинхронно работают практически одновременно

 

в отличии от синхронности

 

В разных потоках

 

В данном случае без разницы в каком потоке будет работать, многопоточность будет работать преимущественно только если ты работаешь с синхронным кодом.

 

синхронно, в разных потоках одновременно?

 

Фактически, что самое важное, ты полностью абстрагируешь классы от знания , что они async

 

Ну да. Тут система сложнее, чем js.

 

где тут?

 

В iOS есть обычные сишные потоки, всякие сигналы и обертки на ними

 

Это он про многопоточность

 

Есть три обычные обертки : nsthread, dispatch, и nsoperation

 

Вместе это весьма голодные ингредиенты для создания хороших классов с достаточным уровнем абстракции, что классы не обладают знаниями о потоках без должной необходимости. Что даёт понятное тестирование и переиспользование. Ну и прочие плюшки. Async слишком плоско в этой вселенной. Хотя, кто вещи писать, где-то можно было бы и проще. Если тут есть годные многопоточные программисты, поправьте меня, почему, если я в чем-то неправ.

 

Ты очень критично говоришь, асинг априори лучше синхронщиты в ио, но асинк однозначно хуже при синхронных операциях, он дешевле в ресурсах, он проще

 

нельзя говорить что это говно, им пользуются много людей и у них нет проблем в поддержке

 

Я не говорю, что говно. У него есть область применения. Но не надо говорить, что это бест, и им все пользуются. Именно с этого и начался и наш спор

 

Госпади

 

В js реальный многопоток - это webworker. Остальное синтаксис, чтобы не было совсем грустно бросать callback через сотню функций

 

А о чем вы хоть холиварили?

 

Об асинках

 

А чаво именно?

 

Мне говорили, что нет им альтернативы. И ими все пользуются.

 

Ну понятно, опыта нет. Действительно пора заканчивать.

 

В каком контексте?

 

Ну куда мне до тебя:)

 

Хочется синхронных альтернатив для всякого рода io?

 

Причем тут я?

 

Если я тебя правильно понял, то да

 

Ну тут проблема в архитектуре флаттера. Все нативные вызовы через каналы и поэтому асинхронные.

 

Ну я о том же. Меня смущает, что это обязательное правило

 

Не не, мы не так говорили. мы говорили что это прекрасная замена синхронщине а не многопоточности

 

Будто бы это замена одного другому, лол. Пусть. Действительно посмотрит на го например

 

там то же по сути асинхронщина

 

оно тоже однопоточное

 

Ничего подобного, сборка идёт с отптмизацией под определенное количество ядер проца. У меня 8 тредов, но около 100к операций

 

Видимо, мы друг друга не поняли

 

Я же сказал, что ты прекрасный разработчик

 

Ты мне льстишь

 

Никто тебе не говорил что многопоточность это плохо, говорили что асинхронность хороша. И это не отменяет многопоточность, а только дополняет. Нужно меньше кода писать, не теряя при этом в производительности в общих случаях.

 

ну он может раскидывать, но по сути принцип не очень сильно отличается

 

Только придется бороться с дедлоками, решать проблемы с синхронизацией и ТД вручную.

 

Если код синхронный и я запущу на многоядерном проце код с тремя (допустим) корутинами, они ведь по очереди будут выполняться а не одновременно?

 

горутина не может быть синхронная, она сделана чтобы работать параллельно )

 

Вот такой простой код что выведет как думаешь?

 

При условии что у меня не однояредный проц

 

[
"что тут думать? всё написано в доке ",
{
"type": "link",
"text": "http://golang-book.ru/chapter-10-concurrency.html"
},
""
]