форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз языка программирования Go 1.8"	+/–
Сообщение от opennews (??) on 17-Фев-17, 13:03
После шести месяцев разработки компания Google представила (https://blog.golang.org/go1.8) релиз  языка программирования Go 1.8 (http://golang.org), который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок.  Код проекта распространяется под лицензией BSD. Синтаксис Go основан на привычных элементах  языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код  легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов (http://golang.org/pkg/runtime/)), что позволяет добиться производительности, сопоставимой с программами на языке Си. Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, в том числе предоставляя реализованные на уровне операторов средства для организации параллельных вычислений и  взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за допустимые области выделенных блоков памяти и обеспечивает возможность использования сборщика мусора. Основные новшества (http://golang.org/doc/go1.8), представленные в выпуске Go 1.8: -  Добавленный в прошлом выпуске (https://www.opennet.me/opennews/art.shtml?num=44972) бэкенд компилятора SSA (Static Single Assignment), обеспечивающий прирост производительности оценивается в 5-35%, задействован для всех архитектур, а не только для x86_64. Собранные с использованием нового бэкенда программы, продемонстрировали в тестах снижение нагрузки на CPU на 20-30% для 32-разрядных систем ARM. Для x86_64 отмечается увеличение производительности до 10%. По сравнению с прошлым выпуском также проведена работа по увеличению производительности компиляции, которая на системах x86_64 стала выполняться на 15% быстрее; -  Проведена работа по сокращению периодов активации сборщика мусора (https://golang.org/doc/go1.8#gc), приводящих к приостановке выполнения кода приложения. Сборщик мусора теперь осуществляет свою работу в рамках более коротких циклов, не превышающих 100 мс и обычно длящихся около 10 мс. Прекращено использование операций сканировния стека, приостанавливающих выполнение приложения; -  В модуль с реализацией функций HTTP-сервера добавлена поддержка операций Push для HTTP/2, которые позволяют серверу инициировать обращение к клиенту.  В http-сервер также добавлен режим завершения работы (graceful shutdow) с ожиданием окончания обработки активных запросов; -  В модуль context (https://golang.org/pkg/context/) добавлены средства для принудительного завершения соединений и использования таймаутов. Поддержка контекстов добавлена во многие штатные библиотеки, включая  database/sql, net (https://golang.org/pkg/net) и функцию Server.Shutdown из net/http; -  В модуль sort добавлена новая функция Slice (https://golang.org/pkg/sort/#Slice), упрощающая сортировку данных с типом slice (https://blog.golang.org/go-slices-usage-and-internals). Например, для сортировки структур по полю "Name" можно выполнить:    sort.Slice(s, func(i, j int) bool { return s[i].Name -  Добавлена поддержка 32-разрядной архитектуры  MIPS (MIPS32r1) на Linux для систем big-endian (linux/mips) и little-endian (linux/mipsle); -  Изменены требования к минимально поддерживаемым версиям: DragonFly 4.4.4, OpenBSD 5.9 и OS X 10.8; -  Значительно улучшен порт для Plan 9, почти доведены до полноценного состояния сетевые функции. URL: https://blog.golang.org/go1.8 Новость: http://www.opennet.me/opennews/art.shtml?num=46067
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Релиз языка программирования Go 1.8"	–8 +/–
Сообщение от Аноним (??) on 17-Фев-17, 13:03
Не густо
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Релиз языка программирования Go 1.8"	+18 +/–
	Сообщение от KonstantinB (ok) on 17-Фев-17, 13:08
	Производительность подняли, gc-паузу сократили, что еще надо? То, что в языке никаких принципиальных изменений, только мелкие улучшения - это отлично. Go должен оставаться простым и пригодным для изучения за несколько дней, это его основное преимущество.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "Релиз языка программирования Go 1.8"	–7 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 13:23
	>  gc-паузу сократили, что еще надо? Вообще gc убрать, сам буду кучу чистить.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	16. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от u on 17-Фев-17, 13:48
	GOGC=off
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	20. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 14:04
	И-и-и-и? Это опция активирует в Go невидимые ранне функции/операторы, типа, free()/delete?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	25. "Релиз языка программирования Go 1.8"	+7 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 14:23
	А зачем тебе все это в твоем fmt.Println("Hello World")?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	27. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 14:27
	> И-и-и-и? Это опция активирует в Go невидимые ранне функции/операторы, типа, free()/delete? И потом, если уж так чешется, берешь исходники, форкаешь и дописываешь нужный функционал. Осилишь?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	31. "Релиз языка программирования Go 1.8"	+5 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 14:48
	Полный бред. Давай мы теперь всё будем по любому поводу форкать и переписывать под себя, это ведь легко, быстро и абсолютно нормально... Тогда и смысла в языках нет, у каждого был бы свой, удобный, лично для себя,.... если всё бы было так, как Вы описываете. Но все не так, не надо писать бред.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	47. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 15:02
	> Полный бред. Давай мы теперь всё будем по любому поводу форкать и > переписывать под себя, это ведь легко, быстро и абсолютно нормально... Тогда > и смысла в языках нет, у каждого был бы свой, удобный, > лично для себя,.... если всё бы было так, как Вы описываете. > Но все не так, не надо писать бред. Вот и замечательно. Не пойму только, к чему был Ваш бред выше по ветке? Чем CPP Не устраивает? А вот ребята из гугля не поленились и наваяли язык под себя, с покером и... сборщиком мусора. Под свои задачки, видимо. Разнообразии языков и парадигм, как бэ намекает, что нет универсальных ЭФФЕКТИВНЫХ инструментов для решения всех существующих задач. И в следующий раз, когда будете сетовать на отсутствие ручных механизмов освобождения памяти, хотя бы обозначьте задачки, в которых они вам нужны. Может не тем микроскопом гвозди закалачиваете?
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	58. "Релиз языка программирования Go 1.8"	–6 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:15
	Это не мой бред выше по ветке. Меня CPP полностью устраивает (ну почти), и на гугловское п я не перейду никогда. Это очевидно язык детского уровня, для тех, кто не может освоить нормальные языки.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	66. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 15:31
	> Это не мой бред выше по ветке. Меня CPP полностью устраивает (ну > почти), и на гугловское п я не перейду никогда. Это очевидно > язык детского уровня, для тех, кто не может освоить нормальные языки. На здоровье. У меня нет таких проблем как у Вас. Дайте догадаюсь, наверняка и разговорный язык у Вас тоже единственный, русский?
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	106. "Релиз языка программирования Go 1.8"	–4 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:29
	Не угадали. Владею 3-мя разговорными языками, c++, qml, javascript, php, html, sql и т.д., всё на высоком уровне.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	119. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от _ (??) on 17-Фев-17, 17:49
	> Не угадали. Владею 3-мя разговорными языками, c++, qml, javascript, php, html, sql > и т.д., всё на высоком уровне. А по моему он там на сухую гоняет :))))
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	171. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от hhg (ok) on 17-Фев-17, 21:08
	угумс. хтмл написал, а цсс нет - косячник.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	127. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 17:56
	> Не угадали. Владею 3-мя разговорными языками, c++, qml, javascript, php, html, sql > и т.д., всё на высоком уровне. Ну я в резюмешках и не такое видел. Скромность украшает человека! Но есть проблемка, показать реальные свои проекты вы не сможете. Иначе - прощай анонимность. Ну а професионализм как раз таки определяется серьезностью проектов и умением их делать в требуемые сроки.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	170. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 20:41
	> Не угадали. Владею 3-мя разговорными языками,   > php, html, sql > html, sql > Владею 3-мя разговорными языками Русский разговорный, русский строительно-армейский, русский литературный?
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	63. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:21
	Даже в CPP уже лет 5 как ручное освобождение памяти считается дурным тоном. Есть smart pointer'ы. Если программист не совсем дурак, ему не нужен ни сборщик мусора, ни контроль за освобождением выделенной памяти. В конце концов можно использовать Rust. Там хочешь не хочешь, а язык сам контролирует время жизни объектов без всяких сборщиков мусора.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	69. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Василий Теркин on 17-Фев-17, 15:35
	> Даже в CPP уже лет 5 как ручное освобождение памяти считается дурным > тоном. Есть smart pointer'ы. Если программист не совсем дурак, ему не > нужен ни сборщик мусора, ни контроль за освобождением выделенной памяти. В > конце концов можно использовать Rust. Там хочешь не хочешь, а язык > сам контролирует время жизни объектов без всяких сборщиков мусора. Ну а я разве спорю? Можете ковыряться в проблеме любым микроскопом. А в бизнесе и продакшене - "время - деньги". И кто первый - того и тапки, пока все остальные выпиливают лобзиком очередной никому УЖЕ не нужный идеал. Вон, некоторые извращенцы на ассемблере даже операционки общего назначения пилят.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	111. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:37
	На обертывание выделения памяти в умный указатель уходит 1, максимум 2 секунды. Даже на гигантский проектах мест с ручным выделением памяти единичные случаи, т.к. есть контейнеры на любую ситуацию. За два года у вас набежит от силы 1-2 минуты потерянного времени. Экономия ни о чем...
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	157. "Релиз языка программирования Go 1.8"	–5 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:50
	Business, production -- какие великие слова в устах "Василий Теркин", делающие его речь, видимо по его мнению, значимыми и весомыми, не терпящими возражений. Быть может, пора уже отринуть ложное и стать Basil Grater? Ведь нутро-то соответствует, сознайтесь. И по-английски надо писать, по-английски, как я написал. Не надо вам этого сиволапого русского с его "дело", "производство". Не надо.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	163. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 19:09
	> Business, production -- какие великие слова в устах "Василий Теркин", делающие его > речь, видимо по его мнению, значимыми и весомыми, не терпящими возражений. > Быть может, пора уже отринуть ложное и стать Basil Grater? Ведь нутро-то > соответствует, сознайтесь. И по-английски надо писать, по-английски, как я написал. Не > надо вам этого сиволапого русского с его "дело", "производство". Не надо. Это что, попытка неуклюжего троллинга? Весьма неуклюжая, стоит заметить. Ну да ладно. На этом видимо стоит дискуссию закрыть. Для меня персоналии Роберта Гризмера, Роба Пайка и Кена Томпсона более авторитетны, чем Вы с вашими, как там "3-мя разговорными языками, c++, qml, javascript, php, html, sql и т.д., всё на высоком уровне.", которые подтвердить так и не удалось. Всего хорошего.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	193. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от angra (ok) on 18-Фев-17, 12:31
	> Даже в CPP уже лет 5 как ручное освобождение памяти считается дурным  тоном. Есть smart pointer'ы. Их вообще-то там много и каждый со своими достоинствами и недостатками. А еще есть вызов библиотечных функций, которые могут ожидать совсем не того типа указателя, что ты используешь в своем коде. > Если программист не совсем дурак, ему не нужен ни сборщик мусора, ни контроль за освобождением выделенной памяти. Если "программист" ограничивается хеловордами, то действительно не нужен.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	199. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 17:46
	Их 2 - unique_ptr и shared_ptr. И weak_ptr, немного усложненная разновидность shared_ptr. На практике в 99% случаев достаточно и используется unique_ptr.
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	79. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:57
	Лучше бы сделали опцию, которая включает/отключает сборщик мусора при запуске Go. Ну и delete/free. И пусть каждый решает сам, как лучше в каждом конкретном случае. Язык и компиляторы не должны ограничивать свободу действий.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	112. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:41
	Сборщика мусора не должно быть совсем. Есть куча техник обойтись без него и слежения за освобождением памяти программистом.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	126. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от _ (??) on 17-Фев-17, 17:55
	... и при этом есть куча языков где всё так и сделано! Вот и юзайте их, Д,Б! (С) Наше всио :-)
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	203. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 18:00
	>Сборщика мусора не должно быть совсем. Кокой юношеский максимализм. У GC есть свои плюсы, как и минусы.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	155. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от KonstantinB (ok) on 17-Фев-17, 18:45
	И что же будет с библиотеками, которые полагаются на gc? Все переписывать с какими-нибудь if (runtime.gcDisabled) {    free(slice) } ? Не надо этого в go. Он вполне завершен и целостнен в своем дизайне. При этом он, разумеется, не универсален. Если нужен жесткий реалтайм и gc-паузы категорически неприемлемы, стоит изначально выбрать другой язык.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	18. "Релиз языка программирования Go 1.8"	+10 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 13:59
	> Вообще gc убрать, сам буду кучу чистить. Тогда бери лопату и дуй чистить кучу.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	30. "Релиз языка программирования Go 1.8"	+5 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 14:46
	батенька зачем вам го? Пишите на си
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	33. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 14:49
	Неосиляторы вас загрызут за такие высказывания
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	6. "Релиз языка программирования Go 1.8"	+18 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 13:11
	Нет бы запилить несовместимый Golang 3.0 и %%%ться с ним 25 лет подряд. Вот это весело, вот это адреналин.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	176. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от anonnchick on 17-Фев-17, 21:35
	>>Нет бы запилить несовместимый Golang 3.0 и %%%ться с ним 25 лет подряд. Ветка 3.0 идет строго после 2.7
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

2. "Релиз языка программирования Go 1.8"	–1 +/–
Сообщение от Аноним (??) on 17-Фев-17, 13:03
Дебагер уже запилили?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Пользователь Debian on 17-Фев-17, 13:10
	Погуглите по слову "delve".
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	10. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 13:27
	а тебе какой нужен? а то я через плагин к Intellij Idea отлично дебажу ещё со старых версий go
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	19. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 14:02
	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
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	28. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от derlafff (ok) on 17-Фев-17, 14:28
	Эмм. gdb прекрасно работает
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	162. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 19:08
	Оно же на С написано!
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

3. "Релиз языка программирования Go 1.8"	+1 +/–
Сообщение от Nexor on 17-Фев-17, 13:07
100 МИЛЛИсекунд? В оригинале написано 10 МИКРОсекунд... кто то ошибся, но я больше склоняюсь к ошибке в исходном тексте, т.к. иначе звучит нереально
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Пользователь Debian on 17-Фев-17, 13:12
	Микросекунд, да.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	14. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от angra (ok) on 17-Фев-17, 13:47
	Миллисекунды были версии три назад, теперь речь действительно о микро, что конечно не помешает некоторым рассказывать про секундные зависания из-за gc.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	38. "Релиз языка программирования Go 1.8"	–3 +/–
	Сообщение от Я. Р. Ош on 17-Фев-17, 14:52
	> что конечно не помешает некоторым рассказывать про секундные зависания из-за gc. что не помешает некоторым фанатикам бугуртить, когда их священную корову еретики смеют в чем то обвинять
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	141. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от _ (??) on 17-Фев-17, 18:14
	Обвинить - это предъявить доказательства. У _цивилизованных_ людей а не у <your nick name>
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	180. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Sw00p aka Jerom on 17-Фев-17, 22:33
	перед тем как предъявить, нужно прочесть "Теория доказательства" Д. Гильберт-а )
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	54. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:10
	Где-то мы уже слышали эти сказки… Ах да — Оракол тоже всем любит рассказывать про "pausless GC". В смысле — в JVM можно ручками и паузы в сотые наносекунды поставить. Только наблюдаемые подвисания при неаккуратном выделении объектов никуда от этого не деваются. И при достижении предельной фрагментация всё так же идёёт полная сборка (или compacting, что по факту не лучше).
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	147. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Comdiv (ok) on 17-Фев-17, 18:24
	Было бы странно при неаккуратном выделении памяти чего-то хотеть. Free/delete тоже далеко не бесплатны, а при неаккуратном выделении вообще ведут к катастрофе.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	192. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от angra (ok) on 18-Фев-17, 12:16
	Поддержу, некоторые наивно считают, что наличие gc избавляет от необходимости думать о выделении памяти. Но именно на работу с памятью обращается первое внимание при оптимизации кода на go.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	205. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Кай on 18-Фев-17, 19:13
	> Миллисекунды были версии три назад, теперь речь действительно о микро, что конечно > не помешает некоторым рассказывать про секундные зависания из-за gc. А зачем тогда вообще нужно ручное управление памятью, если GC столь быстр?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

8. "Релиз языка программирования Go 1.8"	–1 +/–
Сообщение от Аноним (??) on 17-Фев-17, 13:22
Это версия компилятора или новая версия стандарта?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Andrey Mitrofanov on 17-Фев-17, 13:37
	> Это версия компилятора или новая версия стандарта? Нет стандарта, кроме версии компайлера.  ///про пророка писать тут===>>>
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Релиз языка программирования Go 1.8"	+5 +/–
Сообщение от angra (ok) on 17-Фев-17, 13:44
> Синтаксис Go основан на привычных элементах  языка Си с отдельными заимствованиями  из языка Python. А создатели то и не знают, что они оказывается из питона заимствовали. Они думали, что из algol-60/pascal/modula/oberon и csp/squeak/newsqueak/alef. > что позволяет добиться производительности, сопоставимой с программами на языке Си. С явой, плюсами, но не с С. На нишу С go никогда не претендовал.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	152. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Comdiv (ok) on 17-Фев-17, 18:32
	> С явой, плюсами, но не с С. На нишу С go никогда > не претендовал. Это потому что Вы сужаете изначально широкую нишу С, от которой постоянно откусывают другие языки. Тот же компилятор Go изначально был написан на C, который затем был заменён самим Go. Компилятор - это ниша C или нет? Как по мне, пересечений ниш С и Go хватает.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	191. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от angra (ok) on 18-Фев-17, 12:11
	А если я на perl сделаю прототип видеокодека, будешь ли ты считать видеокодеки нишей perl?
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	195. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Comdiv (ok) on 18-Фев-17, 15:05
	> А если я на perl сделаю прототип видеокодека, будешь ли ты считать > видеокодеки нишей perl? В самом вопросе содержатся 1-а манипуляция и 1-а логическая ошибка, правильней было бы задавать его так: > А если я на каком-нибудь языке сделаю прототип видеокодека, будете ли Вы считать > что в нишу этого языка входит создание видеокодеков? Если отвечать на исправленный вопрос, то да. Если Вы справитесь с задачей так же хорошо, как и разработчики первой версии компилятора Go, написавшие его на Си, то безусловно да. Именно в практических задачах определяется применимость языка, задающая его нишу. И если и можно утверждать, что в нишу Perl не входит создание видеокодеков, то именно потому, что за разумное времени практически значимый видеокодек написать на Perl не получится.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

15. "Релиз языка программирования Go 1.8"	–6 +/–
Сообщение от Аноним (??) on 17-Фев-17, 13:47
>добавлены средства для принудительного завершения соединений Я был более лучшего мнения об этом ЯП, заточенном на сетевые приложения. Т.е. только сейчас он научился делать FIN-FIN/ACK, RST?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от angra (ok) on 17-Фев-17, 13:50
	Нет, это вообще о другом.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	209. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 18-Фев-17, 20:41
	Опеннет превратился в ЛОР. >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/ms7... Могу тебе сразу ответить, что будет при Graceful Shutdown: опускается этап TIMEWAIT (кои составляет примерно 2 минуты и забивает список используемых сокетов). А ты знаешь к чему ведет graceful shutdown? Нет? Знаешь когда его можно юзать, а когда -- нет? Спорю, что не знаешь. Всё. Прощай опеннет. Одно школье и нубасы кругом.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	211. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от angra (ok) on 18-Фев-17, 20:59
	> Могу тебе сразу ответить, что будет при Graceful Shutdown: опускается этап TIMEWAIT Возможно это вызовет у тебя нервный смех, но это опять не о том. И если бы ты удосужился почитать описание методов, а не левую статью мелкомягких, то может быть и сам бы это понял. > Всё. Прощай опеннет. Одно школье и нубасы кругом. Вот это молодец, полностью поддерживаю твое решение. Как говорится в одной известной песне "убей их всех... начни с себя"
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	215. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 18-Фев-17, 21:12
	Ах да, мега чистильщик сообщений. Вот пруфы ЗА ТЕБЯ я дам. Как обычно. Ты же с ЛОРа, там пруфы не дают: http://man7.org/linux/man-pages/man7/socket.7.html        SO_LINGER               Sets or gets the SO_LINGER option.  The argument is a linger               structure.                   struct linger {                       int l_onoff;    /* linger active */                       int l_linger;   /* how many seconds to linger for */                   };               When enabled, a close(2) or shutdown(2) will not return until               all queued messages for the socket have been successfully sent               or the linger timeout has been reached.  Otherwise, the call               returns immediately and the closing is done in the background.               When the socket is closed as part of exit(2), it always               lingers in the background.
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	218. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 21:35
	Офигеть терминология в гугле. И пруфы аналитиков просто сыпятся. https://go.googlesource.com/go/+/53fc330e2d154443acf3d01e0d6... +// Shutdown gracefully shuts down the server without interrupting any +// active connections. Shutdown works by first closing all open +// listeners, then closing all idle connections, and then waiting +// indefinitely for connections to return to idle and then shut down. +// If the provided context expires before the shutdown is complete, +// then the context's error is returned. +func (s *Server) Shutdown(ctx context.Context) error { +    atomic.AddInt32(&s.inShutdown, 1) +    defer atomic.AddInt32(&s.inShutdown, -1) + +    s.mu.Lock() +    lnerr := s.closeListenersLocked() +    s.closeDoneChanLocked() +    s.mu.Unlock() + +    ticker := time.NewTicker(shutdownPollInterval) +    defer ticker.Stop() +    for { +        if s.closeIdleConns() { +            return lnerr +        } +        select { +        case <-ctx.Done(): +            return ctx.Err() +        case <-ticker.C: +        } +    } +} +
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	169. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от LU on 17-Фев-17, 20:17
	А я менее лучшего
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	181. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Sw00p aka Jerom on 17-Фев-17, 22:36
	>>FIN-FIN/ACK, RST? разве не ОС должна делать (точнее tcp/ip стек)?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	210. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 20:49
	Открой ты RFC 793 и прочитай кто что должен. Нубасы хреновы не знают, что делает accept(), что делает shutdown(), что делает connect(). Куда вы лезете со своими бреднями?
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	225. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Sw00p aka Jerom on 19-Фев-17, 16:29
	)))))))))))))))))) ага ЯП должен реализовывать в стд стек TCP/IP https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
	Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

	227. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 20-Фев-17, 12:35
	И что ты нашел? Что ты хочешь доказать? Что ты вообще пытаешься сказать, кроме как попытаться выставиться себя умником, выскочкой. Смотрю в школах совсем все плохо, выскочек раньше били ногами. Итак, по делу. Кто должен вызывать shutdown() на сокет? Приложение? ОС? Мифические существа внутри коробки, что называется компьютер, а для тебя процессор? Можешь ли ты внятно строить свои мысли, а, существо?
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	229. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Sw00p aka Jerom on 20-Фев-17, 17:33
	>>И что ты нашел? клондайк )) >>Что ты хочешь доказать? ну как минимум - нерешенные проблемы Гильберта >>Что ты вообще пытаешься сказать, кроме как попытаться выставиться себя умником, выскочкой. Молчание золото, я тока задал вопрос и жду ответа на него. >>Смотрю в школах совсем все плохо школу закончил эдак в 2004 году - проехали >>выскочек раньше били ногами. ведьм сжигали, еретиков подвергали экзекуции и что ? >>Итак, по делу. Кто должен вызывать shutdown() на сокет? Приложение? ОС? 1) а много таких прикладных приложений которые дёргают сискол ОС shutdown() ? 2) по таймауту сама ОС спокойно вызовет его. вы разницу между socket.c и tcp.c видите? >>Мифические существа внутри коробки, что называется компьютер, а для тебя процессор? архитектура Фон-неймана >>Можешь ли ты внятно строить свои мысли, а, существо? вы походу не прошли тест-Тьюринга ))))))))))))))))))))))))
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	231. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 20-Фев-17, 20:43
	>а много таких прикладных приложений которые дёргают сискол ОС shutdown() ? Столько же сколько дергают сискол accept(). http://man7.org/linux/man-pages/man2/accept.2.html И только не говори, что accept() НЕ посылает пакеты по TCP. Такие как SYN/ACK, ACK. Их посылает ОС. Сама. Без спросу. Когда солнце взойдет на западе и сядет на востоке. Тогда отправится пакет ACK. Все. Я добрый пока что. Иди учи сишку и читай маны.
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	234. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Sw00p aka Jerom on 20-Фев-17, 23:22
	не устраивает пакет net - узайте уже пакет syscall - вот там уж точно вы будете решать когда shutdown() вызывать ))) https://golang.org/pkg/net/ https://golang.org/pkg/syscall/ а на крайняк вам поможет что-то вроде такого интерфейса https://godoc.org/github.com/google/gopacket
	Ответить | Правка | ^ к родителю #231 | Наверх | Cообщить модератору

	235. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Sw00p aka Jerom on 21-Фев-17, 00:29
	>>И только не говори, что accept() НЕ посылает пакеты по TCP. Такие как SYN/ACK, ACK. Их посылает ОС. Сама. Без спросу. 1) не пакеты, а сегменты 2) SYN/ACK, ACK - это не пакеты, а Флаги (управляющие биты) конечно ОС сама без спросу отправляет, всё зависит какой интерфейс ос вы используете )))) и http://man7.org/linux/man-pages/man2/accept.2.html тут int flags совсем не те флаги SYN/ACK, ACK. http://rfc.com.ru/rfc793.htm 3.8. Интерфейсы
	Ответить | Правка | ^ к родителю #231 | Наверх | Cообщить модератору

	230. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Sw00p aka Jerom on 20-Фев-17, 17:43
	> Можешь ли ты внятно строить свои мысли, а, существо? Урок номер 1: Сетевая модель OSI https://ru.wikipedia.org/wiki/%D0%A1%D0%... пс: приложение приложение о каком приложении идёт речь ? ОС - тоже приложение.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

21. "Релиз языка программирования Go 1.8"	+1 +/–
Сообщение от Owlet on 17-Фев-17, 14:05
> В модуль sort добавлена новая функция Slice, упрощающая сортировку данных с типом slice Вот для чего, дети, нужны дженерики. Чтобы не было по своей функции сортировки для каждого вида последовательностей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Релиз языка программирования Go 1.8"	+6 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 14:20
	Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию, а не в Россию.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	105. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Andrey Mitrofanov on 17-Фев-17, 17:20
	> Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию, а не в > Россию. Потому что "и сами они довольно неискренние, и самовар у них" неоткровенный? :D
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	194. "Релиз языка программирования Go 1.8"	–3 +/–
	Сообщение от Michael Shigorin (ok) on 18-Фев-17, 13:03
	> Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию, > а не в Россию. Потому что у нас -- разработчики, а не кодеры?  Боюсь, Вы всё же приукрашиваете.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	212. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 21:01
	>Потому что у нас -- разработчики, а не кодеры?  Боюсь, Вы всё же приукрашиваете. Потому что ворье. Потому что Альт стоит как последняя винда в коробке. А в Индии как раз все дешево и сердито. Между прочим не видел ни одного русского разраба на андроиде, который мог тянуть фулстак разработку. А индусов полно. И все у них очень качественно. Жду рассказа про очевидные вещи #2.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	160. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от KonstantinB (ok) on 17-Фев-17, 18:55
	Вот отсутствие дженериков в том или ином виде - это действительно недостаток. Но каноничные джава-дженерики не подойдут к модели типов go. Наверное, можно было бы решить вопрос, разрешить писать реализации по умолчанию для интерфейсов, но слишком неявно получается.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

26. "Релиз языка программирования Go 1.8"	–4 +/–
Сообщение от Ilya Indigo (ok) on 17-Фев-17, 14:24
> Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. В бочку с мёдом добавили ложку дёгтя.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	44. "Релиз языка программирования Go 1.8"	–4 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:00
	Это как раз была ложка меда, тщательно выскребенная и отцеженная из бочки с дёгтем.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	179. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Led (ok) on 17-Фев-17, 22:26
	> Это как раз была ложка меда Этот "мёд" уже один раз кто-то ел.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

29. "Релиз языка программирования Go 1.8"	+1 +/–
Сообщение от Аноним (??) on 17-Фев-17, 14:32
Наконецта порт для план 9 доделали, Роб Майк своих не бросает!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

55. "Релиз языка программирования Go 1.8"	–3 +/–
Сообщение от Аноним (??) on 17-Фев-17, 15:11
Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и никаких проблем это не создаёт.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	65. "Релиз языка программирования Go 1.8"	+9 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:29
	> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и > никаких проблем это не создаёт. Совершенно никаких, даром что USE-AFTER-FREE входит в 20ку самых эксплуатируемых уязвимостей. Примерчик с пылу с жару: CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	68. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:35
	Мне кажется люди просто не знаю, что уже давно проблема ручного контроля освобождения памяти решена std::unique_ptr. Все до сих пор считают что там, где нет сборщика мусора, надо писать что-то вроде: > TYPE n = new TYPE() > ..... > // много кода > delete n; Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а не когда соизволит сборщик.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	73. "Релиз языка программирования Go 1.8"	+3 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 15:45
	> Мне кажется люди просто не знаю, что уже давно проблема ручного контроля > освобождения памяти решена std::unique_ptr. Все до сих пор считают что там, > где нет сборщика мусора, надо писать что-то вроде: >> TYPE n = new TYPE() >> ..... >> // много кода >> delete n; > Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а > не когда соизволит сборщик. Ну да, ну да... Когда НУЖНО программисту. Только страдают от этого потом пользователи и системы. Ведь программист, в силу своего эгоцентризма, даже не подозревает, что задачки, выполняемые его кодом, могут быть не самыми приоритетными в системе. Или программеры уже научились предугадывать в каком "обвесе" будет работать их код в будущем? В свое время для этого и придумали API, чтобы юные вундеркинды не крашили систему прямым управлением аппаратными ресурсами.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	77. "Релиз языка программирования Go 1.8"	–4 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:55
	Сборщик мусора не удалит объект, пока на него есть ссылки. И запускается он через определенные промежутки времени. Т.ч. в языке со сборщиком мусора объекты могут жить дольше, но не меньше. И при этом дольше - это обычно во много раз дольше. В с++ даже локальный объект можно удалить автоматически до выхода из функции просто ограничив ему область видимости фигурными скобками. В том же Go он будет жить еще несколько мс после завершения функции, пока сборщик не соизволит пошевелиться.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	86. "Релиз языка программирования Go 1.8"	+7 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 16:10
	> Сборщик мусора не удалит объект, пока на него есть ссылки. И запускается > он через определенные промежутки времени. Фееричные-познания-в-теме-рука-лицо.жпг > В с++ даже локальный > объект можно удалить автоматически до выхода из функции просто ограничив ему > область видимости фигурными скобками. В том же Go он будет жить > еще несколько мс после завершения функции, пока сборщик не соизволит пошевелиться. Опять тайные знания? На самом деле есть только один GC, а еscape анализ придумка маркетологов?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	121. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:52
	Ветка про сборщик мусора, а не про Go. Везде разные реализации сборщика.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	133. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:01
	> Ветка про сборщик мусора, а не про Go. Ответ как раз про _сборщики_ мусора, а не специфику го. > Везде разные реализации сборщика. Алгоритмов сборки целая куча. И работают они очень по разному. И да, упоминание "а вот так можно в плюсах" тоже не в тему - это особенность конретного ЯП.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	90. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 16:23
	> В том же Go он будет жить еще несколько мс после завершения функции, пока сборщик не соизволит пошевелиться. Go использует стандартную реализацию стека. Все локальные переменные будут удалены* мгновенно при возврате из функции, аналогично с/с++. *Указатель на стек вернется в состояние до вызова функции.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	97. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от hoopoe (ok) on 17-Фев-17, 16:47
	там же замыкания на уровне языка реализованы... как их на стек положить?
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	125. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от Мяут (ok) on 17-Фев-17, 17:55
	Там компилятор автоматически определяет, нужно ли переменную на стеке создавать (если она не покидает пределов области видимости) или в куче. Можно -gcflags -m использовать, оно скажет что будет на куче создаваться. Например: type S struct {     I int } func foo() func () S {     var s S     fmt.Scan(s.I)     return func () S { return s } } скажет "src/stack.go:13: s.I escapes to heap" UPD: благодаря этому можно кстати поинтеры на локальные переменные возвращать без плохих последствий
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	172. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 21:11
	Еще зависит от размера и типа переменной и от самой функции, как она вызывается. Стек не резиновый...
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	123. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:53
	В общем случае да, но есть исключения
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	78. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:56
	Системы с ограниченными ресурсами самое то, чтобы распылять их на потуги сборщика и висящие неиспользуемые объекты, которые он непонятно когда удалит.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	87. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 16:12
	У вас в квартире дверь есть?
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	120. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:50
	У вас в квартире унитаз есть?
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	132. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:00
	В магазине: - У вас трусы есть? - Нет. - А в продаже?
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	156. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:48
	На автоматическое управление памятью тратятся вычислительные ресурсы машины. На ручное управление памятью тратятся временные ресурсы программиста. Говорить о том, какой выбор оптимальнее можно только в конкретных случаях. Например, если использовать ручное управление памятью и потерять на это месяц работы, мы заработаем примерно $10000, а если направим время программистов на написание фичи X, то заработаем примерно $15000, 15000 > 10000 -> нет смысла тратить время на ручное управление памятью.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	173. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 21:14
	Написали уже, оптимальный - умные указатели. Никакого тебе сборщика мусора и ручного освобождения памяти. Месяц вы никак не потеряете, обернуть вызов new в умный указатель - пара секунд. > TYPE *p = new TYPE(); в > std::unique_ptr<TYPE> p(new TYPE()); И всё.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	80. "Релиз языка программирования Go 1.8"	–3 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:57
	Краши уже в прошлом, есть статические анализароры, умные указатели, диапазонные циклы и т.д.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	88. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Василий Теркин on 17-Фев-17, 16:13
	> Краши уже в прошлом, есть статические анализароры, умные указатели, диапазонные циклы и > т.д. Вы серьезно?
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	124. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:55
	Для меня да. Ваш уровень знания языка вероятно гораздо ниже, раз краши для вас обыденность.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	140. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 18:12
	> Для меня да. Ваш уровень знания языка вероятно гораздо ниже, раз краши > для вас обыденность. А что написали? Судя по приводимым в этой ветке примерам - код из популярной серии "С++ для чайников за 7 дней".
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	94. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от Ordu (ok) on 17-Фев-17, 16:30
	> Мне кажется люди просто не знаю, что уже давно проблема ручного контроля > освобождения памяти решена std::unique_ptr. Все до сих пор считают что там, > где нет сборщика мусора, надо писать что-то вроде: >> TYPE n = new TYPE() >> ..... >> // много кода >> delete n; > Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а > не когда соизволит сборщик. Если бы всё было так просто, то мемликов бы не было. Вообще нигде не было бы, даже в ассемблере. Иногда хочется иметь ссылку на объект в разных стековых фреймах, а иногда ещё и в структурке хранить её удобно. А ещё иногда объект прямо или косвенно ссылается сам на себя, тогда даже ref_count не всегда спасает.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	108. "Релиз языка программирования Go 1.8"	–3 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:35
	> Если бы всё было так просто, то мемликов бы не было. А не всё так просто. Но и не всё так ужасно. > Вообще нигде не было бы, даже в ассемблере. Как это? В ассемблере же ни смарт-пойнтеров, ни сборщика мусора нет. Наверное какая-то глубокая философия была. > Иногда хочется иметь ссылку на объект в разных стековых фреймах, а иногда ещё и в структурке хранить её удобно. "В структурке"? Сишника в вас ощущаю я. В С++ есть решение из коробки, std::shared_ptr. Помогает в большинстве случаев. Понятно, что можно извратиться и его обмануть. Но тогда можно и своё решение для этой категории изврата написать. > А ещё иногда объект прямо или косвенно ссылается сам на себя, тогда даже ref_count не всегда спасает. В этом случае и сборщик мусора не всегда спасает. Вот вам хорошая презенташка про утечки памяти в Java: http://www.slideshare.net/RafaelWinterhalter/a-topology-of-m...
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	158. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Ordu (ok) on 17-Фев-17, 18:51
	>> Вообще нигде не было бы, даже в ассемблере. > Как это? В ассемблере же ни смарт-пойнтеров, ни сборщика мусора нет. Наверное > какая-то глубокая философия была. Потому что до тех пор, пока у нас есть указатель вписывающийся в идею uniq_ptr, отследить время жизни объекта не просто, а крайне просто. Я не знаю кем надо быть, чтобы забыть его удалить. >> Иногда хочется иметь ссылку на объект в разных стековых фреймах, а иногда ещё и в структурке хранить её удобно. > "В структурке"? Сишника в вас ощущаю я. Пфеу. > В С++ есть решение из коробки, std::shared_ptr. Помогает в большинстве случаев. Угу. Да, подсчёт ссылок решает большинство таких проблем, я о том и говорю. Но не все. Я когда-то читал у Кнута, что подсчётом ссылок можно решать на системном уровне даже работу с циклическими объектами, но с тех пор так и не собрался походить по ссылкам и выяснить -- не врал ли он. >> А ещё иногда объект прямо или косвенно ссылается сам на себя, тогда даже ref_count не всегда спасает. > В этом случае и сборщик мусора не всегда спасает. В этом случае спасает. Даже консервативный сборщик мусора одетый на C++ сможет эту проблему вычленить и освободить память. Правда он консервативный -- он не имеет информации о типах переменных, и поэтому если какой-нибудь буфер, куда был прочитан файл, содержит значение похожее на указатель в потерянный объект, то он сохранит этот объект на всякий случай. > Вот вам хорошая презенташка про утечки памяти в Java: > http://www.slideshare.net/RafaelWinterhalter/a-topology-of-m... Ой, ну естественно. Если ты подключаешь к программе со сборкой мусора библиотеки без сборки мусора, то их объекты сборщик мусора не может тупо удалять, потому что он не может проверить unsafe код на предмет владения указателями. Если ты начинаешь использовать unsafe код, то половина гарантий, которые даёт язык просто отваливаются, и там всё упирается в то, способен ли ты управлять памятью вручную. Это проблемы не сборщика мусора, как такового -- это проблемы вылезающие из-за неиспользования сборщика мусора кодом.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	165. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 19:31
	> Потому что до тех пор, пока у нас есть указатель вписывающийся в идею uniq_ptr, отследить время жизни объекта не просто, а крайне просто. Я не знаю кем надо быть, чтобы забыть его удалить. Не всегда просто. Легко забыть сделать delete перед return в середине функции. Особенно если указателей несколько, return-ов тоже несколько, и надо перед разными return надо делать разный набор delete. Также вместо преждевременного return бывает исключение, да ещё в какой-нибудь вложенной функции. > Пфеу. Принято. :) > Да, подсчёт ссылок решает большинство таких проблем, я о том и говорю.  Но не все. Так и GC не все. Да, теоретически GC может освободить больше памяти, чем RAII. А практически - оба подхода работают очень хорошо. А RAII может ещё и другие ресурсы автоматически освобождать, например закрывать файлы, сетевые соединения, БД-соединения и т.д. > В этом случае спасает. Циклические ссылки циклическим ссылкам рознь. Не всегда GC может их правильно раскрутить. > unsafe код Посмотрите презентацию повнимательнее, дальше 7-й страницы. Так не только unsafe код.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	168. "Релиз языка программирования Go 1.8"	+3 +/–
	Сообщение от Ordu (ok) on 17-Фев-17, 20:10
	>> Потому что до тех пор, пока у нас есть указатель вписывающийся в идею uniq_ptr, отследить время жизни объекта не просто, а крайне просто. Я не знаю кем надо быть, чтобы забыть его удалить. > Не всегда просто. Легко забыть сделать delete перед return в середине функции. > Особенно если указателей несколько, return-ов тоже несколько, и надо перед разными > return надо делать разный набор delete. Также вместо преждевременного return бывает > исключение, да ещё в какой-нибудь вложенной функции. Вот нефиг писать исключительно на C++. Попробуй пописать на C или asm годик, тебе в кровь въестся идея, что return из середины функции -- это плохо, и прежде чем так делать, нужно три раза подумать. ;) Это реально выходит на уровень условного рефлекса, который срабатывает всегда, при виде return, за которым тело функции продолжается. Даже если писать приходится на питоне -- всё равно срабатывает. Так и хочется вместо return написать goto finish. Или, если на C/asm аллергия, то вместо них можно попробовать какую-нибудь функциональщину, в которой вообще использование return -- признак дурного тона, а для cleanup кода, если он нужен, есть какой-нибудь особый костыль, позволяющий обходиться без return и без создания временной переменной для хранения результата вычислений, пока выполняется этот самый cleanup код. Что-нибудь типа unwind-protect в common lisp'е. >> Да, подсчёт ссылок решает большинство таких проблем, я о том и говорю.  Но не все. > Так и GC не все. Да, теоретически GC может освободить больше памяти, > чем RAII. А практически - оба подхода работают очень хорошо. А > RAII может ещё и другие ресурсы автоматически освобождать, например закрывать файлы, > сетевые соединения, БД-соединения и т.д. Я в последний раз сталкивался с жабой лет пятнадцать назад, но даже тогда она умела закрывать файловые дескрипторы, когда умирали объекты, владеющие ими. Там было что-то типа метода finalize -- деструктор, который вызывался непосредственно перед освобождением памяти. Это было дерьмово, потому что пока сборщик мусора не выяснит, что объект умер, он не вызовет finalize, а finalize не вызовет close(2) и файловый дескриптор будет оставаться открытым, что неудачно, если много файловых дескрипторов открывается и закрывается. Поэтому всё равно, стоило закрывать файлы прежде чем терять ссылки на них. Но это было даже тогда. Ну, чтобы это работало, конечно же, надо избегать работать с файловым дескриптором напрямую и работать с ним исключительно через посредство специально созданного объекта со специально заточенным finalize. >> В этом случае спасает. > Циклические ссылки циклическим ссылкам рознь. Не всегда GC может их правильно раскрутить. Если циклическая ссылка недоступна из корневого указателя, то gc её даже не найдёт, потому что он ищет не объекты, которые нужно удалять, а объекты, которые нужно сохранять. Может речь про вызов деструкторов циклического объекта? Там, вероятно, могут возникать проблемы -- если у нас есть цикл из однотипных объектов, то чей деструктор вызывать первым? М-м-м... Я не думал об этом. Может просто вызвать их в рандомном порядке? Какая собственно разница. >> unsafe код > Посмотрите презентацию повнимательнее, дальше 7-й страницы. Так не только unsafe код. Я не умею смотреть презентации, я их не понимаю -- какие-то случайным образом раскиданные по слайду непонятные схемки и буковки... Можно мне сам доклад текстом, а не только картинки из него?
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	175. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 21:21
	> return из середины функции -- это плохо Может так и есть, но ведь так удобно! :) Выяснил, что больше делать нечего, и до свиданья. И, продолжая минутку юмора, если не делать ранних return-ов, может получиться вот так: https://pbs.twimg.com/media/Bp1IyS7CYAATIEB.jpg :) > finalize -- деструктор ... дерьмово Да, вот я про это самое. > пока сборщик мусора не выяснит, что объект умер, он не вызовет finalize Это условие необходимое, но недостаточное. Время вызова finalize, увы, неопределено, и  сборщик мусора любит оттягивать сборку насколько это возможно. > лет пятнадцать назад С тех пор (а может и тогда было) придумали finally и try-with-resources, что, в общем-то, неплохо. В отличие от деструктора, работает только в одном scope. > Можно мне сам доклад текстом Поискал специально для тебя, не нашёл. :( Хотя доклад очень хороший был. Нашёл другое: The different kinds of Java memory leaks and how to analyze them https://www.dynatrace.com/resources/ebooks/javabook/memory-l.../ Один из разделов, кстати, называется "Circular and Complex Bi-Directional References". Ну и на гугле, и на ютубе тоже, на эту тему много.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	178. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Ordu (ok) on 17-Фев-17, 22:17
	>> return из середины функции -- это плохо > Может так и есть, но ведь так удобно! :) Выяснил, что больше > делать нечего, и до свиданья. Ну, много чего есть удобного, что потом может выйти боком. Для этого и придумывают всякие CodingStyle, чтобы ограничить программиста в том, какие глупости он может совершить. > И, продолжая минутку юмора, если не > делать ранних return-ов, может получиться вот так: https://pbs.twimg.com/media/Bp1IyS7CYAATIEB.jpg > :) :) Да, я сталкивался с таким. Причём в C коде. Причём авторства IBM. Но там было хуже, там вперемешку десятками вкладывались if, for, while... И отступы по два пробела. Здесь-то однотипные проверки, которые можно раскидать по функциям и вызывать их в цикле, а можно и ничего не делать -- и так в общем-то понятно что происходит. Но в том драйвере флоповода был просто вынос мозга. Причём не в одном каком-то месте, а постоянно. > Нашёл другое: > The different kinds of Java memory leaks and how to analyze them > https://www.dynatrace.com/resources/ebooks/javabook/memory-l.../ Спасибо. > Один из разделов, кстати, называется "Circular and Complex Bi-Directional References". Там не memleak. Или, если очень хочется, то memleak, но не в строгом понимании этого слова -- всё совершенно законно. Если мы храним Node, а Node зачем-то хранит Document, то память доступна приложению. Удаление нода приведёт к удалению Document. То есть это наверное неудобно для кодера -- ему надо для отлавливания таких штук понимать, как работает API, которым он пользуется, но я не вижу что с этим можно сделать, со сборщиком мусора или без него. Хотя... lifetimes и borrowing позволяют творить чудеса... может и можно спроектировать API так, чтобы если не решить проблему вообще, то хотя бы ограничить её рамками lifetime'а переменной, хранящей Document. Может быть даже удастся обойтись без сборки мусора (и без gc, и без счётчика ссылок) для последующего освобождения памяти Node. Но, соглашусь, lifetime/borrowing это уже не GC, а другой способ решения проблемы. > Ну и на гугле, и на ютубе тоже, на эту тему много. Ну, мне на самом деле не очень интересно -- интересно, но не настолько, чтобы я погрузился бы в поиски: я не думаю, что вдруг я найду, что-то новое. Если бы я писал на жабе или го, то пошёл бы и поискал, но я не пишу на них.
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	184. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от анонимчик on 17-Фев-17, 23:23
	>В С++ есть решение из коробки, std::shared_ptr. Помогает в большинстве случаев. который на каждый чих мьютекс блокирует.. проще на питоне написать и слипы повставлять.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	128. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:56
	Во всех этих случаях требуется пересмотр архитектуры приложения.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	164. "Релиз языка программирования Go 1.8"	+3 +/–
	Сообщение от Ordu (ok) on 17-Фев-17, 19:26
	> Во всех этих случаях требуется пересмотр архитектуры приложения. Требуется. И что? Ну пересмотришь ты её, а дальше что? Будешь переписывать пару сотен тысяч строк кода? Или ты до сих пор веришь в миф 90-х годов о том, что программу можно спроектировать заранее так, чтобы потом не возникало проблем с архитектурой?
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	182. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 23:06
	> Или ты до сих пор веришь в миф 90-х годов о том, что программу можно > спроектировать заранее так, чтобы потом не возникало проблем с архитектурой? Это "стало мифом", когда стало модно быть балбесом.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	185. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Ordu (ok) on 18-Фев-17, 00:03
	Может быть. Но я склонен разделять мнение этих 95%, которые считают, что проблема в возросшей сложности софта. Пару месяцев назад я читал статейку -- ребята провели исследования нескольких крупных проектов, на предмет взаимосвязей между различными частями кода, причём как-то они этот код разбивали по уровням примерно так (сейчас я навру скорее всего, потому что не помню, но сочиняю): минимальное деление -- код разбивается на функции, среднее -- на файлы, крупное ещё как-то. И просто посчитали количество ссылок по горизонтали -- между частями одного уровня, и по вертикали, между частями разных уровней. Цель была оценить качество кода -- чем меньше взаимосвязей, тем лучше проектирование. Так вот, там большинство проектов или даже все на низком уровне показывали весьма пристойный уровень проектирования, на среднем было ~50/50, а на верхнем у всех получался бардак, безумная мешанина из связей между различными частями. Вывод напрашивается очевидный: человек просто не способен проектировать системы подобной сложности. И если осталость в мире 5% уникумов, которые могут, то, во-первых, найти их не удастся ни мне, ни тебе, а во-вторых, это не надолго: пройдёт ещё пять лет, и эти 5% тоже сломаются под всё возрастающей сложностью софта. Там, правда, выборка была небольшая -- меньше десяти проектов, но там были проекты на C, на C++, Java -- это я точно помню. И вывод этот очень хорошо укладывается в общую картину. Я, к сожалению, ссылку не могу найти, чтобы ты сам мог бы посмотреть в деталях.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	190. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 18-Фев-17, 08:39
	KISS.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	198. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от chinarulezzz (ok) on 18-Фев-17, 16:20
	Потому что, если не вся, то большая часть _сложности_ вытекает из 1) незнания: хождения вслепую, велосипедов с квадратными колёсами, антипаттернов, спагетти-кода, и т.п. 2) экономики: комбайны, обфускация и усложнение исследования кода для конкурентного преимущества и т.п. Всё гениальное -- просто, KISS не выгоден ввиду сложившейся системы: #Комбайнёры, комбайнёры © #I want to ride my bicycle ©
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	118. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:49
	Нет, не решена. Программист должен изначально знать нужен ему unique_ptr или shared_ptr, а может weak_ptr? В языках с GC об этом можно просто не думать, там везде shared_ptr. Это ещё не говоря о том, насколько замусоривается код: fun() -> std::unique_ptr<std::array<std::shared_ptr<Node>>>;
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	131. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:00
	shared_ptr, а уж тем более weak_ptr - это вообще наиредчашие случаи. Я за 15 лет программирования shared_ptr использовал только один раз. А код замусоривается потому что неправильно пишете. Вот это вот: > std::unique_ptr<std::array<std::shared_ptr<Node>>> очевидно неправильная конструкция, надо разбираться, почему такая х получилась.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	149. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:25
	Не думаю, что редчайшим случаем является ситуация, когда неизвестно кто из владельцев должен уничтожить объект. А ещё, по хорошему, нужна невладеющая обёртка поинтера, см observer_ptr. Итого программист выбирает между хранением и передачей по значению, голому указателю, уникальному указателю, разделяемому указателю, weak указателю, observer_ptr, ссылке, std::reference_wrapper (враппер ссылки). Хороший язык, ничего не скажешь, есть инструменты на все случаи жизни. Только кто в этом разбираться будет? Семантика копирования, семантика перемещения.. Подскажите, как правильно, пожалуйста. Потому что в моём коде такое часто встречается. Использую алиасы типов. using BucketType = std::vector<NodeInfo>; using Bucket = std::unique_ptr<BucketType>; using Buckets = std::array<Bucket, Parameters::B>;
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	177. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 21:43
	> Не думаю, что редчайшим случаем является ситуация, когда неизвестно кто из владельцев должен уничтожить объект. Ситцация, когда нужен shared_ptr? Такая ситуация является просто очень редкой. По сравнению с unique_ptr. А редчайший случай (хоть и не невозможный) - это когда кажется, что хватит и unique_ptr, а потом оказывается, что не хватает, и нужен shared_ptr. > Подскажите, как правильно, пожалуйста. Потому что в моём коде такое часто встречается. Использую алиасы типов. > using BucketType = std::vector<NodeInfo>; Пойдёт как syntax sugar. > using Bucket = std::unique_ptr<BucketType>; Не нужно, вектор и так в куче выделяет. Разве что хочется гарантировать уникальность (некопирование). > using Buckets = std::array<Bucket, Parameters::B>; Двумерный массив типа? Можно так, можно вектор векторов.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	189. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Андрей (??) on 18-Фев-17, 07:25
	> Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а не когда соизволит сборщик. А что с динамическим выделением объекта? Он-то выделится тогда, когда это нужно программисту, но от этого не легче, так как алгоритм выделения в куче не ограничен константным временем. А всё дело во времени: не хочется иметь непредвиденных задержек. Так вот с GC они и так уже небольшие, а что с выделением в куче?
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	200. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 17:49
	Какой аллокатор напишешь - так и будет выделяться. А GC никогда не был и не будет предсказуем.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	223. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Андрей (??) on 19-Фев-17, 15:48
	> Какой аллокатор напишешь Так можно и язык свой написать. Я говорю о тех, что под капотом в glibc и в stdlibc++. По-умолчанию (начиная с какого-то размера объекта, наверное), он тоже не предсказуем. Да ещё и куча фрагментируется.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	219. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 18-Фев-17, 22:04
	Ты ничего не смыслишь в программировании.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	104. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:19
	>> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и >> никаких проблем это не создаёт. > CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10 Абы ляпнуть чтоль? Ядро Linux написано НЕ на С++. Ваш Кэп.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	110. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 17:37
	>>> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и >>> никаких проблем это не создаёт. >> CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10 > Абы ляпнуть чтоль? > Ядро Linux написано НЕ на С++. Ваш Кэп. Писали бы на С++ вообще бы Линукса до сих пор не было.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	113. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:42
	Что за перевод темы такой? Пассаж про CVE-2016-7117 не в тему к С++ был, так или нет?
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	145. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Василий Теркин on 17-Фев-17, 18:19
	> Что за перевод темы такой? Пассаж про CVE-2016-7117 не в тему к > С++ был, так или нет? Все в тему. С и ассемблер тоже без мусорки. Но и без ООП со всякими с++ плюшками. Поэтому разрабы до сих пор не рискуют переводит код ядра на с++. Слишком большой код и слишком малдо времени, чтобы его отладить.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	174. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 21:17
	> Ядро Linux написано НЕ на С++. Ваш Кэп. На Go что ли? Если серьезно, причем здесь ядро вообще?
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	183. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 23:23
	> > Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и > > никаких проблем это не создаёт. > Примерчик с пылу с жару: > CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10 Ядро Linux это примерчик того, что в C++ нужен сборщик мусора? Ну вот как, как к таким умозаключениям приходят? P.S. Эта критическая дыра не зависит от сборщика мусора в C++, так как ядро Linux не на C++ написано.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	93. "Релиз языка программирования Go 1.8"	+4 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 16:26
	Да-да, С++ нахваливают, что память нужно вручную освобождать и юзают при этом умные указатели
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	109. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:37
	Взаимоисключающие утверждения?
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	134. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:03
	Как раз вручную память освобождать не следует. И язык позволяет обходится без этого непотребства и сборщика мусора одновременно.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	96. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Толл on 17-Фев-17, 16:35
	>>Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и никаких проблем это не создаёт. Сильное утверждение. Проверять я его, конечно же, не буду. (с)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	135. "Релиз языка программирования Go 1.8"	–4 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:05
	Вот и создатели Go не стали. И получилось что имеем - большой костылище для решение проблемы, решаемой простой структурой - умным указателем.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	154. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от Mike Lee on 17-Фев-17, 18:45
	Точно. Засунем все в смартпоинтеры, потрахаемся с копированием, удалим auto_ptr потому что не работает, добавим мув семантики, но будем понтоваться, что сборщик мусора не нужен.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	201. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 18-Фев-17, 17:56
	Смарт поинтеры нужны в единичных случаях, т.к. обычно достаточно контейнеров. В мув семантике ничего сложного нет, rvalue ссылки + конструктор перемещения, осваивается минут за 10. Смарт поинтера по сути 2 - unique_ptr для единоличного владения и shared_ptr для множественного. Проблемы по сути нет, а уж воротить для её решения GC - верх иди
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	98. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 17:05
	> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и > никаких проблем это не создаёт. Прогони в С++ 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 сишарпа по рантайму. Да, конечно, примерчик так себе, но показателен. Аллокаторы тоже жрут ресурсы, представь себе!
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	101. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Василий Теркин on 17-Фев-17, 17:14
	> Прогони в С++ Стырено в https://habrahabr.ru/post/148657/ Но смысл понятен. Сборщик мусора, оптимизированный под эффективную работу с кучей для приложения, будет предпочтительней "ручного управления". Разработчику не придется придумывать свой "велосипед" и тратить лишнее время на оптимизацию кода, добиваясь приемлимого рантайма. Время - деньги. Да, конечно, в особо экзотических случаях ручное управление дает большее пространство для маневра в плане производительности. Но в крупных проектах это так же приводит к неприемлимым срокам сдачи. Одно дело написать драйвер устройства, и совсем другое - распределенную систему управления банковскими транзакциями. Накладные расходы, связанные с наличием сборщика мусора решаются другими способами, на уровне реализации системы в целом, а не на уровне кода приложения.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	139. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:11
	> Да, конечно, примерчик так себе, но показателен Не показателен. Так никто не пишет. Для С# это вполне нормальный код, т.к. разработчик не должен знать как всё устроено внутри и язык не должен выполнять код буквально. C++ же дает гарантии, что код будет выполнен точно так, как напишет программист. Поэтому программист должен понимать как и что работает, и писать правильно.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	143. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:17
	> Поэтому программист должен понимать как и что работает, и писать правильно. Только вот считающих, что уж они понимают, как что-то работает, во все времена было больше действительно понимающих. Особенно, если важна не только принципильная схема, но и нюансы.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	151. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 18:31
	>> Да, конечно, примерчик так себе, но показателен > Не показателен. Так никто не пишет. Для С# это вполне нормальный код, > т.к. разработчик не должен знать как всё устроено внутри и язык > не должен выполнять код буквально. C++ же дает гарантии, что код > будет выполнен точно так, как напишет программист. Поэтому программист должен понимать > как и что работает, и писать правильно. Ну тогда напиши код для cpp "правильно", сделав тоже самое, но за меньшее время чем это делается сишарпе. Задачка-то простая.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	166. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 19:37
	Да запросто: { } (компилятор соптимизировал всё в ноль)
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	202. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 17:59
	Решение предельно простое, не выделять память 10000000 раз, как ииот.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	150. "Релиз языка программирования Go 1.8"	+3 +/–
	Сообщение от Ivan (??) on 17-Фев-17, 18:30
	Не хочется кормить тролля, но один раз отвечу. Данный пример ничего полезного не делает и clang 3.9.1 компилирует его в функцию из одной инструкции ret: https://godbolt.org/g/aKZsWT Я думаю можно с уверенностью сказать, что нет ничего быстрее, чем пустая функция. Но это всё благодаря оптимизации, когда мы видим, что память выделилась и тут же освободилась мы можем заменить аллокацию в хипе на аллокацию в стеке. GCC такую оптимизацию не делает. Я не знаю, про какую реализацию .NET ты говоришь, но приведенный код тоже может быть соптимизирован в ничто. Хочу обратить внимание, что данный код на C++ пессимизирован и правильнее было бы создавать объект в стеке, просто: Node v; Тогда оба компилятора и clang и GCC компилируют код в пусто. С бенчмарками есть одна проблема. Существует множество различных программ, в бенчмарке автор выбирает одну из них и сравнивает на ней. Вопрос, почему мы считаем этот один пример вообще репрезентативным? Я хочу обратить внимание вот на какой факт. Все современные аллокаторы памяти работают для маленьких объектов (до ~1kb, а это 99.9% всех объектов) за O(1). Все современные GC так или иначе обходят весь хип, это может по разному называется, но это происходит. Они стараются делать это как можно реже (применяют гипотезу поколений, используют счетчики ссылок, чтобы не обходить, когда не возникают циклы -- разные делают разному), но это всё равно проиходит. То есть мы сравниваем O(1) и O(размера хипа). Есть ещё один момент компирующие сборщики мусора копируют объекты. Как правило увеличение размера объектов приводит к тому, что GC случаются чаще и копировать памяти нужно больше. Т.е. GC чувствителен к размеру наших объектов. Обычные аллокаторы памяти на 64-битных системах к этому не чувствительны. Таким образом по мере роста размера хипа и увеличения размера объектов GC будет работать всё хуже и хуже по сравнению с обычным аллокатором памяти. Конечно обычные бенчмарки обычно проводятся в условиях почти идеальных для GC (маленькие объекты, маленький хип). Ещё один способ наврать в бенчмарках это заточиться на гипотезу поколений и сделать так, чтобы все объекты умирали не выходя из Gen0, собственно, что ты сделал в своем примере. Но ответ на это очень простой -- если объект коротко живущий его надо создавать в стеке. И если мы для коротко живущих объектов будем использовать стек, то на долго живщих обычный аллокатор, скажем jemalloc или tcmalloc, порвет на тряпки дотнетовский Gen2 GC.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	161. "Релиз языка программирования Go 1.8"	+2 +/–
	Сообщение от Василий Теркин on 17-Фев-17, 18:55
	> Не хочется кормить тролля, но один раз отвечу. Спасибо за развернутый ответ. Но я НИКОГДА и не спорил, что в С++ с его гибкостью нельзя решить задачку идеально, по сравнению с другими ЯП. Но, за это придется заплатить. 1. Время разработки/отладки 2. Квалификация программиста. И 90% программистов будут писать код "что вижу то и пишу", и без дополнительных механизмов повышения качества конечного продукта, увы, не обойтись. Поэтому Java в свое время оккупировала рынок энтерпрайз систем, вытеснив с этой ниши С и С++. Как я уже говорил, в некоторых случаях скорость разработки РАБОТОСПОСОБНОГО решения превалирует над макисмальной возможной скоростью его быстродействия. А требования к надежности и предсказуемости работы кода еще более сужают нишу применения с++. Высококлассных программистов в наше время не так уж и много, чтобы решать весь спектр существующих задач. ЯП - всего лишь инструмент. И если этот инструмент решает поставленные задачи - это хороший инструмент. А беседы об идеальных инструментах на все случаи жизни - это уже из разряда религий и верований.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	167. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 19:45
	А что про Python и Ruby скажете? Скорость разработки на них выше, чем на Java. И, подозреваю, выше, чем на Go. Считаете, что дольше надо будет добиваться РАБОТОСПОСОБНОГО решения?
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	228. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Василий Теркин on 20-Фев-17, 14:56
	Ну вроде оба этих языка относятся к интерпретируемым(за исключением отдельно привязываемых костылей). И у обоих есть сборщики мусора. И если решение на этих языках конкретных задач более эффективно, чем на GO или С++, то я отношусь к этим языкам весьма положительно. И буду дальше добиваться РАБОТОСПОСОБНОГО приложения, по причине того, что НЕРАБОТОСПОСОБНЫЕ никому не нужны, кроме их авторов.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

64. "Релиз языка программирования Go 1.8"	+1 +/–
Сообщение от Аноним (??) on 17-Фев-17, 15:26
Осторожно, влюбиться в него очень просто. При этом уровень вхождения выше среднего, из-за настроек, что отсекает Гкодеров типа PHP.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	70. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 15:39
	Всё ровным счетом наоборот. И настройки не относятся к уровню вхождения в язык. Настроить может любой другой человек, помимо программиста. А программисту знать настройки чтобы писать код - не нужно.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	75. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Василий Теркин on 17-Фев-17, 15:49
	> Всё ровным счетом наоборот. И настройки не относятся к уровню вхождения в > язык. Настроить может любой другой человек, помимо программиста. А программисту знать > настройки чтобы писать код - не нужно. Разве что программисту на бэйсике. А уж CPP-программеру, например, без знания настроек компилятора... Совсем худо.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	81. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 16:00
	> sudo apt-get install qt-sdk или если под виндой - скачать и поставить sdk с оф.сайта. Дальше можно писать код. Чтобы собрать - надо нажать кнопочку в левом нижнем углу. И ни капельки не худо.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	82. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 16:02
	Хотя в конкретном случае Qt Creator достаточно, он сам подтянет зависимости
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	102. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аномномномнимус on 17-Фев-17, 17:16
	Хорошая шутка юмора, но нет, уж лучше старый добрый C++
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	137. "Релиз языка программирования Go 1.8"	–3 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:06
	Язык без дженериков не нужен.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

91. "Релиз языка программирования Go 1.8"	–1 +/–
Сообщение от Аноним (??) on 17-Фев-17, 16:25
А если на этой штуке игровой движок накатать, все будет совсем плохо? Как оно по сравнению с С++ по производительности
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	142. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:15
	Со сборщиком мусора придётся побороться. Но эта проблема всех больших проектов на подобных языках. Сборщик начинает захлёбываться без подсказок.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	144. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:18
	Пули будут в полёте приостанавливаться на время сборки мусора :)
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	153. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним Аналитег on 17-Фев-17, 18:36
	Думаю игровых движков должно быть мало как раз из-за gc, который может создавать неожиданные паузы. Тут то лучше пусть и не быстрый real time чем неожиданный возникший stop the world. В жабе такие вещи решаются тюнингом работы gc как например в Revenge of the titans, количество используемых ключей и параметров к jvm для запуска меня удивило.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

95. "Релиз языка программирования Go 1.8"	–3 +/–
Сообщение от Аноним (??) on 17-Фев-17, 16:31
func g() // ! {        // НЕВЕРНО } if x { }      // ! else { // НЕВЕРНО } func g(){ // ВЕРНО } if x { } else { // ВЕРНО } После этого язык GO для меня не сущесвует
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	99. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:06
	func g()// НЕВЕРНО {       } >>После этого язык GO для меня не сущесвует Платят за количество строк? Я знаю эти удаки на С/С++ еще и возвращаемый тип переносят на отдельную строку: int main() { //овнокод. } выглядит инфернально.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	136. "Релиз языка программирования Go 1.8"	–3 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:05
	> Платят за количество строк? Нет, просто такой код легче читать. > Я знаю эти удаки на С/С++ еще и возвращаемый тип переносят на отдельную строку Представьте себе, иногда не лишено смысла. Но вы можете продолжать писать код в одну строку, если хотите. Любой язык, который навязывает стиль оформления, ущербный по определению. // другой Аноним
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	186. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Аноним (??) on 18-Фев-17, 04:38
	int main() Это оправдано, потому что в отличие от хелловордов, в реальном коде это выглядит как-то так: static inline struct node * node_create(const char *key, const char *value, int flags, size_t size) {   ...; }
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	220. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 22:16
	Да-да, ты прав: https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/crtstuff.c?view... 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 Кругом дураки, а ты самый-самый. Иди возьми пирожок.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	100. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Вы забыли заполнить поле Name on 17-Фев-17, 17:12
	он еще не компилируется с несиспользуемыми переменными
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	148. "Релиз языка программирования Go 1.8"	–3 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:24
	При том, что это явно замедляет разработку, а они борются за каждую секунду разработчика
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	187. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 18-Фев-17, 04:39
	Просто баранье упёрство, хотя там напрашивается warning, а не error
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	196. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от angra (ok) on 18-Фев-17, 15:36
	Ты просто не понимаешь, что экономить на до не на спичках(уменьшение времени на набор текста), а на водке(уменьшение времени затрачиваемого на отладку).
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	103. "Релиз языка программирования Go 1.8"	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-17, 17:18
	Форматирование переносом строк для чайников, том 2. func g () { // верно } func g ( ) if x { / * а т л и ч н а * / }
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	107. "Релиз языка программирования Go 1.8"	+4 +/–
	Сообщение от Andrey Mitrofanov on 17-Фев-17, 17:32
	> После этого язык GO для меня не сущесвует Вздох облегчения из гугля дважды обогнул шарик.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	146. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 17-Фев-17, 18:21
	Я предпочитаю так: >if x { >... >} >else { >... >} А с функциями зависит от количества аргументов. Например часто так получается: >// ---------------------------- >func g(TYPE arg1, >       TYPE arg2, >      TYPE arg3, >      ....) >{ >... >} Но у маленьких функцию пишу так: >// ---------------------------- >func g() { >... >} Т.к. функции отделены комментарием, не принципиально где будет открывающая фигурная скобка, всё равно всё видно сразу. Но в Go работает только последний вариант.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	188. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 04:41
	>func g(TYPE arg1, >       TYPE arg2, >      TYPE arg3, >      ....) Если тебе такое понадобилось, с высокой вероятностью эту функцию стоит переделать: слишком длинный список аргументов, неиспользование typedef или слишком длинные имена параметров.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	206. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним (??) on 18-Фев-17, 20:16
	Или не тратить время и оставить всё как есть
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	197. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от angra (ok) on 18-Фев-17, 15:43
	> После этого язык GO для меня не сущесвует Одной из основных целей при разработке go и его дальнейшем развитии была и остается скорость сборки. Успех в этой области складывается в том числе и из таких вот мелочей. Но у таких ограничений есть и бонус - не надо ставить ';' в конце строк. Чтобы тебя окончательно добить, сообщу страшную вещь, на go принято пропускать код через форматировщик. В результате у всех код в одном визуальном стиле. Так что для самовыражения в форматировании действительно лучше выбрать другой ЯП.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	207. "Релиз языка программирования Go 1.8"	–2 +/–
	Сообщение от Аноним (??) on 18-Фев-17, 20:19
	> Так что для самовыражения в форматировании действительно лучше выбрать другой ЯП. На мой взгляд предложенное форматирование в Go - самовыражение его разработчиков. В моём круге общения такой стиль считается неправильным и не приемлем.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	224. "Релиз языка программирования Go 1.8"	–1 +/–
	Сообщение от Андрей (??) on 19-Фев-17, 15:59
	Неправильный стиль? Синтаксически корректный стиль оформления кода не бывает неправильным! Неприемлемый - пожалуйста. На вкус и цвет, как говорится. А какой из общепринятых K&R, GNU, original Berkeley, Linux,.. приемлем? Или тот, что в js с jquery?
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	232. "Релиз языка программирования Go 1.8"	+/–
	Сообщение от Аноним Аналитег on 20-Фев-17, 21:15
	>> В результате у всех код в одном визуальном стиле. > В моём круге общения такой стиль считается неправильным и не приемлем Мой опыт говорит, что в каждом монастыре свой code convention. Причем каждый кейс обоснуют. Многие ide позволяют подробно задать параметры форматтера. Слышали про collective code ownership?
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

226. "Релиз языка программирования Go 1.8"	–1 +/–
Сообщение от Анонишвили on 20-Фев-17, 11:45
lol no generics
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема