Доступен (https://github.com/tinygo-org/tinygo/releases) выпуск проекта Tinygo 0.7.0 (https://tinygo.org/), в рамках которого развивается компилятор языка Go для областей, в которых необходимо компактное представление результирующего кода и низкое потребление ресурсов, таких как микроконтроллеры и компактные однопроцессорные системы. Код распространяется (https://github.com/tinygo-org/tinygo/) под лицензией BSD.
Компиляция для различных целевых платформ реализована при помощи LLVM, а для поддержки языка применяются библиотеки, применяемые в основном инструментарии от проекта Go. Скомпилированная программа напрямую может запускаться на микроконтроллерах, позволяя применять Go в качестве языка для написания сценариев автоматизации.
Мотивом создания нового проекта послужило желание использовать привычный для себя язык Go на компактных устройствах - разработчики рассудили, что если существует вариант Python для микроконтроллеров, то почему бы не создать подобное для языка Go. Go выбран (https://tinygo.org/faq/why-go-instead-of-rust/) вместо Rust так как он более прост в изучении, предоставляет независимую от реализаций потоков поддержку распараллеливания на основе сопрограмм и предлагает обширную стандартную библиотеку ("батарейки входят в комплект").
В текущем виде поддерживается 15 моделей микроконтроллеров, включая различные платы Adafruit, Arduino, BBC micro:bit, ST Micro, Digispark, Nordic Semiconductor, Makerdiary и Phytec. Программы также могут быть собраны для запуска в браузере в формате WebAssembly и в виде исполняемых файлов для Linux.
Ключевые цели проекта:- Генерация очень компактных исполняемых файлов;
- Поддержка наиболее распространённых моделей плат микроконтроллеров;
- Возможность применения для Web;
- Поддержка CGo с минимальными накладными расходами при вызове функций на языке Си;
- Поддержка большей части стандартных пакетов и возможность компиляции типового существующего кода без его изменения.
Не входит в число основных целей поддержка многоядерных систем,
эффективный запуск огромного числа сопрограмм (сам по себе запуск сопрограмм поддерживается в полной мере), достижение уровня производительности эталонного компилятора gc (оптимизация отдаётся на откуп LLVM и в некоторых применениях Tinygo может оказаться быстрее gc) и полная совместимость (https://tinygo.org/lang-support/) со всеми приложениями на Go.Основным отличием от похожего компилятора emgo (https://github.com/ziutek/emgo) является попытка сохранения оригинальной модели управления памятью Go с использованием сборщика мусора и задействование LLVM для генерации эффективного кода вместо компиляции в представление на языке Си.
Из изменений в выпуске 0.7 отмечается реализация команды "tinygo test", обеспечение поддержки сборки мусора для большинства целевых плат (на базе ARM Cortex-M) и WebAssembly, поддержка платы HiFive1 rev B на основе архитектуры RISC-V и платы Arduino nano33,
улучшение поддержки языка (поддержка битовых полей с использованием геттеров и сеттеров, поддержка анонимных структур).
URL: https://github.com/tinygo-org/tinygo/releases
Новость: https://www.opennet.ru/opennews/art.shtml?num=51126
Под ESP32 кто-нибудь пробовал это дело?
Жаль поддержки ESP32 нет, а было бы просто огонь:
- хорошая поддержка веб-технологий;
- горутины (а эта железка двухъядерная).Хотя наличие какой-нибудь простенькой RTOS не помешало бы...
> Генерация очень компактных исполняемых файлов;
Лень по ссылкам ходить, насколько компактно? Вес Hello World исчисляется не в мегабайтах? Любители Go, не минусуйте - в контексте встраиваемых систем "настольный" Go действительно весьма жирный.
> поддержка платы HiFive1 rev B на основе архитектуры RISC-V
Вот это кстати хорошо.
Немного оффтоп: лично меня печалит, что беспроводные коммуникации = проприетарные блобы. Wi-Fi (те же ESP-шки, которые впихнули в одну из RISC-V плат), Bluetooth, а уж про GSM/GPRS вспоминать страшно... Медленное, но верное рподвижение RISC-V радует, надеюсь что однажды кто-нибудь сможет родить по-настоящему свободный Wi-Fi чип.
Во что нашёл:
https://tinygo.org/faq/what-about-esp8266-esp32/
>- горутины (а эта железка двухъядерная).И они никак не связаны с многоядерностью, асинхронность не всегда равно параллелизм. Так что не вижу тут никакого преимущества для многоядерных процах по сравнению с другими языками. К тому же по дефолту (по крайней мере так было) рутины запускаются на 1 ядре, поочерёдно переключаясь, так как работа с потоками ОС не такая уж и дешёвая вещь.
По дефолту уже давно горутины запускаются не на одном ядре. И потоки ОС почти не используются (запускается столько потоков сколько ядер, а дальше уже свой планировщик)
> Любители Go, не минусуйте - в контексте встраиваемых систем "настольный" Go действительно весьма жирный.Любая статически скомпилированная прога будет столько весить (а микрики как раз статично собранные, ибо там не то что shared library, там ОС то нет).
Ничего подобного. Дело даже не в том, что у Go весьма жирный рантайм, а в самой «модели памяти», которую сии деятели героически пытаются протащить на МК. При малом объёме оперативки вообще кучу использовать противопоказано, не говоря уже про GC.
> Любая статически скомпилированная прога будет столько веситьДа что вы такое говорите?
frog@frog-ThinkPad-X240 /tmp> cat q.c
#include <stdio.h>
void main()
{
printf("Hello World\n");
}
frog@frog-ThinkPad-X240 /tmp> gcc q.c -static
frog@frog-ThinkPad-X240 /tmp> ls -la a.out
-rwxrwxr-x 1 frog frog 844696 Jul 20 10:54 a.out*
frog@frog-ThinkPad-X240 /tmp>
Не умеешь.
$ musl-gcc q.c -static
$ ls -l a.out
-rwxr-xr-x 1 user user 26064 июл 20 11:12 a.out
Не бьется что то
#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}gcc q.cc -static
ls -l844696 июл 21 09:48 a.out
70 июл 21 09:48 q.cc
Ну и для сравнения:
$ cat q.go
package mainimport "fmt"
func main() {
fmt.Println("Hello World")
}
$ go build
$ ls -l hello
-rwxr-xr-x 1 user user 1906945 июл 20 11:16 hello
package main
func main() {
print("Hello World!\n")
}
go build -ldflags -s hello.go
ls -l hello
-rwxr-xr-x 1 Unit RedstarOS 760160 Jul 28 18:16 hello
и это он еще man strip не прочитал!
> так как он более прост в изученииА вот мне он очень трудно даётся, после C-подобного синтаксиса в разных языках постоянно в голове крутится вопрос "зачем так сделали вообще"
Попробуй метапрог, вот там-то заживём!</sarcasm>
Дык реально заживем. По твоему вот то что выше - лучше?
У Go вполне себе C-подобный синтаксис. Слегка упрощённый (можно не ставить лишние скобочки и разделители).
Таки плюсую
Не надо, плюсы то еще го*но монструозное. Даже Страуструп там уже ногу сломает.
Не спорю, у Go синтаксис ближе к С, чем к тому же Python. Но, например, зачем было делать 2 способа объявить переменную, оставлять возможность variable shadowing - чтобы потом ловить лулзов на этапе дебага и впиливать в go tool ещё один флаг проверки? Или, например, синтаксис методов на структуре - его вообще упорыш писал. Ладно, нет в языке классов, наследования и вот этого всего - но сделать человеческий синтаксис, чтобы в теле структуры можно было обьявить метод без тонны ((())) наверное можно было? Прямо современный язык, на котором писать сложнее чем на С. Даже жабоскрипт в этом плане куда проще и красивее.
> сделать человеческий синтаксис, чтобы в теле структуры можно было обьявить методЗачем тебе его там объявлять? Чтобы дублировать один и тот же прототип в двух местах, как в сишечке? Так в сишечке это не от хорошей жизни сделано.
Дык в этом-то и вопрос - зачем в современный ЯП тащит конструкции из С? Я считаю, что следующая запись куда проще парсится гдазами:type Foo struct {
func Bar() string { ... }
}Сразу видно, где метод как операция над структурой, а где просто глобальная функция. А в обычном Go-шной записи мне приходится смотреть на тип в скобках - вдруг там какой-нибудь саботажник в том же файле воткнул функцию для другого типа? Вот эта запись просто вызывает вопрос - зачем мне нужен Go, если я так же могу написать на С?:
type Foo struct {
}func (f Foo) Bar() string { ... }
Вообще, горный синтаксис лучше выглядят в результатах грепа: хочешь найти, где метод объявлен, грепаешь, и сразу видишь, на каких типах он объявлен.А с С++/Java/etc синтаксисом приходится лезть в файл и искать начало объявления класса.
Безусловно, с навороченными IDE это все не проблема. Но иногда хочется использовать VIM.
В C++ никто не запрещает писать определение метода вне определения класса. Собственно, обычно так и делают, если только речь не идёт о шаблонах и/или предназначенной для инлайнинга мелочи.
> Я считаю, что следующая запись куда проще парсится гдазами:
>
> type Foo struct {
> func Bar() string { ... }
> }Такая — проще, да. А вот когда на месте «...» оказывается несколько десятков строк, и число методов тоже начинает измеряться десятками, — уже не проще.
структура есть сучность хранения данных. методы досступа к оным (к модификации,чтению, созданию нового etc) - это не к структуре. (ладно, в крестах - да, но то - кресты...)
Правильно, пусть дальше будем жрат тормозной JS!
js хоть просмотреть можно (возникни у меня такое извращенное желание)..
Вообще-то очень забавно рассматривать браузер как среду для исполнения кода))
> js хоть просмотреть можноЕго сейчас всюду минифицируют... Толку немного.
> js хоть просмотреть можноhttps://code.jquery.com/jquery-3.4.1.min.js - чайтате, пожалуйста. И это ещё без обфускатора.
Убедил. Поэтому давно использую технику блокировки всех сторонних js, чтобы не сталкиваться с подобными простынями :) Ну не нужны мне ПРИЛОЖЕНИЯ в браузере.
> не нужны мне ПРИЛОЖЕНИЯ в браузере.Вот с этого и нужно было начинать.
Сейчас всё идет к тому, что в браузере будут всё более мощные и крутые приложения (уже, собственно), в частности без убогого дома и с wasm.
Нет смысла этому противиться.
Проблема в том, что эти какбы-приложения по существу все равно внешние сервисы. Да и использование браузера как среды выполнения выходит все равно довольно накладно, и тут ничего сделать нельзя. То есть никаким прогрессом тут и не пахнет..
доставка приложений, обновлений, не нужна установка, плюсов тоже хватает
> Сейчас всё идет к тому, что в браузере будут всё более мощные и крутые приложения (уже, собственно), в частности без убогого дома и с wasm.Где-то я что-то подобное уже слышал лет 15 назад. Только вместо wasm фигурировал flash.
>> Сейчас всё идет к тому, что в браузере будут всё более мощные и крутые приложения (уже, собственно), в частности без убогого дома и с wasm.
> Где-то я что-то подобное уже слышал лет 15 назад. Только вместо wasm фигурировал flash.Java апплеты, ActiveX. Причем, совсем не примитив:
https://www.csm.ornl.gov/~geist/java/book/Cool-Applets.html (1997, на тех компютерах модный^W современный JS феймворк вообще в память не влезет, не говоря уже о JS движках с JIT)или из более современного:
http://coolapplets.blogspot.com/
> Поэтому давно использую технику блокировки всех сторонних jsОх и не завидую я тебе
А что толку-то? К DOM'у всё равно толком не проберёшься.
Справедливости ради, JS - один из быстрейший интерпретируемых языков. Браузерные войнушки пошли ему на пользу за последние десять лет.
а больное место браузера -- тормозной DOM, который в идеале заменить бы на WebGL / WebAssembly
Больное место браузера - возможность гонять код вместе с данными и менять его в любой момент,напрочъ убившее любые осмысленные стороние (и подконтрольные пользователю) клиенты
>а больное место браузера -- тормозной DOM, который в идеале заменить бы на WebGL / WebAssemblyИшь чего удумали, текст с сайтов копировать! Дадим им картинку, пусть утрутся.
Будем скриншотить и прогонять через OCR. Чёрт, звучит как идея для дополнения (если они к тому времени останутся).
останутся, но доступа к изображению на странице у них не будет, для вашей большей безопастносте - а то ж они его могут - украсть!
DOM не такой уж тормозной, просто не надо его использовать как хранилище данных.
Убийца раста.
Смотря на различный код, Раст, пускай и многословней, но на вид как-то поадекватнее Го
Так что пускай лучше живёт
Адекватнее. Одни сплошные сголашения и синтаксис просто хакерский какие-то двоеточия вертикальные пайпы блоки выполнения. Ну нахрен.
Да, синтаксис не очень красивый. Но если разобраться поглубже - то становится понятно, что в расте всё на своих местах.
А вы не хакер случаем?
> А вы не хакер случаем?Хyякер
Не, это разные языки. Сферы их применения пересекаются, но не совпадают.
> компактное представление
> LLVMКак-то не верится.
Вот добавить бы упралвение подкапотными потоками (создавать, удалять, группировать в группы и т.д.) ну цены бы не было, а так приходиться изгаляться всякими GetOSLockThread.
А да еще хорошо бы более прозрачную интеграцию с C runtime и вообще бы цены небыло, а так какая игрушка.
И у нас там был недалеко топор. И мы подумали — может топор запустить?! Отсюда и родилась мысль — сделать летающий топор. (c)
Откуда это? Хочу почитать ...
В поиск вбей, что ты как маленький.
Какая-то токсичная газета, вы не находите?
То есть летающий топор это нормально, а гезета значит токсичная. Да помоему это все идиотизм вмесете взятое,
Хорошо, в следующий раз просто кину ссылку на DuckDuckGo с соответствующим запросом.
> разработчики рассудили, что если существует вариант Python для микроконтроллеров, то почему бы не создать подобное для языка GoРассуждение из области "вон кто-то намусорил, значить почему бы и мне не намусорить?".