Go, напротив, реализует подход communicating sequential processes (CSP).
CSP и реактивное программирование не взаимоисключающи.
Более того, это частая ошибка новичков в Go, узнав про каналы и горутины начинать их использовать везде – даже там где достаточно простого вызова функции. Так что наличие CSP в языке, не означает, что необходимо везде это использовать.
Тони Хоар ещё в 1975 писал, что борьба с любителями избыточной сложности это будет долгий и нелегкий процесс, но вот такие посты прям показывают, что через 50 лет это не борьба, а война просто :)
В 2009 горутины были прорывом (наверное. Я в C# пользовался тасками примерно тогда же). Сейчас же это мейнстрим в большинстве языков.
Горутины сами по себе не были новыми и не они есть причиной успеха Go для concurrent-кода. Новинкой была имплементация CSP-подобной логики как часть языка, и этого, насколько мне известно, пока в других языках нет.
Спасибо, вот что-то подобное Wi-Fi Direct я очень давно хочу, чтобы было из коробки и стандартно для всех девайсов, но пока это далеко от истины. iOS-устройства, например Wi-Fi Direct не поддерживают, у них там своя технология.
Спасибо. Да, чуть выше обсуждали уже альтернативные коды. У QR кодов всё-таки главный плюс это встроенная поддержка в мобильных SDK и вообще везде. Я могу такой анимированный QR сгенерировать даже через Apple Shortcut скриптинг :) Less is more.
Спасибо. Да, безусловно, это пока эксперимент, и для более-менее серьезных продакшн проектов ещё сыроват. Там есть свои проблемы (связанные, опять таки, с фактом того, что в итоге всё равно JS на выходе) – например при частом обновлении виджета из горутины (прогрессбар быстрый, допустим), может понадобится вручную вызывать `runtime.Gosched()` иначе виджет не будет обновляться.
Так что на данном моменте как полноценную замену существующих стеков для фронтенда не могу рекомендовать.
Я не употреблял слово «кроссплатформенность».
Была конкретная задача использовать код на трёх платформах и ни один из вышеприведённых языков не позволял сделать это достаточно просто.
Инструмент инструменту рознь. Мнение о том, что все инструменты одинаково хорошо, «просто нужно их получше узнать» мне чуждо, и, честно говоря, считаю его крайне вредным. Все программисты должны понимать, что выбор инструментов очень сильно будет влиять на их работу, продуктивность и даже дальнейшую судьбу. Но умение отличать плохие инструменты от хороших приходит с опытом, конечно.
Про постоянную величину сложности фреймворков – это вот сильно мимо. Интересно было бы послушать, как вы пришли к такому выводу.
Я действительно не знаю способов использовать код на Java, Python или JS на ноутбуке, в вебе и в iOS и Android проекте. Возможно, нужно было добавить, что "непортируемым, в сравнении с Go", потому что в Go это всё однострочные команды и меньше секунды ожидания:
Ну, настолько я усложнять не хочу — почти любое решение тут сильно ограничивает круг применения. Я вот только сегодня понял, что такую анимированную гифку даже Apple-овские Shortcuts скриптинг может сделать – можно сказать «Сири, сгенерируй-ка мне QR из последнего скриншота», и скрипт возьмёт скриншот, разобъет на куски (вот тут еще не уверен, умеет ли такое), сгенерирует QR на каждый и склеит в GIF-ку (такое точно умеет). В общем, less is more.
Да и дорого слишком реализовывать протокол с подтверждениями – Шэннон не одобряет :) Я буду чуть позже фонтанные коды реализовывать, чтобы проблему с ожиданием цикла решить.
Узнать может и не сложно, но что делать, если генерация заняла больше времени, чем задержка между кадрами? (а там почти всегда так). А горутины всё равно в скомпилированному JS будут в одном потоке работать.
принимающей стороны кадры должны быть синхронизованы с передающей?
Как раз нет — рассинхронизация частот будет влиять только на общее время передачи, но всё равно будет работать. Я там в описании идеи протокола немного объяснял этот момент — фреймы можно вообще в любом порядке принимать.
CSP и реактивное программирование не взаимоисключающи.
Более того, это частая ошибка новичков в Go, узнав про каналы и горутины начинать их использовать везде – даже там где достаточно простого вызова функции. Так что наличие CSP в языке, не означает, что необходимо везде это использовать.
Горутины сами по себе не были новыми и не они есть причиной успеха Go для concurrent-кода. Новинкой была имплементация CSP-подобной логики как часть языка, и этого, насколько мне известно, пока в других языках нет.
Именно, третьего порядка.
Точно, респект. )
Так что на данном моменте как полноценную замену существующих стеков для фронтенда не могу рекомендовать.
Была конкретная задача использовать код на трёх платформах и ни один из вышеприведённых языков не позволял сделать это достаточно просто.
Инструмент инструменту рознь. Мнение о том, что все инструменты одинаково хорошо, «просто нужно их получше узнать» мне чуждо, и, честно говоря, считаю его крайне вредным. Все программисты должны понимать, что выбор инструментов очень сильно будет влиять на их работу, продуктивность и даже дальнейшую судьбу. Но умение отличать плохие инструменты от хороших приходит с опытом, конечно.
Про постоянную величину сложности фреймворков – это вот сильно мимо. Интересно было бы послушать, как вы пришли к такому выводу.
Нет, не шутка.
Я действительно не знаю способов использовать код на Java, Python или JS на ноутбуке, в вебе и в iOS и Android проекте. Возможно, нужно было добавить, что "непортируемым, в сравнении с Go", потому что в Go это всё однострочные команды и меньше секунды ожидания:
Windows PE
GOOS=windows go buildLinux ELF
GOOS=linux go buildMacOS X Mach64
GOOS=darwin go buildiOS Framework
gomobile bind -target=ios .Android AAR Native Code
gomobile bind -target=android .Web (JS)
gopherjs buildИ это всё фактически из коробки (
gomobileиgopherjsставятся отдельно также однострочниками).Да и дорого слишком реализовывать протокол с подтверждениями – Шэннон не одобряет :) Я буду чуть позже фонтанные коды реализовывать, чтобы проблему с ожиданием цикла решить.
Здорово, спасибо за ссылку.
Вот ещё очень подробный разбор, только обратного процесса и с интерактивом — https://www.nayuki.io/page/creating-a-qr-code-step-by-step
Ага, есть вот даже такой проект: https://github.com/claudiodangelis/qr-filetransfer
Узнать может и не сложно, но что делать, если генерация заняла больше времени, чем задержка между кадрами? (а там почти всегда так). А горутины всё равно в скомпилированному JS будут в одном потоке работать.
Как раз нет — рассинхронизация частот будет влиять только на общее время передачи, но всё равно будет работать. Я там в описании идеи протокола немного объяснял этот момент — фреймы можно вообще в любом порядке принимать.