The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз языка программирования Go 1.8

17.02.2017 11:44

После шести месяцев разработки компания Google представила релиз языка программирования Go 1.8, который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD.

Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов), что позволяет добиться производительности, сопоставимой с программами на языке Си.

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

Основные новшества, представленные в выпуске Go 1.8:

  • Добавленный в прошлом выпуске бэкенд компилятора SSA (Static Single Assignment), обеспечивающий прирост производительности генерируемого кода на 5-35%, задействован для всех архитектур, а не только для x86_64. При тестировании на 32-разрядных системах ARM собранные с использованием нового бэкенда программы, продемонстрировали снижение нагрузки на CPU на 20-30%. Для x86_64 отмечается увеличение производительности до 10%, по сравнению с показателями SSA в прошлом выпуске. Кроме того, проведена работа по увеличению производительности компиляции, которая на системах x86_64 стала выполняться на 15% быстрее;
  • Проведена работа по сокращению периодов активации сборщика мусора, приводящих к приостановке выполнения кода приложения. Сборщик мусора теперь осуществляет свою работу в рамках более коротких циклов, не превышающих 100 мкс и обычно длящихся около 10 мкс. Также прекращено использование операций сканирования стека, приостанавливающих выполнение приложения;
  • В модуль с реализацией функций HTTP-сервера добавлена поддержка операций Push для HTTP/2, которые позволяют серверу инициировать обращение к клиенту. В http-сервер также добавлен метод Server.Shutdown для завершения соединения с ожиданием окончания обработки запроса и метод Server.Close для незамедлительного обрыва соединения;
  • В модуль context добавлены средства для принудительного завершения соединений и использования таймаутов. Поддержка контекстов добавлена во многие штатные библиотеки, включая database/sql, net и функцию Server.Shutdown из net/http;
  • В модуль sort добавлена новая функция Slice, упрощающая сортировку данных с типом slice. Например, для сортировки структур по полю "Name" можно выполнить:
    
       sort.Slice(s, func(i, j int) bool { return s[i].Name < s[j].Name })
    
  • Проведена оптимизация модулей bytes, crypto/aes, crypto/cipher, crypto/elliptic, crypto/sha256, crypto/sha512, encoding/asn1, encoding/csv, encoding/hex, encoding/json, hash/crc32, image/color, image/draw, math, math/big, reflect, regexp, runtime, strconv, strings, syscall, text/template и unicode/utf8;
  • Добавлена поддержка 32-разрядной архитектуры MIPS (MIPS32r1) для систем big-endian (linux/mips) и little-endian (linux/mipsle);
  • Изменены требования к минимально поддерживаемым версиям: DragonFly 4.4.4, OpenBSD 5.9 и OS X 10.8;
  • Значительно улучшен порт для Plan 9, в котором почти доведены до полноценного состояния сетевые функции.


  1. Главная ссылка к новости (https://blog.golang.org/go1.8...)
  2. OpenNews: Проект Go опубликовал собственный шрифт для программистов
  3. OpenNews: Выпуск языка программирования Go 1.7
  4. OpenNews: Доступен язык программирования Go 1.6
  5. OpenNews: Язык программирования Go переходит с Mercurial на Git и GitHub
  6. OpenNews: В кодовую базу LLVM приняты биндинги для языка Go
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46067-golang
Ключевые слова: golang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (180) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 13:03, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Не густо
     
     
  • 2.4, KonstantinB (ok), 13:08, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Производительность подняли, gc-паузу сократили, что еще надо?

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

     
     
  • 3.9, Аноним (-), 13:23, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –7 +/
    >  gc-паузу сократили, что еще надо?

    Вообще gc убрать, сам буду кучу чистить.

     
     
  • 4.16, u (?), 13:48, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    GOGC=off
     
     
  • 5.20, Аноним (-), 14:04, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    И-и-и-и? Это опция активирует в Go невидимые ранне функции/операторы, типа, free()/delete?
     
     
  • 6.25, Василий Теркин (?), 14:23, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +7 +/
    А зачем тебе все это в твоем fmt.Println("Hello World")?
     
  • 6.27, Василий Теркин (?), 14:27, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > И-и-и-и? Это опция активирует в Go невидимые ранне функции/операторы, типа, free()/delete?

    И потом, если уж так чешется, берешь исходники, форкаешь и дописываешь нужный функционал. Осилишь?


     
     
  • 7.31, Аноним (-), 14:48, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Полный бред. Давай мы теперь всё будем по любому поводу форкать и переписывать под себя, это ведь легко, быстро и абсолютно нормально... Тогда и смысла в языках нет, у каждого был бы свой, удобный, лично для себя,.... если всё бы было так, как Вы описываете. Но все не так, не надо писать бред.
     
     
  • 8.47, Василий Теркин (?), 15:02, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот и замечательно Не пойму только, к чему был Ваш бред выше по ветке Чем CPP ... большой текст свёрнут, показать
     
     
  • 9.58, Аноним (-), 15:15, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Это не мой бред выше по ветке Меня CPP полностью устраивает ну почти , и на гу... текст свёрнут, показать
     
     
  • 10.66, Василий Теркин (?), 15:31, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На здоровье У меня нет таких проблем как у Вас Дайте догадаюсь, наверняка и ра... текст свёрнут, показать
     
     
  • 11.106, Аноним (-), 17:29, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Не угадали Владею 3-мя разговорными языками, c , qml, javascript, php, html, s... текст свёрнут, показать
     
     
  • 12.119, _ (??), 17:49, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А по моему он там на сухую гоняет ... текст свёрнут, показать
     
     
  • 13.171, hhg (ok), 21:08, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    угумс хтмл написал, а цсс нет - косячник ... текст свёрнут, показать
     
  • 12.127, Василий Теркин (?), 17:56, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну я в резюмешках и не такое видел Скромность украшает человека Но есть пробле... текст свёрнут, показать
     
  • 12.170, Аноним (-), 20:41, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Русский разговорный, русский строительно-армейский, русский литературный ... текст свёрнут, показать
     
  • 9.63, Аноним (-), 15:21, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже в CPP уже лет 5 как ручное освобождение памяти считается дурным тоном Есть... текст свёрнут, показать
     
     
  • 10.69, Василий Теркин (?), 15:35, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а я разве спорю Можете ковыряться в проблеме любым микроскопом А в бизнесе ... текст свёрнут, показать
     
     
  • 11.111, Аноним (-), 17:37, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    На обертывание выделения памяти в умный указатель уходит 1, максимум 2 секунды ... текст свёрнут, показать
     
  • 11.157, Аноним (-), 18:50, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Business, production -- какие великие слова в устах Василий Теркин , делающие е... текст свёрнут, показать
     
     
  • 12.163, Василий Теркин (?), 19:09, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это что, попытка неуклюжего троллинга Весьма неуклюжая, стоит заметить Ну да л... большой текст свёрнут, показать
     
  • 10.193, angra (ok), 12:31, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Их вообще-то там много и каждый со своими достоинствами и недостатками А еще ес... текст свёрнут, показать
     
     
  • 11.199, Аноним (-), 17:46, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Их 2 - unique_ptr и shared_ptr И weak_ptr, немного усложненная разновидность sh... текст свёрнут, показать
     
  • 7.79, Аноним (-), 15:57, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Лучше бы сделали опцию, которая включает/отключает сборщик мусора при запуске Go. Ну и delete/free. И пусть каждый решает сам, как лучше в каждом конкретном случае. Язык и компиляторы не должны ограничивать свободу действий.
     
     
  • 8.112, Аноним (-), 17:41, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сборщика мусора не должно быть совсем Есть куча техник обойтись без него и слеж... текст свёрнут, показать
     
     
  • 9.126, _ (??), 17:55, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    и при этом есть куча языков где всё так и сделано Вот и юзайте их, Д,Б С ... текст свёрнут, показать
     
  • 9.203, Аноним (-), 18:00, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Кокой юношеский максимализм У GC есть свои плюсы, как и минусы ... текст свёрнут, показать
     
  • 6.155, KonstantinB (ok), 18:45, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И что же будет с библиотеками, которые полагаются на gc? Все переписывать с какими-нибудь

    if (runtime.gcDisabled) {
       free(slice)
    }

    ?

    Не надо этого в go. Он вполне завершен и целостнен в своем дизайне. При этом он, разумеется, не универсален. Если нужен жесткий реалтайм и gc-паузы категорически неприемлемы, стоит изначально выбрать другой язык.

     
  • 4.18, Аноним (-), 13:59, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > Вообще gc убрать, сам буду кучу чистить.

    Тогда бери лопату и дуй чистить кучу.

     
  • 4.30, Аноним (-), 14:46, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    батенька зачем вам го? Пишите на си
     
  • 4.33, Аноним (-), 14:49, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Неосиляторы вас загрызут за такие высказывания
     
  • 2.6, Аноним (-), 13:11, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Нет бы запилить несовместимый Golang 3.0 и %%%ться с ним 25 лет подряд.
    Вот это весело, вот это адреналин.
     
     
  • 3.176, anonnchick (?), 21:35, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>Нет бы запилить несовместимый Golang 3.0 и %%%ться с ним 25 лет подряд.

    Ветка 3.0 идет строго после 2.7

     

     ....большая нить свёрнута, показать (32)

  • 1.2, Аноним (-), 13:03, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Дебагер уже запилили?
     
     
  • 2.5, Пользователь Debian (?), 13:10, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Погуглите по слову "delve".
     
  • 2.10, Аноним (10), 13:27, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    а тебе какой нужен? а то я через плагин к Intellij Idea отлично дебажу ещё со старых версий go
     
     
  • 3.19, Аноним (-), 14:02, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Jetbrains уже и полноценную EDI для Golang выкатели(EAP пока) -Gogland
    https://www.jetbrains.com/go/
    и автодополнение и дебаг там в разы лучше(100x faster performance - дебагер в 100 раз быстрее).
    Преимущества перед плагином описаны по ссылке:
    https://www.jetbrains.com/help/go/1.0/faq.html#d3e52
     
  • 2.28, derlafff (ok), 14:28, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Эмм. gdb прекрасно работает
     
     
  • 3.162, Аноним (-), 19:08, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оно же на С написано!
     

  • 1.3, Nexor (?), 13:07, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    100 МИЛЛИсекунд? В оригинале написано 10 МИКРОсекунд... кто то ошибся, но я больше склоняюсь к ошибке в исходном тексте, т.к. иначе звучит нереально
     
     
  • 2.7, Пользователь Debian (?), 13:12, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Микросекунд, да.
     
  • 2.14, angra (ok), 13:47, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Миллисекунды были версии три назад, теперь речь действительно о микро, что конечно не помешает некоторым рассказывать про секундные зависания из-за gc.
     
     
  • 3.38, Я. Р. Ош (?), 14:52, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > что конечно не помешает некоторым рассказывать про секундные зависания из-за gc.

    что не помешает некоторым фанатикам бугуртить, когда их священную корову еретики смеют в чем то обвинять


     
     
  • 4.141, _ (??), 18:14, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Обвинить - это предъявить доказательства. У _цивилизованных_ людей а не у <your nick name>
     
     
  • 5.180, Sw00p aka Jerom (?), 22:33, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    перед тем как предъявить, нужно прочесть "Теория доказательства" Д. Гильберт-а )
     
  • 3.54, Аноним (-), 15:10, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Где-то мы уже слышали эти сказки… Ах да — Оракол тоже всем любит рассказывать про "pausless GC". В смысле — в JVM можно ручками и паузы в сотые наносекунды поставить. Только наблюдаемые подвисания при неаккуратном выделении объектов никуда от этого не деваются. И при достижении предельной фрагментация всё так же идёёт полная сборка (или compacting, что по факту не лучше).
     
     
  • 4.147, Comdiv (ok), 18:24, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Было бы странно при неаккуратном выделении памяти чего-то хотеть. Free/delete тоже далеко не бесплатны, а при неаккуратном выделении вообще ведут к катастрофе.
     
     
  • 5.192, angra (ok), 12:16, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Поддержу, некоторые наивно считают, что наличие gc избавляет от необходимости думать о выделении памяти. Но именно на работу с памятью обращается первое внимание при оптимизации кода на go.
     
  • 3.205, Кай (?), 19:13, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Миллисекунды были версии три назад, теперь речь действительно о микро, что конечно
    > не помешает некоторым рассказывать про секундные зависания из-за gc.

    А зачем тогда вообще нужно ручное управление памятью, если GC столь быстр?

     

  • 1.8, Аноним (-), 13:22, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Это версия компилятора или новая версия стандарта?
     
     
  • 2.12, Andrey Mitrofanov (?), 13:37, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это версия компилятора или новая версия стандарта?

    Нет стандарта, кроме версии компайлера.  ///про пророка писать тут===>>>

     

  • 1.13, angra (ok), 13:44, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > Синтаксис Go основан на привычных элементах  языка Си с отдельными заимствованиями  из языка Python.

    А создатели то и не знают, что они оказывается из питона заимствовали. Они думали, что из algol-60/pascal/modula/oberon и csp/squeak/newsqueak/alef.

    > что позволяет добиться производительности, сопоставимой с программами на языке Си.

    С явой, плюсами, но не с С. На нишу С go никогда не претендовал.

     
     
  • 2.152, Comdiv (ok), 18:32, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > С явой, плюсами, но не с С. На нишу С go никогда
    > не претендовал.

    Это потому что Вы сужаете изначально широкую нишу С, от которой постоянно откусывают другие языки. Тот же компилятор Go изначально был написан на C, который затем был заменён самим Go. Компилятор - это ниша C или нет? Как по мне, пересечений ниш С и Go хватает.

     
     
  • 3.191, angra (ok), 12:11, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А если я на perl сделаю прототип видеокодека, будешь ли ты считать видеокодеки нишей perl?
     
     
  • 4.195, Comdiv (ok), 15:05, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А если я на perl сделаю прототип видеокодека, будешь ли ты считать
    > видеокодеки нишей perl?

    В самом вопросе содержатся 1-а манипуляция и 1-а логическая ошибка, правильней было бы задавать его так:
    > А если я на каком-нибудь языке сделаю прототип видеокодека, будете ли Вы считать
    > что в нишу этого языка входит создание видеокодеков?

    Если отвечать на исправленный вопрос, то да. Если Вы справитесь с задачей так же хорошо, как и разработчики первой версии компилятора Go, написавшие его на Си, то безусловно да. Именно в практических задачах определяется применимость языка, задающая его нишу. И если и можно утверждать, что в нишу Perl не входит создание видеокодеков, то именно потому, что за разумное времени практически значимый видеокодек написать на Perl не получится.

     

  • 1.15, Аноним (-), 13:47, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    >добавлены средства для принудительного завершения соединений

    Я был более лучшего мнения об этом ЯП, заточенном на сетевые приложения. Т.е. только сейчас он научился делать FIN-FIN/ACK, RST?

     
     
  • 2.17, angra (ok), 13:50, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, это вообще о другом.
     
     
  • 3.209, Аноним (-), 20:41, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Опеннет превратился в ЛОР.

    >HTTP Server Graceful Shutdown
    >The HTTP Server now has support for graceful shutdown using the new Server.Shutdown method and abrupt shutdown using the new Server.Close method.

    Изучай теперь, и не говори мне что выставление опции != FIN/FIN-ACK.
    https://msdn.microsoft.com/en-us/library/windows/desktop/ms738547%28v=vs.

    Могу тебе сразу ответить, что будет при Graceful Shutdown: опускается этап TIMEWAIT (кои составляет примерно 2 минуты и забивает список используемых сокетов). А ты знаешь к чему ведет graceful shutdown? Нет? Знаешь когда его можно юзать, а когда -- нет? Спорю, что не знаешь.

    Всё. Прощай опеннет. Одно школье и нубасы кругом.

     
     
  • 4.211, angra (ok), 20:59, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Могу тебе сразу ответить, что будет при Graceful Shutdown: опускается этап TIMEWAIT

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

    > Всё. Прощай опеннет. Одно школье и нубасы кругом.

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

     
     
  • 5.215, Аноним (-), 21:12, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ах да, мега чистильщик сообщений Вот пруфы ЗА ТЕБЯ я дам Как обычно Ты же с Л... большой текст свёрнут, показать
     
  • 5.218, Аноним (-), 21:35, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Офигеть терминология в гугле И пруфы аналитиков просто сыпятся https go goog... большой текст свёрнут, показать
     
  • 2.169, LU (?), 20:17, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А я менее лучшего
     
  • 2.181, Sw00p aka Jerom (?), 22:36, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>FIN-FIN/ACK, RST?

    разве не ОС должна делать (точнее tcp/ip стек)?


     
     
  • 3.210, Аноним (-), 20:49, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Открой ты RFC 793 и прочитай кто что должен. Нубасы хреновы не знают, что делает accept(), что делает shutdown(), что делает connect(). Куда вы лезете со своими бреднями?
     
     
  • 4.225, Sw00p aka Jerom (?), 16:29, 19/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ))))))))))))))))))

    ага ЯП должен реализовывать в стд стек TCP/IP

    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/

     
     
  • 5.227, Аноним (-), 12:35, 20/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    И что ты нашел? Что ты хочешь доказать? Что ты вообще пытаешься сказать, кроме как попытаться выставиться себя умником, выскочкой. Смотрю в школах совсем все плохо, выскочек раньше били ногами.

    Итак, по делу. Кто должен вызывать shutdown() на сокет? Приложение? ОС? Мифические существа внутри коробки, что называется компьютер, а для тебя процессор?

    Можешь ли ты внятно строить свои мысли, а, существо?

     
     
  • 6.229, Sw00p aka Jerom (?), 17:33, 20/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    клондайк ну как минимум - нерешенные проблемы Гильберта Молчание золото, я то... большой текст свёрнут, показать
     
     
  • 7.231, Аноним (-), 20:43, 20/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >а много таких прикладных приложений которые дёргают сискол ОС shutdown() ?

    Столько же сколько дергают сискол accept().

    http://man7.org/linux/man-pages/man2/accept.2.html

    И только не говори, что accept() НЕ посылает пакеты по TCP. Такие как SYN/ACK, ACK. Их посылает ОС. Сама. Без спросу. Когда солнце взойдет на западе и сядет на востоке. Тогда отправится пакет ACK. Все. Я добрый пока что. Иди учи сишку и читай маны.

     
     
  • 8.234, Sw00p aka Jerom (?), 23:22, 20/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    не устраивает пакет net - узайте уже пакет syscall - вот там уж точно вы будете ... текст свёрнут, показать
     
  • 8.235, Sw00p aka Jerom (?), 00:29, 21/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    1 не пакеты, а сегменты 2 SYN ACK, ACK - это не пакеты, а Флаги управляющие б... текст свёрнут, показать
     
  • 6.230, Sw00p aka Jerom (?), 17:43, 20/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Можешь ли ты внятно строить свои мысли, а, существо?

    Урок номер 1: Сетевая модель OSI
    https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82

    пс: приложение приложение о каком приложении идёт речь ? ОС - тоже приложение.


     

  • 1.21, Owlet (?), 14:05, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > В модуль sort добавлена новая функция Slice, упрощающая сортировку данных с типом slice

    Вот для чего, дети, нужны дженерики. Чтобы не было по своей функции сортировки для каждого вида последовательностей.

     
     
  • 2.24, Аноним (-), 14:20, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию, а не в Россию.
     
     
  • 3.105, Andrey Mitrofanov (?), 17:20, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию, а не в
    > Россию.

    Потому что "и сами они довольно неискренние, и самовар у них" неоткровенный? :D

     
  • 3.194, Michael Shigorin (ok), 13:03, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию,
    > а не в Россию.

    Потому что у нас -- разработчики, а не кодеры?  Боюсь, Вы всё же приукрашиваете.

     
     
  • 4.212, Аноним (-), 21:01, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >Потому что у нас -- разработчики, а не кодеры?  Боюсь, Вы всё же приукрашиваете.

    Потому что ворье. Потому что Альт стоит как последняя винда в коробке.

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

    Жду рассказа про очевидные вещи #2.

     
  • 2.160, KonstantinB (ok), 18:55, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Вот отсутствие дженериков в том или ином виде - это действительно недостаток.

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

     

  • 1.26, Ilya Indigo (ok), 14:24, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python.

    В бочку с мёдом добавили ложку дёгтя.

     
     
  • 2.44, Аноним (-), 15:00, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Это как раз была ложка меда, тщательно выскребенная и отцеженная из бочки с дёгтем.
     
     
  • 3.179, Led (ok), 22:26, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это как раз была ложка меда

    Этот "мёд" уже один раз кто-то ел.

     

  • 1.29, Аноним (-), 14:32, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Наконецта порт для план 9 доделали, Роб Майк своих не бросает!
     
  • 1.55, Аноним (-), 15:11, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и никаких проблем это не создаёт.
     
     
  • 2.65, Аноним (-), 15:29, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +9 +/
    > Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
    > никаких проблем это не создаёт.

    Совершенно никаких, даром что USE-AFTER-FREE входит в 20ку самых эксплуатируемых уязвимостей. Примерчик с пылу с жару:
    CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10


     
     
  • 3.68, Аноним (-), 15:35, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мне кажется люди просто не знаю, что уже давно проблема ручного контроля освобождения памяти решена std::unique_ptr. Все до сих пор считают что там, где нет сборщика мусора, надо писать что-то вроде:

    > TYPE n = new TYPE()
    > .....
    > // много кода
    > delete n;

    Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а не когда соизволит сборщик.

     
     
  • 4.73, Василий Теркин (?), 15:45, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну да, ну да Когда НУЖНО программисту Только страдают от этого потом пользов... большой текст свёрнут, показать
     
     
  • 5.77, Аноним (-), 15:55, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Сборщик мусора не удалит объект, пока на него есть ссылки. И запускается он через определенные промежутки времени. Т.ч. в языке со сборщиком мусора объекты могут жить дольше, но не меньше. И при этом дольше - это обычно во много раз дольше. В с++ даже локальный объект можно удалить автоматически до выхода из функции просто ограничив ему область видимости фигурными скобками. В том же Go он будет жить еще несколько мс после завершения функции, пока сборщик не соизволит пошевелиться.
     
     
  • 6.86, Аноним (-), 16:10, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Сборщик мусора не удалит объект, пока на него есть ссылки. И запускается
    > он через определенные промежутки времени.

    Фееричные-познания-в-теме-рука-лицо.жпг

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

    Опять тайные знания? На самом деле есть только один GC, а еscape анализ придумка маркетологов?


     
     
  • 7.121, Аноним (-), 17:52, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ветка про сборщик мусора, а не про Go. Везде разные реализации сборщика.
     
     
  • 8.133, Аноним (-), 18:01, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ответ как раз про _сборщики_ мусора, а не специфику го Алгоритмов сборки целая ... текст свёрнут, показать
     
  • 6.90, Аноним (-), 16:23, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В том же Go он будет жить еще несколько мс после завершения функции, пока сборщик не соизволит пошевелиться.

    Go использует стандартную реализацию стека. Все локальные переменные будут удалены* мгновенно при возврате из функции, аналогично с/с++.

    *Указатель на стек вернется в состояние до вызова функции.

     
     
  • 7.97, hoopoe (ok), 16:47, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    там же замыкания на уровне языка реализованы... как их на стек положить?
     
     
  • 8.125, Мяут (ok), 17:55, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Там компилятор автоматически определяет, нужно ли переменную на стеке создавать ... текст свёрнут, показать
     
     
  • 9.172, Аноним (-), 21:11, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Еще зависит от размера и типа переменной и от самой функции, как она вызывается ... текст свёрнут, показать
     
  • 7.123, Аноним (-), 17:53, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    В общем случае да, но есть исключения
     
  • 5.78, Аноним (-), 15:56, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Системы с ограниченными ресурсами самое то, чтобы распылять их на потуги сборщика и висящие неиспользуемые объекты, которые он непонятно когда удалит.
     
     
  • 6.87, Аноним (-), 16:12, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    У вас в квартире дверь есть?
     
     
  • 7.120, Аноним (-), 17:50, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У вас в квартире унитаз есть?
     
     
  • 8.132, Аноним (-), 18:00, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В магазине - У вас трусы есть - Нет - А в продаже ... текст свёрнут, показать
     
  • 6.156, Аноним (-), 18:48, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На автоматическое управление памятью тратятся вычислительные ресурсы машины.
    На ручное управление памятью тратятся временные ресурсы программиста.

    Говорить о том, какой выбор оптимальнее можно только в конкретных случаях. Например, если использовать ручное управление памятью и потерять на это месяц работы, мы заработаем примерно $10000, а если направим время программистов на написание фичи X, то заработаем примерно $15000, 15000 > 10000 -> нет смысла тратить время на ручное управление памятью.

     
     
  • 7.173, Аноним (-), 21:14, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Написали уже, оптимальный - умные указатели. Никакого тебе сборщика мусора и ручного освобождения памяти. Месяц вы никак не потеряете, обернуть вызов new в умный указатель - пара секунд.
    > TYPE *p = new TYPE();

    в
    > std::unique_ptr<TYPE> p(new TYPE());

    И всё.

     
  • 5.80, Аноним (-), 15:57, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Краши уже в прошлом, есть статические анализароры, умные указатели, диапазонные циклы и т.д.
     
     
  • 6.88, Василий Теркин (?), 16:13, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Краши уже в прошлом, есть статические анализароры, умные указатели, диапазонные циклы и
    > т.д.

    Вы серьезно?

     
     
  • 7.124, Аноним (-), 17:55, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Для меня да. Ваш уровень знания языка вероятно гораздо ниже, раз краши для вас обыденность.
     
     
  • 8.140, Василий Теркин (?), 18:12, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А что написали Судя по приводимым в этой ветке примерам - код из популярной сер... текст свёрнут, показать
     
  • 4.94, Ordu (ok), 16:30, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Мне кажется люди просто не знаю, что уже давно проблема ручного контроля
    > освобождения памяти решена std::unique_ptr. Все до сих пор считают что там,
    > где нет сборщика мусора, надо писать что-то вроде:
    >> TYPE n = new TYPE()
    >> .....
    >> // много кода
    >> delete n;
    > Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а
    > не когда соизволит сборщик.

    Если бы всё было так просто, то мемликов бы не было. Вообще нигде не было бы, даже в ассемблере. Иногда хочется иметь ссылку на объект в разных стековых фреймах, а иногда ещё и в структурке хранить её удобно. А ещё иногда объект прямо или косвенно ссылается сам на себя, тогда даже ref_count не всегда спасает.

     
     
  • 5.108, Аноним (-), 17:35, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А не всё так просто Но и не всё так ужасно Как это В ассемблере же ни смарт-п... большой текст свёрнут, показать
     
     
  • 6.158, Ordu (ok), 18:51, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что до тех пор, пока у нас есть указатель вписывающийся в идею uniq_ptr, ... большой текст свёрнут, показать
     
     
  • 7.165, Аноним (-), 19:31, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не всегда просто Легко забыть сделать delete перед return в середине функции О... большой текст свёрнут, показать
     
     
  • 8.168, Ordu (ok), 20:10, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вот нефиг писать исключительно на C Попробуй пописать на C или asm годик, теб... большой текст свёрнут, показать
     
     
  • 9.175, Аноним (-), 21:21, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Может так и есть, но ведь так удобно Выяснил, что больше делать нечего, и до... большой текст свёрнут, показать
     
     
  • 10.178, Ordu (ok), 22:17, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, много чего есть удобного, что потом может выйти боком Для этого и придумыва... большой текст свёрнут, показать
     
  • 6.184, анонимчик (?), 23:23, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >В С++ есть решение из коробки, std::shared_ptr. Помогает в большинстве случаев.

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

     
  • 5.128, Аноним (-), 17:56, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Во всех этих случаях требуется пересмотр архитектуры приложения.
     
     
  • 6.164, Ordu (ok), 19:26, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Во всех этих случаях требуется пересмотр архитектуры приложения.

    Требуется. И что? Ну пересмотришь ты её, а дальше что? Будешь переписывать пару сотен тысяч строк кода? Или ты до сих пор веришь в миф 90-х годов о том, что программу можно спроектировать заранее так, чтобы потом не возникало проблем с архитектурой?

     
     
  • 7.182, Аноним (-), 23:06, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Или ты до сих пор веришь в миф 90-х годов о том, что программу можно
    > спроектировать заранее так, чтобы потом не возникало проблем с архитектурой?

    Это "стало мифом", когда стало модно быть балбесом.

     
     
  • 8.185, Ordu (ok), 00:03, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Может быть Но я склонен разделять мнение этих 95 , которые считают, что проблем... большой текст свёрнут, показать
     
     
  • 9.190, Аноним (-), 08:39, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    KISS ... текст свёрнут, показать
     
     
  • 10.198, chinarulezzz (ok), 16:20, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что, если не вся, то большая часть _сложности_ вытекает из 1 незнания х... текст свёрнут, показать
     
  • 4.118, Аноним (-), 17:49, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, не решена. Программист должен изначально знать нужен ему unique_ptr или shared_ptr, а может weak_ptr?
    В языках с GC об этом можно просто не думать, там везде shared_ptr.
    Это ещё не говоря о том, насколько замусоривается код:
    fun() -> std::unique_ptr<std::array<std::shared_ptr<Node>>>;
     
     
  • 5.131, Аноним (-), 18:00, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    shared_ptr, а уж тем более weak_ptr - это вообще наиредчашие случаи. Я за 15 лет программирования shared_ptr использовал только один раз.
    А код замусоривается потому что неправильно пишете.
    Вот это вот:
    > std::unique_ptr<std::array<std::shared_ptr<Node>>>

    очевидно неправильная конструкция, надо разбираться, почему такая х получилась.

     
     
  • 6.149, Аноним (-), 18:25, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не думаю, что редчайшим случаем является ситуация, когда неизвестно кто из владе... большой текст свёрнут, показать
     
     
  • 7.177, Аноним (-), 21:43, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ситцация, когда нужен shared_ptr Такая ситуация является просто очень редкой П... большой текст свёрнут, показать
     
  • 4.189, Андрей (??), 07:25, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а не когда соизволит сборщик.

    А что с динамическим выделением объекта? Он-то выделится тогда, когда это нужно программисту, но от этого не легче, так как алгоритм выделения в куче не ограничен константным временем. А всё дело во времени: не хочется иметь непредвиденных задержек. Так вот с GC они и так уже небольшие, а что с выделением в куче?

     
     
  • 5.200, Аноним (-), 17:49, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Какой аллокатор напишешь - так и будет выделяться. А GC никогда не был и не будет предсказуем.
     
     
  • 6.223, Андрей (??), 15:48, 19/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Какой аллокатор напишешь

    Так можно и язык свой написать. Я говорю о тех, что под капотом в glibc и в stdlibc++. По-умолчанию (начиная с какого-то размера объекта, наверное), он тоже не предсказуем. Да ещё и куча фрагментируется.

     
  • 5.219, Аноним (-), 22:04, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты ничего не смыслишь в программировании.
     
  • 3.104, Аноним (-), 17:19, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
    >> никаких проблем это не создаёт.
    > CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10

    Абы ляпнуть чтоль?

    Ядро Linux написано НЕ на С++. Ваш Кэп.

     
     
  • 4.110, Василий Теркин (?), 17:37, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
    >>> никаких проблем это не создаёт.
    >> CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10
    > Абы ляпнуть чтоль?
    > Ядро Linux написано НЕ на С++. Ваш Кэп.

    Писали бы на С++ вообще бы Линукса до сих пор не было.

     
     
  • 5.113, Аноним (-), 17:42, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что за перевод темы такой? Пассаж про CVE-2016-7117 не в тему к С++ был, так или нет?
     
     
  • 6.145, Василий Теркин (?), 18:19, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Что за перевод темы такой? Пассаж про CVE-2016-7117 не в тему к
    > С++ был, так или нет?

    Все в тему. С и ассемблер тоже без мусорки. Но и без ООП со всякими с++ плюшками. Поэтому разрабы до сих пор не рискуют переводит код ядра на с++. Слишком большой код и слишком малдо времени, чтобы его отладить.

     
  • 4.174, Аноним (-), 21:17, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Ядро Linux написано НЕ на С++. Ваш Кэп.

    На Go что ли? Если серьезно, причем здесь ядро вообще?

     
  • 3.183, Аноним (-), 23:23, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > > Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
    > > никаких проблем это не создаёт.
    > Примерчик с пылу с жару:
    > CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10

    Ядро Linux это примерчик того, что в C++ нужен сборщик мусора?
    Ну вот как, как к таким умозаключениям приходят?

    P.S.
    Эта критическая дыра не зависит от сборщика мусора в C++,
    так как ядро Linux не на C++ написано.

     
  • 2.93, Аноним (-), 16:26, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Да-да, С++ нахваливают, что память нужно вручную освобождать и юзают при этом умные указатели
     
     
  • 3.109, Аноним (-), 17:37, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Взаимоисключающие утверждения?
     
  • 3.134, Аноним (-), 18:03, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз вручную память освобождать не следует. И язык позволяет обходится без этого непотребства и сборщика мусора одновременно.
     
  • 2.96, Толл (?), 16:35, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и никаких проблем это не создаёт.

    Сильное утверждение. Проверять я его, конечно же, не буду. (с)

     
     
  • 3.135, Аноним (-), 18:05, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Вот и создатели Go не стали. И получилось что имеем - большой костылище для решение проблемы, решаемой простой структурой - умным указателем.
     
     
  • 4.154, Mike Lee (?), 18:45, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Точно. Засунем все в смартпоинтеры, потрахаемся с копированием, удалим auto_ptr потому что не работает, добавим мув семантики, но будем понтоваться, что сборщик мусора не нужен.
     
     
  • 5.201, Аноним (-), 17:56, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Смарт поинтеры нужны в единичных случаях, т.к. обычно достаточно контейнеров. В мув семантике ничего сложного нет, rvalue ссылки + конструктор перемещения, осваивается минут за 10. Смарт поинтера по сути 2 - unique_ptr для единоличного владения и shared_ptr для множественного. Проблемы по сути нет, а уж воротить для её решения GC - верх иди
     
  • 2.98, Василий Теркин (?), 17:05, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
    > никаких проблем это не создаёт.

    Прогони в С++
    class Node {
    public:
            Node* next;
    };
    for (int i = 0; i < 10000000; i++) {
            Node* v = new Node();
    }

    А потом в С#
    class Node
    {
        public Node next;
    }
    for (int l = 0; l < 10000000; l++)
    {
        var v = new Node();
    }

    Если в сях еще прикрутить delete, то ты поймешь преимущество GC сишарпа по рантайму. Да, конечно, примерчик так себе, но показателен. Аллокаторы тоже жрут ресурсы, представь себе!

     
     
  • 3.101, Василий Теркин (?), 17:14, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Стырено в https habrahabr ru post 148657 Но смысл понятен Сборщик мусора, оп... большой текст свёрнут, показать
     
  • 3.139, Аноним (-), 18:11, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Да, конечно, примерчик так себе, но показателен

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

     
     
  • 4.143, Аноним (-), 18:17, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Поэтому программист должен понимать как и что работает, и писать правильно.

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

     
  • 4.151, Василий Теркин (?), 18:31, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Да, конечно, примерчик так себе, но показателен
    > Не показателен. Так никто не пишет. Для С# это вполне нормальный код,
    > т.к. разработчик не должен знать как всё устроено внутри и язык
    > не должен выполнять код буквально. C++ же дает гарантии, что код
    > будет выполнен точно так, как напишет программист. Поэтому программист должен понимать
    > как и что работает, и писать правильно.

    Ну тогда напиши код для cpp "правильно", сделав тоже самое, но за меньшее время чем это делается сишарпе. Задачка-то простая.

     
     
  • 5.166, Аноним (-), 19:37, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да запросто:

    {
    }

    (компилятор соптимизировал всё в ноль)

     
  • 5.202, Аноним (-), 17:59, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Решение предельно простое, не выделять память 10000000 раз, как ииот.
     
  • 3.150, Ivan (??), 18:30, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не хочется кормить тролля, но один раз отвечу Данный пример ничего полезного не... большой текст свёрнут, показать
     
     
  • 4.161, Василий Теркин (?), 18:55, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Спасибо за развернутый ответ Но я НИКОГДА и не спорил, что в С с его гибкость... большой текст свёрнут, показать
     
     
  • 5.167, Аноним (-), 19:45, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что про Python и Ruby скажете? Скорость разработки на них выше, чем на Java. И, подозреваю, выше, чем на Go. Считаете, что дольше надо будет добиваться РАБОТОСПОСОБНОГО решения?
     
     
  • 6.228, Василий Теркин (?), 14:56, 20/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вроде оба этих языка относятся к интерпретируемым(за исключением отдельно привязываемых костылей). И у обоих есть сборщики мусора. И если решение на этих языках конкретных задач более эффективно, чем на GO или С++, то я отношусь к этим языкам весьма положительно. И буду дальше добиваться РАБОТОСПОСОБНОГО приложения, по причине того, что НЕРАБОТОСПОСОБНЫЕ никому не нужны, кроме их авторов.
     

     ....большая нить свёрнута, показать (68)

  • 1.64, Аноним (64), 15:26, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Осторожно, влюбиться в него очень просто.
    При этом уровень вхождения выше среднего, из-за настроек, что отсекает Гкодеров типа PHP.
     
     
  • 2.70, Аноним (-), 15:39, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё ровным счетом наоборот. И настройки не относятся к уровню вхождения в язык. Настроить может любой другой человек, помимо программиста. А программисту знать настройки чтобы писать код - не нужно.
     
     
  • 3.75, Василий Теркин (?), 15:49, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Всё ровным счетом наоборот. И настройки не относятся к уровню вхождения в
    > язык. Настроить может любой другой человек, помимо программиста. А программисту знать
    > настройки чтобы писать код - не нужно.

    Разве что программисту на бэйсике. А уж CPP-программеру, например, без знания настроек компилятора... Совсем худо.

     
     
  • 4.81, Аноним (-), 16:00, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > sudo apt-get install qt-sdk

    или если под виндой - скачать и поставить sdk с оф.сайта.
    Дальше можно писать код. Чтобы собрать - надо нажать кнопочку в левом нижнем углу. И ни капельки не худо.

     
     
  • 5.82, Аноним (-), 16:02, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя в конкретном случае Qt Creator достаточно, он сам подтянет зависимости
     
  • 2.102, Аномномномнимус (?), 17:16, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошая шутка юмора, но нет, уж лучше старый добрый C++
     
  • 2.137, Аноним (-), 18:06, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Язык без дженериков не нужен.
     

  • 1.91, Аноним (-), 16:25, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А если на этой штуке игровой движок накатать, все будет совсем плохо? Как оно по сравнению с С++ по производительности
     
     
  • 2.142, Аноним (-), 18:15, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Со сборщиком мусора придётся побороться. Но эта проблема всех больших проектов на подобных языках. Сборщик начинает захлёбываться без подсказок.
     
  • 2.144, Аноним (-), 18:18, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Пули будут в полёте приостанавливаться на время сборки мусора :)
     
  • 2.153, Аноним Аналитег (?), 18:36, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю игровых движков должно быть мало как раз из-за gc, который может создавать неожиданные паузы. Тут то лучше пусть и не быстрый real time чем неожиданный возникший stop the world. В жабе такие вещи решаются тюнингом работы gc как например в Revenge of the titans, количество используемых ключей и параметров к jvm для запуска меня удивило.
     

  • 1.95, Аноним (-), 16:31, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    func g() // !
    {        // НЕВЕРНО
    }

    if x {
    }      // !
    else { // НЕВЕРНО
    }

    func g(){ // ВЕРНО
    }

    if x {
    } else { // ВЕРНО
    }

    После этого язык GO для меня не сущесвует

     
     
  • 2.99, Аноним (-), 17:06, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    func g()// НЕВЕРНО
    {      
    }
    >>После этого язык GO для меня не сущесвует

    Платят за количество строк?
    Я знаю эти удаки на С/С++ еще и возвращаемый тип переносят на отдельную строку:



    int
    main()
    {
    //овнокод.
    }



    выглядит инфернально.

     
     
  • 3.136, Аноним (-), 18:05, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Платят за количество строк?

    Нет, просто такой код легче читать.

    > Я знаю эти удаки на С/С++ еще и возвращаемый тип переносят на отдельную строку

    Представьте себе, иногда не лишено смысла. Но вы можете продолжать писать код в одну строку, если хотите.

    Любой язык, который навязывает стиль оформления, ущербный по определению.

    // другой Аноним

     
  • 3.186, Аноним (-), 04:38, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    int
    main()

    Это оправдано, потому что в отличие от хелловордов, в реальном коде это выглядит как-то так:

    static inline struct node *
    node_create(const char *key, const char *value, int flags, size_t size)
    {
      ...;
    }

     
  • 3.220, Аноним (-), 22:16, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да, ты прав:

    https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/crtstuff.c?view=markup

    277 static inline void
    278 deregister_tm_clones (void)
    279 {
    280   void (*fn) (void *);
    281
    282 #ifdef HAVE_GAS_HIDDEN
    283   func_ptr *end = __TMC_END__;
    284   // Do not optimize the comparison to false.
    285   __asm ("" : "+g" (end));
    286   if (__TMC_LIST__ == end)
    287     return;
    288 #else
    289   if (__TMC_LIST__[0] == NULL)
    290     return;
    291 #endif

    Кругом дураки, а ты самый-самый. Иди возьми пирожок.

     
  • 2.100, Вы забыли заполнить поле Name (?), 17:12, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    он еще не компилируется с несиспользуемыми переменными
     
     
  • 3.148, Аноним (-), 18:24, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    При том, что это явно замедляет разработку, а они борются за каждую секунду разработчика
     
     
  • 4.187, Аноним (-), 04:39, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто баранье упёрство, хотя там напрашивается warning, а не error
     
  • 4.196, angra (ok), 15:36, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ты просто не понимаешь, что экономить на до не на спичках(уменьшение времени на набор текста), а на водке(уменьшение времени затрачиваемого на отладку).
     
  • 2.103, Аноним (-), 17:18, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Форматирование переносом строк для чайников, том 2.

    func g ()
    {
    // верно
    }

    func g
    (
    )
    if x
    {
    /
    *
    а
    т
    л
    и
    ч
    н
    а
    *
    /
    }

     
  • 2.107, Andrey Mitrofanov (?), 17:32, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > После этого язык GO для меня не сущесвует

    Вздох облегчения из гугля дважды обогнул шарик.

     
  • 2.146, Аноним (-), 18:21, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Я предпочитаю так:
    >if x {
    >...
    >}
    >else {
    >...
    >}

    А с функциями зависит от количества аргументов. Например часто так получается:
    >// ----------------------------
    >func g(TYPE arg1,
    >       TYPE arg2,
    >      TYPE arg3,
    >      ....)
    >{
    >...
    >}

    Но у маленьких функцию пишу так:
    >// ----------------------------
    >func g() {
    >...
    >}

    Т.к. функции отделены комментарием, не принципиально где будет открывающая фигурная скобка, всё равно всё видно сразу. Но в Go работает только последний вариант.

     
     
  • 3.188, Аноним (-), 04:41, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >func g(TYPE arg1,
    >       TYPE arg2,
    >      TYPE arg3,
    >      ....)

    Если тебе такое понадобилось, с высокой вероятностью эту функцию стоит переделать: слишком длинный список аргументов, неиспользование typedef или слишком длинные имена параметров.

     
     
  • 4.206, Аноним (-), 20:16, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Или не тратить время и оставить всё как есть
     
  • 2.197, angra (ok), 15:43, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > После этого язык GO для меня не сущесвует

    Одной из основных целей при разработке go и его дальнейшем развитии была и остается скорость сборки. Успех в этой области складывается в том числе и из таких вот мелочей. Но у таких ограничений есть и бонус - не надо ставить ';' в конце строк.

    Чтобы тебя окончательно добить, сообщу страшную вещь, на go принято пропускать код через форматировщик. В результате у всех код в одном визуальном стиле. Так что для самовыражения в форматировании действительно лучше выбрать другой ЯП.


     
     
  • 3.207, Аноним (-), 20:19, 18/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Так что для самовыражения в форматировании действительно лучше выбрать другой ЯП.

    На мой взгляд предложенное форматирование в Go - самовыражение его разработчиков. В моём круге общения такой стиль считается неправильным и не приемлем.

     
     
  • 4.224, Андрей (??), 15:59, 19/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Неправильный стиль? Синтаксически корректный стиль оформления кода не бывает неправильным! Неприемлемый - пожалуйста. На вкус и цвет, как говорится.

    А какой из общепринятых K&R, GNU, original Berkeley, Linux,.. приемлем? Или тот, что в js с jquery?

     
  • 4.232, Аноним Аналитег (?), 21:15, 20/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> В результате у всех код в одном визуальном стиле.
    > В моём круге общения такой стиль считается неправильным и не приемлем

    Мой опыт говорит, что в каждом монастыре свой code convention. Причем каждый кейс обоснуют. Многие ide позволяют подробно задать параметры форматтера. Слышали про collective code ownership?

     

  • 1.226, Анонишвили (?), 11:45, 20/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    lol no generics
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру