В состав проекта LLVM принят (http://llvmweekly.org/issue/42) начальный набор биндингов (http://reviews.llvm.org/rL219976) для обеспечения поддержки развиваемого компанией Google языка программирования Go (http://golang.org/), который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Принятый код основан на наработках проекта LLVM Go (https://github.com/go-llvm/llvm), разработчики которого согласились перелицензировать код под лицензией LLVM и предложили (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/0776...) свою работу для включения в основной состав LLVM.Включение биндингов в состав LLVM является необходимым условием дальнейшей интеграции в LLVM фронтэнда с компилятором для языка Go (llgo (https://github.com/go-llvm/llgo)), который построен с использованием данных биндингов. Ожидается, что поддержка языка Go войдёт в состав следующего выпуска LLVM 3.6. Поддержка языка Go в GCC была добавлена (http://www.opennet.me/opennews/art.shtml?num=30035) весной 2011 года.
URL: http://llvmweekly.org/issue/42
Новость: http://www.opennet.me/opennews/art.shtml?num=40936
И 0 комментариев. Всем пофиг?
да
А что еще говорить?
gccgo пока не нужен, т.к. там не работают goroutine и работает он только под *nix (ну или только под GNU/Linux).Что касается llgo, то ничего сказать не могу, т.к. не работал с ним.
Лично мне хватает официального компилятора Go, может быть он и не самый лучший в плане оптимизации, но над этим активно работают и улучшают от версии к версии.
>gccgo пока не нуженЧувствуется эксперт. gccgo умеет линковаться с динамическими библиотеками, в отличие от официального компилятора.
>только под *nixОстальные системы не нужны.
>активно работают и улучшаютgccgo с небольшим запаздыванием включает все фичи. Goroutine доступны с линковщиком gold.
> gccgo умеет линковаться с динамическими библиотеками, в отличие от официального компилятора.Ты так говоришь, как будто это что-то хорошее
> Чувствуется эксперт. gccgo умеет линковаться с динамическими библиотеками, в отличие от официального компилятора.В офф. компиляторе этого нет, потому-что в Go изначально этого нет.
Да и потом, с чего это нет? import "C" даст вам все что угодно. Я так SSE через ассемблерные вставки использовал.
Да и потом, лично мне Go нравится из-за статичной линковки. А так, я соберу у себя программу с помощью gccgo, а на другой машине будет другая версия gccgo (или не будет), у которой ABI поломано.
>там не работают goroutineРаботают вполне.
>работает он только под *nix (ну или только под GNU/Linux)
Ну, чего поделаешь. Однако чаще всего на Go пишут серверные приложения, которые запускают под *nix.
> Работают вполне.Ну уж извините, я бедный, у меня нет золота.
> Ну, чего поделаешь. Однако чаще всего на Go пишут серверные приложения, которые
> запускают под *nix.Ну я на нем только клиентские писал. Хотя была одна серверная, но нужно было учитывать возможность поднятия под Windows.
>защищённость от ошибокГромко сказано. Не от всех ведь ошибок? Даже в описании Rust сказано "защищённость от распространённых ошибок".
имеются ввиду сборка мусора и bounds checking
Отличная новость!
Интересно, а в чем заключается поддержка Go со стороны LLVM? Иными словами что такого есть в Go, что недостаточно стандартных возможностей LLVM и нужно делать какие-то биндинги? Для Rust есть аналогичная "поддержка со стороны LLVM"?
> Иными словами что такого есть в Go, что недостаточно стандартных возможностей LLVM и
> нужно делать какие-то биндинги?Ну, во-первых, llgo написан на Go, и ему хотелось бы как-то вызывать библиотеки LLVM. Конструктор байт-кода, например.
Хотя, конечно, я думаю, теоретически, может быть, наверное, он мог бы выплевывать LLVM IR самостоятельно, а потом просто вызывать llc.
> Ожидается, что поддержка языка Go войдёт в состав следующего выпуска LLVM 3.6.Только взялись интегрировать, и уже в следующем релизе! Это радует.
Вот бы они так с openmp поступили. А то говорят уже более года, а успеть и до 3.6 под большим вопросом.