После шести месяцев разработки компания Google сформировала (https://blog.golang.org/go1.7) релиз языка программирования Go 1.7 (http://golang.org), который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов (http://golang.org/pkg/runtime/)), что позволяет добиться производительности, сопоставимой с программами на языке Си.Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, в том числе предоставляя реализованные на уровне операторов средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за допустимые области выделенных блоков памяти и обеспечивает возможность использования сборщика мусора.
Основные новшества (http://golang.org/doc/go1.7), представленные в выпуске Go 1.7:- Новый бэкенд (https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr... компилятора, использующий промежуточный код на базе SSA (https://ru.wikipedia.org/wiki/SSA) (Static Single Assignment). SSA предоставляет низкоуровневые операции, которые во многом отражают обычные машинные инструкции, за исключением того, что предоставляют возможность работы с неограниченным числом регистров. Применение SSA позволяет задействовать при сборке дополнительные классы оптимизаций и, соответственно, добиться увеличения производительности результирующего кода. Например, появляется возможность выявить ситуации в которых проверки выхода за границы не имеют смысла или можно исключить части выражений. В среднем прирост производительности оценивается в 5-35%. Для разработчиков бэкенд на базе SSA предоставляет (https://pauladamsmith.com/blog/2016/08/go-1.7-ssa.html) ряд расширенных средств аналитики, позволяющих на низком уровне проанализировать ход компиляции и принятые решения по оптимизации. Новый бэкенд пока доступен только для архитектуры amd64;
- Во фронтэнде компилятора задействован новый более компактный формат экспорта данных и обеспечен более эффективный импорт определений. Данные изменения позволили значительно ускорить компиляцию и на 20-30% сократить размер исполняемых файлов;
- Внесены оптимизации в сборщик мусора, которые позволили немного увеличить производительность и значительно сократить паузы при сборке мусора в программах с большим числом неактивных потоков (goroutines);- Внесены оптимизации в различные модули стандартной библиотеки. Например, ускорение более чем на 10% отмечено в библиотеках
crypto/sha1, crypto/sha256, encoding/binary, fmt, hash/adler32, hash/crc32, hash/crc64, image/color, math/big, strconv, strings, unicode и unicode/utf16;
- Реализован порт для Linux на IBM z Systems (s390x);- В состав стандартной библиотеки включён пакет golang.org/x/net/context (http://golang.org/x/net/context), популярный среди разработчиков сетевых приложений и микросервисов. Начиная с Go 1.7 данная библиотека доступна под именем context (https://golang.org/pkg/context/) без префикса "/x/net/".
Поддержка модуля context добавлена в штатные пакеты net/http и os/exec;
- Директория vendor (https://golang.org/s/go15vendor), предназначенная для поставки внешних зависимостей, привязанных к определённому поставщику, переведена в разряд неотключаемых возможностей.
URL: https://blog.golang.org/go1.7
Новость: http://www.opennet.ru/opennews/art.shtml?num=44972
Например можно уже его использовать как язык общего назначения? Библиотечки всякие разные, например конекторы к базам понаросли?
Конечно, пишу на нем 2 года, помимо коннекторов к базе в нем key/value базы появились
Ответил сам себе и отмодерировал последующую дискуссию, вот тебе и opennet, вот тебе и аноним
Как будто не разработчики пишут библиотеки, а они сами "наростают", смахивает на теорию эволюции.
Так и есть, эволюция. Разработчики пишут, кто-то использует. Удачно написанное и многими используемое становится стандартом де-факто, который реально можно использовать в рабочих проектах.
Возможна ситуация, когда используемая библиотека вымирает в процессе такой эволюции. Так что пишущие всерьез и обеспечивающие поддержку гонятся не столько за новшествами, сколько за уверенностью, что оно не будет заброшено и забыто через пару лет.
Ибо переписывать уже запущенный проект в погоне за прогрессом - это очень нехорошо...
лучше бы под солярис нормальный порт сделали
И под OS/2, да и под TR-DOS не помешало бы...
под os/390 хачу
Так есть же...
А у меня в спектрум флешка с линухом не вставляется, поэтому мне без разницы.
Пользователи BeOS негодуют!
Так то для Linux OS390, а вот для z/OS USS/MVS бы...
>лучше бы под солярис нормальный порт сделалиСоляра - как бы проприетарный продукт, это - раз.
Популярность которого - ниже плинтуса и стремительно сворачивается в вообще ничто - это два.
Так кому оно надо - гуглу или оракелу?! Оракель не чешется ... вывод? :(БСД к примеру стараются, у них там 3 косяка неприятных, но проблема озвучена - народ роет ...
А в соляре всё хорошо - всем пофиг :( А ведь было время ... а да чего там! Как солнце закатилось - всем всё понятно было :(PS: Вот голубым тоже надо, дык они тоже и тормошили и контрибутили - результат смотри в новости :)
Полноценных биндингов к Qt или GTK так и не появилось?inb4, все эти проекты с подписью experimental и is not recommended for any real use не предлагать.
Так это от официальных выпусков никак и не зависит.
Если привязки этих библиотек до сих пор не появились, значит они не особо нужны нынешним разработчикам на Go
Пишешь сам через cgo. Надежнее, да дольше, зато ничего лишнего не потянешь.
Есть какие-нибудь примеры десктопных приложений на go в дикой природе?
https://syncthing.net/
> Полноценных биндингов к Qt или GTK так и не появилось?Так вебинтырьфейсы ж в моде теперь, а все остальное устаревшее и окаменевшее ненужно из древнючей эпохи.
> Так вебинтырьфейсы ж в моде теперьНу дык. Хозяева не зря растили веб-стадо, у которого клиент-серверная архитектура в мозгу жёстко прошита. А если десктоп-либы развивать, глядишь ещё и peer-to-peer приложения начнут писать и хозяева не смогут контролировать стадо.
Поэтому вебня головного мозга во все поля!
Я тебе сейчас страшную вещь скажу, peer-to-peer можно написать даже на js в браузере.
Дженерики так и не завезли.
Там много чего не завезли и никогда не завезут.
http://tmikov.blogspot.ru/2015/02/you-dont-like-googles-go-b...:-)
Полиморфные типы лучше генериков. :P
>Дженерики так и не завезли.... и "Слава Аллаху!!!!"
Впрочем версия 1.7 ... что там в 2.* и далее будет - посмотрим.
Они там и не нужны
Рили? И как мне отличить Array<Int> от Array<String> без дженериков то? А как компайлер узнает что в эту функцию нужно передать Array<Int> и выдаст мне ошибку компиляции при попытке передать в нее Array<String>?На данный момент в Go для такой наипростейшей задачи приходится городить костыли времен Java 4. Действительно дженерики в Go не нужны, только вместе с самим Go с на пару.
> как мне отличить Array<Int> от Array<String>элементарно. у первой тип []int, у второй []string.
Бросьте, это очередной нытик, который пытается писать на языке со статической типизацией как не петоне.
> с такими достоинствами скриптовых языков, как ... защищённость от ошибокВот это - неправда, скриптовые языки плохо защищают от ошибок в целом. Может имелось ввиду от пределённого класса ошибок?
Смотрю, эта ошибка кочует из новости в новость о Go.
> Может имелось ввиду от пределённого класса ошибок?Сборщик мусора же. Позволяет уменьшить утечки памяти.
Только скриптовые языки тут ни при чём. Сборка мусора есть где угодно, даже для C.
REALY?
А что тебя удивляет то? Салага ты, всё что есть в этом мире - есть под Си! :)
Например знаменитый http://www.hboehm.info/gc/PS: Для Си даже и объекты есть :) См. гном
>Салага ты, всё что есть в этом мире - есть под Си! :)Де Бил.
Да я понял кто ты, ну не расстраивайся - ты держись там! :)
>> с такими достоинствами скриптовых языков, как ... защищённость от ошибок
> Вот это - неправда, скриптовые языки плохо защищают от ошибок в целом.
> Может имелось ввиду от пределённого класса ошибок?Имелось в виду, что он заставляет программиста рассматривать ошибки как значения, а не просто хреначить отовсюду исключения и надеяться на лучшее.
"Why should I have written ZeroMQ in C": http://250bpm.com/blog:4
"Errors are values": https://blog.golang.org/errors-are-valuesИсключения там тоже есть, но они используются для исключительных ситуаций, а не для компенсации отсутствия стратегии обработки ошибок и отсутствия множественных возвращаемых значений (привет C++, C# и Java).
> отсутствия множественных возвращаемых значенийТы реально думаешь что в C++ нельзя вернуть структуру?
>> отсутствия множественных возвращаемых значений
> Ты реально думаешь что в C++ нельзя вернуть структуру?Ты реально думаешь, что из батона нельзя сделать троллейбус?
> return {20, std::string("baz"), 1.2f};Это по-вашему троллейбус?
Так не в том проблема. Это возможно, но ведь никто не использует эту прекрасную возможность!
Вы полагаете что у языка Go есть особая уличная магия, которой по странному стечению обстоятельств лишены все остальные языки, не позволяющая программисту на Фортране написать на нём программу на Фортране?
Я полагаю, что хорошими возможностями языка Go программисты пользуются, а С++ - нет.
И вам не кажется это, если бы оно было действительно так, немного странным?К тому же за пределами первого семестра обучения Паскалю говорить о каких-то априорно "хороших" и "плохих" возможностях сколь нибудь развитых языков было бы изрядным упрощением. Иначе люди начинают пугаться modifyIORef и Войда с подругой его, Звездочкой и писать на любом языке программы на Фортране.
Это initializer list из C++?Покажите, пожалуйста, как выглядит деконструкция такого значения, которое вернули из функции, в точке его использования.
Другими словами, еслиreturn {20, std::string("baz"), 1.2f};
возвращается из фанкции foo(), то я бы хотел увидеть LHS в выражении
whatever = foo()
Я могу там написать
int n;
std::string s;
float f;
n, s, f = foo()?
>[оверквотинг удален]
> Другими словами, если
> return {20, std::string("baz"), 1.2f};
> возвращается из фанкции foo(), то я бы хотел увидеть LHS в выражении
> whatever = foo()
> Я могу там написать
> int n;
> std::string s;
> float f;
> n, s, f = foo()
> ?Можно так:
std::tuple<int, std::string, float> foo();
int n;
std::string s;
float foo;std::tie(n, s, f) = foo();
Начиная с C++17 можно будет писать проще:
auto [n, s, f] = foo();
Спасибо!
n, s и f придётся взять в скобочки, как в Perl (только неудобней, придется добавить auto).Можно и std::tie(retval, err) = foo(), особенно - err всё равно переиспользуется постоянно, да и retval обычно какой-нибудь size_t везде один и тот же.
> Ты реально думаешь что в C++ нельзя вернуть структуру?Можно, но это не то же самое, что вернуть несколько значений. Более того, использование подобного для возврата ошибки не является общепринятой практикой в С++. Между "возможно" и "удобно" есть достаточно большая разница, чтобы существовало множество ЯП, а не один единственный.
>> отсутствия множественных возвращаемых значений
> Ты реально думаешь что в C++ нельзя вернуть структуру?Да не в этом дело. На самом деле оно вот в чём:
> Let's say that need f is called by g. g needs several values from f.
> Without multiple value return, f packs the values in a list (or vector),
> which is passed to g. g then immediately unpacks the list.
>
> With multple values, the values are just pushed on the stack. Thus no
> packing and unpacking is done.
>
> Whether this should be called an optimization hack or not, is up to you.
>> отсутствия множественных возвращаемых значений
> Ты реально думаешь что в C++ нельзя вернуть структуру?Какие-то гарантии, что это в штатном порядке сначала задействует регистры, а только потом костыли с копированием в память?
О разных механизмах обработки ошибок, их преимуществах и недостатках, можно дискутировать бесконечно.
Для Go максимально "лобовой" (если не сказать "лоботомический") способ выбран верно, если учитывать его область применения - интерны и несложный код типа "бери из сокета, кидай в сокет".
Главный минус обработки ошибок в виде проверки дополнительных возвращаемых значений в том что он крайне загромождает код и засоряет основную логику этой своей лапшой ифов, равномерно размазанной повсюду. В случае отсутствия каких-либо механизмов создания абстракций, заботливо не внесенных авторами в язык, написание более-менее сложной логики становится в любом случае делом невозможным, а простейшую засорять не страшно.
Сюрприз - исключения - это и есть значения. В тех же плюсах ты можешь throw хоть int, хоть SuperMegaObject. И имеешь абсолютно всё, чтобы обработать исключительную ситуацию. И ты не понял главную фишку исключений - автоматическую очистку при выходе из скопа. Вот ты открл файл, добавил данные в структуру, отданную как аргумнт, ещё что-то - и теперь при каждом выходе при ошибке ты должен сообразить, что в этой точке уже сделано и что надо откатывать. С исключениями же всё, что тебе нужно сделать - обработать выход из скопа. И то, что в вышеуказанной статейке приходится костылить, с исключениями ты имеешь из коробки.Прямо передо мной здоровенный сишный проект. Одна из самых больших его проблем - именно возня с обработкой ошибок, процентов 80 из которых идут вверх по стеку уровней на 5. Ну просто потому что хороший стиль - это таки много мелких специализированных функций. Что с необходимостью предполагает, что большинство ошибок форвардится.
> Сюрприз - исключения - это и есть значения. В тех же плюсах
> ты можешь throw хоть int, хоть SuperMegaObject. И имеешь абсолютно всё,
> чтобы обработать исключительную ситуацию.Это типичное заблуждение.
"Ты" имеешь только то, что передано в брошенном значении и -- всё.
Точнее, если тебе повезло с ЯП, ты имеешь ещё трейс стека в том месте,
где исключение "положило" тебе приложение (потому что в большинстве случаев они
именно так и "обрабатываются" (ну, то есть я, естественно уверен, что именно Вы
их обрабатываете по-другому, но я вижу много реального кода вокруг себя, который
писали не Вы, и там они "обрабатываются" как я написал выше)).Проблема в том, что в той точке, в которой ловится исключение, о его _контексте_
не известно совершенно ничего, и в основном всё, что с ним можно сделать полезного,
это его запротоколировать.А реальная проблема состоит в том, что в ЯП с широкой поддержкой исключений исключения
кидаются _абсолютно на всё_, и если у вас в C++ есть вот такой код:a = foo(b + c);
то исключение может быть брошено минимум в трёх местах.
А это означает, что вменяемой обработки ошибок быть не может. То, что у вас есть,
это иллюзия контроля над ситуацией.> И ты не понял главную фишку исключений
> - автоматическую очистку при выходе из скопа. Вот ты открл файл,
> добавил данные в структуру, отданную как аргумнт, ещё что-то - и
> теперь при каждом выходе при ошибке ты должен сообразить, что в
> этой точке уже сделано и что надо откатывать. С исключениями же
> всё, что тебе нужно сделать - обработать выход из скопа. И
> то, что в вышеуказанной статейке приходится костылить, с исключениями ты имеешь
> из коробки.Ну, на Go мы так и пишем:
f, err = os.Open("blah.txt)
defer f.Close()
// Если какой-то код запаникует начиная с этой точки,
// файл будет закрыт в ходе раскрутки стека.> Прямо передо мной здоровенный сишный проект. Одна из самых больших его проблем
> - именно возня с обработкой ошибок, процентов 80 из которых идут
> вверх по стеку уровней на 5. Ну просто потому что хороший
> стиль - это таки много мелких специализированных функций. Что с необходимостью
> предполагает, что большинство ошибок форвардится.Я ни в коем случае не спорю, что явная обработка ошибок это free lunch.
Более того, я считаю, что в "скриптоподобном" коде исключения, которые прерывают
выполнение это именно то, что нужно.
Но не в сложном коде, у которого задача -- работать, а не падать с красивым стектрейсом.
Дык и в Go можно возвращать bool и терять всё и вся. Или вообще ошибку не возвращать. Суть в том, что в плюсах МОЖНО вернуть всё, что угодно. То есть байки насчёт "обязательно потеряете контекст" - враньё. И из моего опыта очень мало ситуаций, когда есть смысл обрабатывать ошибку там же, где она возникла - подняться по стеку на пару-тройку уровней приходится почти всегда. С "if (err) return" мусора получается катастрофически много.И там, где в "a = foo(b + c)" может быть три исключения - в Go ровно те же три ошибки будут - с поправкой на неудобную запись вида a.set(foo(add(b, c))).
defer - хорошо, но это если код запаникует. А на ошибки придётся таки закрывать его явно?
Кстати, ровно наоборот - именно для скриптоподобного кода вообще плевать, где и как делать обработку - а вот когда код сложный, загромождать его обработкой ошибок, да ещё так, что её не может опознать и спрятать IDE - значит усложнить понимание кода. И я бы не называл обработку ошибок в стиле "if (err) return" явной - она не более явная, чем исключения - только, в отличие от них, никак от основной логики не отделена.
Ещё раз - исключения не прерывают исполнение и не "падают с красивым стектрейсом".Это вы чего-то решили, что их никто не обрабатывает. Наоборот - в отличие от возвращаемой ошибки исключения сложно проигнорировать, тем более - так, чтобы это было не видно на ревью.
> с поправкой на неудобную запись вида a.set(foo(add(b, c))).
> defer - хорошо, но это если код запаникует. А на ошибки придётся
> таки закрывать его явно?Ты явно не знаешь Go, так зачем же ты лезешь в это обсуждение?
> Ты явно не знаешь Go, так зачем же ты лезешь в это обсуждение?Берём томик Толстого. Находим во всём повествовании одну крайне сомнительную строчку. "Толстой явно не знал жизни, зачем же он написал такой толмуд"?
Я смотрю ты мастер передергивания 80-го уровня.
в гугле не ищется. видимо, кроме слова "толмуд" допущены и другие ошибки.
в си есть goto какраз для обработки ошибок
ОТкрой для себя longjump
Открой для себя чудеса отладки с longjump
> имелось в виду, что он заставляет программиста рассматривать
> ошибки как значения, а не просто хреначить отовсюду исключенияВо-первых, исключения в Go есть, но называются по другому. Во-вторых эта особенность не имеет отношение к скриптовости.
C vendor так и не разобрался, кто-нибудь подскажет?
Есть проект:
$GOPATH/main.goКоторый импортирует "github.com/.../package" (который в свою очередь имеет свои зависимости).
С гитхаба сливаю этот пакет в vendor - ошибка компиляции. Причем пробовал по-всякому размещать в vendor - с полными путями, относительными, укороченными: все равно не видит. Пробовал на 1.6
конечно не будет работать
надо обновится до Go 1.7
Эта фича включена по умолчания с 1.6
> Эта фича включена по умолчания с 1.6...а работала с 1.5 при наличии GO15VENDOREXPERIMENT=1 в переменных окружении.
Есть проект:
$GOPA
.
уж не занимается ли этот проект БУшными трубками?
> Есть проект:
> $GOPATH/main.goТак делать не надо. Заработает только для простейших проектов и быстро приведет к проблемам.
Любой проект должен быть в отдельной папке в $GOPATH/src/. Например $GOPATH/src/myproject/main.go или $GOPATH/src/github.com/username/projectname/main.go. А уже в ней или на уровень выше можно создавать vendor и класть в нее с полным путем. То есть будет что-то вроде
$GOPATH/src/myproject/vendor/github.com/username/depproject/, а в $GOPATH/src/myproject/main.go в import включаем как "github.com/username/depproject"
Спасибо.
> C vendor так и не разобрался, кто-нибудь подскажет?
> Есть проект:
> $GOPATH/main.go
> Который импортирует "github.com/.../package" (который в свою очередь имеет свои зависимости).
> С гитхаба сливаю этот пакет в vendor - ошибка компиляции. Причем пробовал
> по-всякому размещать в vendor - с полными путями, относительными, укороченными: все
> равно не видит. Пробовал на 1.61) Должно быть $GOPATH/src/ваш_проект/main.go
2) Положите пакет в $GOPATH/src/ваш_проект/vendor чтобы получилось
$GOPATH/src/ваш_проект/vendor/github.com/.../package3) Импортируйте его в своём коде просто как "github.com/.../package".
4) Вызов
go install ваш_проект
соберёт всё и сделает Вам исполняемый файл
$GOPATH/bin/ваш_проектМожете для начала делать просто `go build` в каталоге с проектом.
Спасибо.
Хороший язык? Лучше жабки с питонами?
Да. Зависит от задач.
> Хороший язык?Что такое "хороший язык"?
> Лучше жабки с питонами?
По каким критериям, на каких задачах, в каких условиях?
Для написания I/O bound серверов - хороший, до тех пор пока не упираетесь в GC-паузы.
Чем оно лучше APL?
Как что-то может быть лучше APL?
Обновился и что-то "beego run" теперь отрабатывает весьма долго :(
А Go - это адекватная замена Python? Вот захотелось научиться программировать, то в какую сторону смотреть? Хотелось бы увидеть развернутый ответ.
Если для школьных лаб, сгодится и Python. Уровень вхождения очень низкий, гитхаб завален проектами на нем.
Человек ведь о другом спрашивал.
Между "научиться программировать" и "быстро лабать лабы" разница не просто огромная, но во многом даже принципиальная.
Да не - всё он верно сказал.
Даже вон в "великом и ужастном" MIT - переключились с scheme на Python ....
Еще через два десятилетия, когда все джаваскрипты будут состоять уже из одних функторов с монадами, MIT перейдет с Python на ML.
Не нужно переоценивать MIT, и не нужно недооценивать их бюрократизм в поспевании за индустрией.
Обучение програмированию (а мы вель о нём?) к "поспеванию за индустрией" ... нк никак! Ну совсем никак! :-) Иди в дупу Роб, лучше го для фряхи почини! :-р
Это смотря кого стремиться выпускать, "готовых к трудоустройству джава-кодеров на Spring" или, например, людей, способных делать что-то новое и решать сложные проблемы.
Студенты MIT, во всяком случае часть их, которой интересно второе, кстати говоря, к переходу на Python отнеслись очень прохладно и ругали MIT именно на основании того что "мы же MIT а не бангалорский техникум".
Вообще идея перехода была, насколько я понимаю, в том, что основная проблематика сейчас лежит совсем не там, где была 30 лет назад - а в реалтаймовых системах, вазимодействии с окружающим миром и т.п. И управляемые питоном роботы к этой проблематике куда ближе.
Только вот реалтаймовые системы строят всё больше на Scala, а совсем не на Python.
И главная проблема у строителей (например, в том же Twitter) в недостатке программистов, умеющих во что-то отличное от Алгол60.
Убежали от языков, где легко сделать ошибку по причине неучтенных побочных эффектов, а прибежали к языкам, на которых без матана хрен че напишешь.
Что говорят в индустрии> I use OCaml at Red Hat for a lot of virtualization tools. I had reason to use Python for some code quite recently, and it reminded me of how much better ML-derived languages are.
> The things I found awful about Python compared to OCaml:
> - Lots of bugs which are never noticed, even at run time, eg. along error paths. 'pylint' helps here, but it doesn't catch all the bugs, and IMHO if you need a lint tool to fix your language you're doing it wrong in the first place.
> - Really hard to refactor code. In OCaml the compiler helps refactoring -- you just break something and hit 'make -k' until you've fixed all the places that need fixing. In Python you have to visually grep all the code, which doesn't scale and is bug-prone.
> - I miss nested variable declarations.
> - Poor support for data types. Python in theory has lots, but in practice everyone's using dictionaries and objects, which are unsafe and introduce bugs by design.
> - Slow. Really slow.
> There were a few good aspects of Python, but I ended up with a lot of buggy code, and I know there are many more bugs in there which I haven't yet found, which just wouldn't be the case with a statically typed, type-inferenced ML-derived language.
Нет, неадекватная.Куда-нибудь в сторону противоположную Алголу60. На языки ML-семейства, например.
А потом долго и нудно искать работу ...
Задачи "найти работу" и "научиться программировать" - это разные задачи, в общем случае ортогональные.
Даааа? А кто тут пел странное? -> http://www.opennet.ru/openforum/vsluhforumID3/108843.html#95:-)
В той стороне - теоретики от CS. Программирование - не там. И да, как альтернатива Питону Go - вполне приличный вариант.
Программирование - пока не там, но учиться и учить желательно тому где оно будет.
Малоизвестная социальная сеть для котиков уже даже специальный синтаксис для OCaml сделала, чтобы джаваскрипт-поколение проще было переучивать. Даже Java уже с лямбдами.
Поэтому переход MIT с Scheme на Python особенно забавен, в полном соответствии с принципом всегда учить вчерашнему дню.
> А Go - это адекватная замена Python?Довольно сложно найти адекватную замену чему-либо неадекватному.
"позволяет добиться производительности, сопоставимой с программами на языке Си"Ох уж эти сказочники... до анси си как ни страдай над кодом, как до луны.
До c++ и то только жабка местами дотягивается. Но её-то мы любим не за то...
А go, rust и остальное - увы, и до жабы не доросли по скорости. :(
>rust и остальное - увы, и до жабы не доросли по скоростиШта?
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
Лол, опять замеры времени старта jvm и вызовов функций на С? Серьёзно. Этот бенчмарк полное г..но, измеряющий непонятно что. Перформанс слишком сложная штука чтобы вот так в лоб сравнивать языки и платформы.
В binary-trees 8 секунд из 12 это старт jvm? А в 23c nbody сколько ушло на старт jvm? А теперь на их фоне глянем на k-nucleotide, выполнившимся за 0.5с, сколько там ушло на этот мифический старт jvm?
> Лол, опять замеры времени старта jvm и вызовов функций на С?
> Перформанс слишком сложная штукаС десяток секунд запускающийся и «разогревающийся» grep или mv? Чур, чур меня от таких «улучшений».
> Ох уж эти сказочники... до анси си как ни страдай над кодом,
> как до луны.Расскажи нам, из какого стандарта вот это
_m128 v0 = _mm_shuffle_ps(v.data, v.data, _MM_SHUFFLE(0, 0, 0, 0));
И как ты собрался писать быстрый код на голом анси. Кстати, анси — это стандарт такой, хотя многие упорно путают с std89.
lol no generics
> that compiler speedup is bullshit, since the premature switch to the Go bootstrapping compiler in 1.5 slowed everything down 4x
> It's like a store that sells a T-shirt for $10 fifty weeks out of a year and then raises the price to $20 for a week before Black Friday or some other holiday and then puts it 'on sale' for the same price it usually is so they can say 50% off.
го становится все сильнее и сильнее
Да, размер скомпилированного файла не мешало бы уменьшить
Как в структурах теги сделать для нескольких парсеров XML, JSON, Protobuf?... {
Handle int `xml:"handle",json:"handle"` - не работает
Handle int `xml:"handle";json:"handle"` - не работает
}Кто-то писал и сталкивался?