LINUX.ORG.RU

Go 1.3

 


1

3

Версия 1.3 выпущена спустя шесть месяцев после версии 1.2 и не содержит изменений в языке. Основная работа была произведена над реализацией, что обеспечило точную сборку мусора, рефакторинг тулчейна, результатом которого стала более быстрая сборка, особенно больших проектов, и значительное улучшение производительности. Как всегда, Go 1.3 держит обещание совместимости, и с новой версией почти все приложения будут продолжать собираться и запускаться без изменений.

Главные улучшения:

  • Прекращена поддержка Windows 2000.
  • Появилась экспериментальная поддержка Dragonfly BSD.
  • Вернулась поддержка Native Client (NaCl).
  • Добавлена экспериментальная поддержка Plan 9.
  • Добавлена экспериментальная поддержка Solaris.
  • Изменилась реализация стеков горутин: прежняя, «сегментированная» модель заменена на непрерывную, что устраняет старую проблему «горячей точки», когда вычисление многократно выходит за границу сегмента. Подробности, включающие статистику производительности, можно посмотреть здесь.
  • Долгое время сборщик мусора был точным при изучении значений в куче. В версии 1.3 аналогичная точность добавлена для значений в стеке. Это значит, что значения Go, не являющиеся указателями (например, целые), больше не будут ошибочно приниматься за указатели и препятствовать повторному использованию незанятой памяти.

А также многое другое.

>>> Подробности

anonymous

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 1)
Ответ на: комментарий от Apple-ch

При чем тут свифт вообще ? Свифт крутиться только на маках и айфончиках. Go очень перспективный язык.

abc
()
Ответ на: комментарий от Kompilainenn

Мы используем. Dropbox, если угодно.

anonymous
()
Ответ на: комментарий от Stalin

Будущим за D не высматривалось и ранее, полагаю, в скорости последует полная остановка всяких его процессов жизнеспособности. Мы — а мы довольно большая компания — не рассматривали D, как альтернативу Go.

anonymous
()
Ответ на: комментарий от RedPossum

Перспектива у него именно замена питонорубей. Преимущество — статическая типизация и при этом высокая скорость компиляции. На динамическую типизацию все плюются рано или поздно. Go можно использовать для системной автоматизации, потому что он позволяет писать скрипты, которые будут компилироваться в бинарники. И эту фичу тоже сделали с прицелом на замену питона, например.
Ну и он уже есть, и есть поддержка обратной совместимости; кроме того, есть подозрение, что синдрому улучшательства не будет подвержен, с ломанием совместимости.
А Swift это такой улучшенный Obj-C, который нужен только Apple. Он безусловно также перспективен, но очень нишевый, как обжект-си.

Virtuos86 ★★★★★
()
Последнее исправление: Virtuos86 (всего исправлений: 1)
Ответ на: комментарий от abc

golang и задумывался как замена питонам и руби.

Неполучилося

Debasher ★★★★★
()
Ответ на: комментарий от Virtuos86

На динамическую типизацию все плюются рано или поздно

Диванного теоретика сразу видно.

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

Go можно использовать для системной автоматизации, потому что он позволяет писать скрипты, которые будут компилироваться в бинарники. И эту фичу тоже сделали с прицелом на замену питона, например.

Скрипт на Ruby или Python можно в случае необходимости открыть и посмотреть код, что-то поправить. Как с бинарником быть?

anonymous
()
Ответ на: комментарий от Virtuos86

А Swift это такой улучшенный Obj-C

Ну да, а go это такой улучшенный C.

который нужен только Apple.

А go нужен только на серверах с linux.

Перспектива у него именно замена питонорубей.

Абсолютно такая-же узкая ниша. Да и в вебе - смысла дергаться нет. Потому как нет батареек как бля простых сайтов, так и для корпоративных монстров.

Хотя я вот уже нагуглил некий monsti cms, может его и удастся скрестить с тем же revel, надо посмотреть. Только вот смысла нет.

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

Каких именно батареек вам не хватает? Про корпоративные сайты не скажу (не знаю, чего именно вы ждете от «корпоративного сайта»), а для создания простых сайтов там есть всё необходимое из коробки. Собственно revel и cms лишние на этом празднике жизни.

Weres ★★★
()
Ответ на: комментарий от Debasher

Или умеют в лисп

Чукча не читатель? Какой из условных питонорубей умеет в лисп, то бишь компилироваться в нативный код или хотя бы в образ?

Virtuos86 ★★★★★
()
Ответ на: комментарий от Weres

Как раз надо чтобы я с минимальными усилиями:

1)наваял моделек, сразу для них получил генерацию табличек и админку

2)cms, с менюшками(в т.ч. и для этих моделек) и прочестями, дабы всякие не относящиеся к делу странички наклепать

3)всякие social-auth модные ненужности.

Все это безобразие у go уже появилось?

RedPossum ★★★★★
()
Ответ на: комментарий от anonymous

Скрипт на Ruby или Python можно в случае необходимости открыть и посмотреть код, что- то поправить. Как с бинарником быть?

Ба, да мне надо подвинуться на диване, кажется! Скрипт на любом языке можно посмотреть. Как я понял, схема такая же, как у питона. Питон (у которого, кстати, строгая типизация, даже сам не знаю, откуда мне это известно, О_о) сначала компилирует исходник в байт-код и кладет рядом с исходником, а выполняет полученный байт-код. Заменяем байт-код на бинарник — получаем схему действия gonow (это отдельный инструмент для выполнения go-программ как скриптов). Ну и как в случае с питоном, при изменении исходника перекомпилируется бинарник. А вот за счет быстрой компиляции этот процесс не давит по нервам. Но это в теории, сам я не пробовал, мне и на диване неплохо рассуждается.

Virtuos86 ★★★★★
()
Ответ на: комментарий от anonymous

А это как раз хорошо, не позволяет всяким мудакам в продакшене что-то редактировать. В моей говноконторе до сих пор такое практикуют, потом сиди разбирайся, что происходит.

anonymous
()
Ответ на: комментарий от Virtuos86

нетЪ

если golang взлетит то только по причине , что массы вкурят горутины и каналы промеж , ну и в компиляторе «ещё более лучще» научатся мигрировать горутино-потоки между ядрами и процами узла а вообще и узлов ( ежели кластероподобие)

т.е golang это ещё и более человечная алтернатива эрлангищу

qulinxao ★★☆
()
Ответ на: комментарий от RedPossum

Авторизации через социалки вроде бы вот: https://github.com/stretchr/gomniauth Остальное не знаю, не встречал. Да и на мой взгляд, это не очень нужно, всё быстро пишется и так. Ну, ИМХО. Батарейки пилят, обратную совместимость обещают не ломать (по крайней мере в первой ветке), так что масса библиотек будет нарастать.

Weres ★★★
()
Ответ на: комментарий от qulinxao

А массам это сильно нужно? Я вот из-за горутин и каналов стал его тыкать, нужно было приложение с распараллеиванием сделать. Но задача это не частая. Для масс. А компании, у которых на это завязаны сервисы, вряд ли будут мигрировать на голанг. Разве что новые проекты будут пытаться на нем сделать.

Weres ★★★
()
Ответ на: комментарий от Virtuos86

Его перспектива это замена джавы, а замена всего остального будет постольку-поскольку, не заменит он сильно высокоуровневые языки с кучей батареек, лишь там где важна производительность в первую очередь он и выстрелит. (Далее уже не конкретно тебе)

А вообще я тут понял что Go не собирается отбирать нишу каких-то языков. У него довольно четкая ниша которая ничем толком не была занята - ниша языка общего назначения заточенного под современное многоядерное железо с высокоуровневыми конструкциями в самом языке, а не батарейками которые где-то сбоку.

Яркий представить того что должно было быть написано на Go - node.js. Это же пи*дец, кто-то проснулся с утра и понял что ему во что бы то не стало нужно написать софт уровня ноды на джаваскрипте. Ну кое-как решает свою задачу, но дальше то что. Языка под эту нишу нет, влезть пытаются все кому не лень. Есть переусложненный D и нестабильный, пытающийся схавать все парадигмы Rust.

Плюс во весь рост встала проблема многоядерных мобильных устройств. И если на пк еще можно как-то обойтись программами использующими одно ядро, то на мобилках на мобилках уже болт. Сейчас вообще полезут мобильники с 8ю ядрами изо всех дыр. Китайцы вон уже наклепали, скоро и очередь до остальных дойдет. А нормального языка так и нет. Есть джава и NDK. Один медленный и память кушает (а еще любит stoptheworld сборщик мусора запускать из-за которого интерфейс ранних версий андроида просто умирал), другой требует высокой квалификации с традиционно осторожной работой с памятью и оба не очень то решают проблемы связанные с большим количеством ядер.

Вот вы серьезно думаете что корпорация уровня гугла решила написать свой питон/перл/руби? Для чего? Она странички в интернете не осилила писать? А может все-таки Гугл это крупнейший сервис для массовой высокопараллельной и распределенной передачи, обработки и хранения информации? Может и язык про это же?

Вспомните еще раз чем всю дорогу была корпорация Гугл. Компания использующая нетривиальные технические решения для того что бы максимуму пустить в дело имеющиеся ресурсы. С самого основания. Это вам не оракл который только продает свои продукты. Они конечно не сильно давно перешли к использованию своей БД (даже припоминаю цитату: с тех пор как оракл перешел на использование своей базы данных, техподдержка стала гораздо лучше воспринимать проблемы клиентов). Нет, гугл это технократы. Можно не верить в их социальные проекты (привет гугл+). Но в техническом плане они впереди планеты всей.

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

(Аж сам вдохновился на более подробное изучение Go. Не серебряная конечно пуля, но свой след этот язык в истории оставит.)

anonymous
()
Ответ на: комментарий от Weres

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

Хорошо, когда писать не надо вообще.

Батарейки пилят, обратную совместимость обещают не ломать

Вот наберется, тогда такие как я будут на go писать.

RedPossum ★★★★★
()
Ответ на: комментарий от Weres

дык если многопоточность не станет нужной массам ( просто по причине , что гонка частот упёрлась в физику и ща фактически 2 пути или массово-конкурентные(многопроцессные) устройства или квантовые вычисления)

если первое , то голэнг для обывателя предпочтительнее эрланга

если второе ( что вообще пока только фантастика ) то там совсем другое кино.

во всех остальных случаях голэнг это действительно нечто руби-питона токмо компилируемое ну и таксказать современное с- всмысле что патриархи считают общеприменимым опустили до уровня маленького(в смысле обозримомго и простого для вкуривания его «определения») языка.

т.е дело не в компаниях , а постепенном распространении многоголовых устройств в быту и для не сверх задач потеря различия между многоголовыми устройствами или сетями из одно многоголовых устройств.

т.е plan9 тока через заднюю дверь и недо.

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

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

Уже стала, продажи мобильных устройств выше чем ПК. Ядер там уже от двух, в среднем четыре, китайцы предлагают и 8. Ресурсы сильно ограничены и не использовать их полностью просто бредово.

Впрочем, я уже написал что у Го своя, почти пустая, ниша.

anonymous
()
Ответ на: комментарий от qulinxao

Распараллеливание между процессорами - задача операционной системы, как мне кажется. Прикладной программист о подобных вещах думать должен, но редко, только если задача именно что под параллельную обработку чего-либо. Голанг подобные думы упрощает. Распараллеливание между серверами и прочим (это ведь ниша эрланга, так?) это уже для крупных компаний и проектов. Про что и писал.

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

А что с Plan 9? Там есть подобные интересные вещи?

Weres ★★★
()
Ответ на: комментарий от anonymous

Ядер там уже от двух, в среднем четыре

И все идёт в сторону специализации этих самых «ядер». Ну да ладно, зачем тотальная асинхронность в обычном мобильном кодинге?

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

А она не тотальная. Нужна синхронность? Так она тоже из коробки. Еще раз голанг это не эрланг.

Ты про технологию амд с «12ю» ядрами или про 4+4 биг.литл? А вообще я говорил про равные 2/4/8 ядер. Китайцы действительно склепали процессор с 8ю одинаковыми ядрами.

anonymous
()
Ответ на: комментарий от Weres

речь не про паралельность(масово распаралеливаемое), а про сопрограммность , а при технической возможности(сети петри) возможность сокращения общего пути путём независимых работ.

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

в плане9 была попытка эмулировать текущий конгломерат используемых машин как одно устройсто - т.е пользователь становилось не важным где сию секунду идёт обсчёт его задачи.

и так же в идеале , его клиент мог быть открыт на любом терминале системы.

общее тут то , что живая система мобильна - т.е може перетекать по мере подключения отключения процесорных устройств и памяти.

для этого требуется не так уж и много .

qulinxao ★★☆
()
Ответ на: комментарий от RedPossum

всяко герцы перестали расти ,

и проще начать использовать возможность увеличения числа ядер на устройстве , чем вынудить программистов писать чище код.

qulinxao ★★☆
()

Го слабо заточен под cpu bound concurrency, он больше под io bound concurrency. Горутина — замена не птхредам, а мессиву из калбеков ноды/твистеда/etc.

PolarFox ★★★★★
()
Ответ на: комментарий от anonymous

А она не тотальная. Нужна синхронность? Так она тоже из коробки.

Джавовский fj-pool для не тотальной вполне подходит. Смысла перескакивать никакого.

RedPossum ★★★★★
()
Ответ на: комментарий от anonymous

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

Это изкоробочная либка. И гугловца о ней все знали. Просто Гугол не всегда знает что ему надо.

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

Это же их модель бизнеса. 20% времени сотрудник тратит на свои проекты которые потом и выливаются в эти велосипеды. Когда тряхнуло в кризис их все позакрывали.

anonymous
()
Ответ на: комментарий от RedPossum

Я лучше спрошу зачем нужна жрущая как не в себя память джава когда рядом есть Го уступающий по производительности плюсам всего в 2 раза?

anonymous
()
Ответ на: комментарий от anonymous

Го уступающий по производительности плюсам всего в 2 раза?

Как бы эти тесты не ругали, но вот http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=g...

А как там в далвике, да ещё и после aot компилятора, непонятно. Может вообще разницы и не быть никакой.

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

Резко снизят количество используемой памяти. Избавят от подлагиваний интерфейса из-за другой реализации GC. Облегчат использование всех ядер процессора.

anonymous
()
Ответ на: комментарий от anonymous

Избавят от подлагиваний интерфейса из-за другой реализации GC.

То есть для дальвика они gc сделать не осилили. А вот для go осилили.

Резко снизят количество используемой памяти.

За счёт чего?

Облегчат использование всех ядер процессора.

Это зачем?

RedPossum ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.