1.2, Crazy Alex (ok), 11:55, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не понял - что такого в том, чтобы в двух goroutine обращаться к одному map? Они ж кооперативные, никаких проблем с локами быть не должно?
| |
|
2.4, Sergey (??), 12:23, 18/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
map-ы в Go не thread-safe. Читать можно конечно и без всяких lock-ов, но не писать. Удобно поэтому для конкурентного доступа к map использовать sync.RWMutex.
| |
|
|
4.51, skybon (ok), 23:37, 18/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Явное лучше неявного.
Словить панику на месте приятнее чем чесать репу разбирая странности потом.
| |
|
5.54, Кирилл (??), 01:58, 19/02/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
С вашей логикой тогда надо крэшить для всех типов одновременный доступ, например, для int. Одновременная запись в string не вызывает паники, и как бэ "явное неявное" почему-то всех устраивает. Race - все же на совести программиста. Зачем паниковать, тоже не понимаю.
Тем более есть прекрасный sync в стандартной либе.
| |
|
6.69, Никто (??), 15:16, 19/02/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> С вашей логикой тогда надо крэшить для всех типов одновременный доступ, например,
> для int.
Было бы неплохо, но сложно реализовать не уничтожив скорость работы и не раздув код
| |
|
|
|
|
|
1.3, Аноним (-), 12:00, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Абзац про гоу-няшное костылестроение с горутином в мужском роде — это пять. Сегодня так ещё не смеялся.
| |
1.6, Никто (??), 12:28, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
>с такими достоинствами скриптовых языков, как ... защищённость от ошибок.
Вы поделили на ноль. Скриптовые языки предоставляют защищённости от ошибок, если только не имеется ввиду, что программа как-нибудь да будет работать даже при наличии кучи ошибок, легко отлавливаемых в статически строго типизированных компилируемых языках.
| |
|
2.7, Никто (??), 12:29, 18/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
>Скриптовые языки НЕ предоставляют защищённости от ошибок
Исправлено
| |
2.14, Kodesu (ok), 13:18, 18/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> легко отлавливаемых
У низкоуровневых языков есть свои траблы.
Программы с миллиардами (!) пользователей, написанные на C страдают от таких проблем, как переполнение буфера и выход за границу массива. (Пруфы? Открой список CVE за последние пару лет)
И что-то не сильно легко эти баги отлавливаются.
| |
|
3.17, Аноним (-), 13:31, 18/02/2016 [^] [^^] [^^^] [ответить]
| +13 +/– |
Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем, как переполнение sql-injection и сравнение нуля с пустой строкой. (Пруфы? Открой новости за последние пару лет)
| |
|
|
5.35, Никто (??), 19:51, 18/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Как бы о защищённости от ошибок динамически типизированных языков.
| |
5.60, Чепукто (?), 06:08, 19/02/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Обоснуй!
PS: я не про то, что PHP или, упасихоспади, Basic в чем-то хороши. Но вот так PHP равнять с Бейсиком! Не настолько же он плох!!!
| |
|
4.56, Лютый жабист (?), 05:10, 19/02/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем, как переполнение sql-injection и сравнение нуля с пустой строкой
Дык программы на си и этим страдают и перечисленным предыдущим оратором.
То что на php или java можно сделать 'rm -rf /' не повод считать их плохими.
А вот то, что на си даже крутой программер не может обеспечить 100% отсутствие переполнений - это повод назвать сишечку какашечкой.
| |
|
5.61, Чепукто (?), 06:25, 19/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем,
> как переполнение sql-injection и сравнение нуля с пустой строкой
> Дык программы на си и этим страдают и перечисленным предыдущим оратором.
> То что на php или java можно сделать 'rm -rf /' не
> повод считать их плохими.
> А вот то, что на си даже крутой программер не может обеспечить
> 100% отсутствие переполнений - это повод назвать сишечку какашечкой.
Ща вот прям срыв покровов будет. ПХП написан на C (как, в общем-то, и Java, и даже само небо и сам Аллах). Поэтому:
1. Программы на ПХП имеют кучу проблем, обусловленных ПХП.
2. Программы на ПХП наследуют проблемы С, на котором написан ПХП.
3. Программисты на ПХП не могут поправить косяки программистов С, написавших ПХП, и живут как-то с этим.
| |
|
|
3.20, Мяут (ok), 14:52, 18/02/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Справедливости ради, такие ошибки можно и нужно вылавливать статическими анализаторами типа PVS-Studio (на чем они кстати и пиарятся). То, что это мало кто делает -- вопрос другой.
А вот для языков с динамической типизацией статический анализатор как-то трудно представить
| |
3.33, Никто (??), 19:35, 18/02/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ваше замечание в целом верно кроме того, что не имеет отношения к моему комментарию. Я не писал про низкоуровневые языки. Перечитайте, у меня написано:
>статически строго типизированных компилируемых языках
На всякий случай уточню - это не про Си, ему не хватает строгости.
Переполнение буфера и выход за границу массива - это по большей части проблемы динамического характера и они недостаточно эффективно отлавливаются на этапе статического анализа. То есть, это вообще не о том. Выход за границу массива и в динамически типизированном языке будет выходом за границу массива. Будет ли оно проходить незаметно или будет сопровождаться крахом - это не свойство вида типизации.
| |
|
4.40, Kodesu (ok), 20:46, 18/02/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> это не свойство вида типизации.
Согласен. Мой комментарий был не к месту.
| |
4.50, angra (ok), 23:36, 18/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
При выходе за границу массива или иной структуры в скриптовых языках не произойдет чтения или перезаписи других данных. С этой точки зрения они защищают(но не предотвращают) от данного класса ошибок.
| |
|
5.65, Никто (??), 13:43, 19/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
>При выходе за границу массива или иной структуры в скриптовых языках не произойдет чтения
>или перезаписи других данных
Это не свойство динамически типизированных языков.
| |
|
|
|
|
1.8, Никто (??), 12:38, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
>Код на языке Go компилируется в обособленные бинарные исполняемые файлы,
>выполняемые нативно без использования виртуальной машины (...), что позволяет
>добиться производительности, сопоставимой с программами на языке Си
Сопоставимая с Си производительность достигается на том же уровне, что и в Java с обособленной виртуальной машиной и не всегда в пользу Go. А при использовании AOT подходы становяться ещё более похожими.
| |
|
2.23, freehck (ok), 15:51, 18/02/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
Хм. Мой опыт использования aptly показал, что это инструмент весьма шустрый.
Раз Вы взялись утверждаеть, что у Go такие же проблемы с производительностью, как и у Java - пожалуйста, подтвердите пруфами.
| |
|
|
4.29, Аноним32 (?), 17:57, 18/02/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
java вообще летает, особенно в связке с 100500 мб оперативы и N ядерным процом с тактовой частотой 100500 ГГц.
| |
|
5.57, Лютый жабист (?), 05:15, 19/02/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
> java вообще летает, особенно в связке с 100500 мб оперативы и N
> ядерным процом с тактовой частотой 100500 ГГц.
Именно так, анонимушка. На большие задачи, которые в любом случае потребуют толстого железа, на си умаешься писать масштабируемый, назовем его обработчик. Или в сишном мире уже появился аналог JavaEE?
| |
|
|
|
8.73, _ (??), 17:24, 19/02/2016 [^] [^^] [^^^] [ответить] | +1 +/– | Внезапно - на С же и написанна Но жабофилам этого не понять, мозжечок не вмещ... текст свёрнут, показать | |
|
|
|
|
|
|
4.46, freehck (ok), 22:11, 18/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Прошу простить мне неграмотность, однако не подскажете ли Вы мне также, что я должен знать, чтобы понимать эти графики? Я нигде не нашёл описания подобного рода графиков, хотя совершенно точно видел их уже не раз. Я боюсь, что читаю их не правильно.
1) Что значит жирная линия посередине столбца? Это среднее значение всех программ, участвовавших в тесте?
2) Что означает белый столбец, внутри которого содержится линия? Это разброс всех замеренных результатов?
3) Что означают чёрные палочки под и над столбцом? Это погрешности измерений?
| |
|
5.66, Никто (??), 13:53, 19/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Это графики для визуализации статистических данных. Можете почитать про боксплоты в "Наглядная статистика. Используем R" биолога Шипунова. Если лень - просто ориентируйтесь на жирную горизонтальную линиию - медиану.
| |
|
4.47, freehck (ok), 22:41, 18/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Окей, значит я пока понял это дело так. Go процентов на 30% шустрее Java, но оба они примерно в 2 раза медленнее C.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
Результат, в принципе, интересный. Меня также удивляет, что OCaml оказался позади Java и Scala, хотя на данный момент, как утверждают некоторые товарищи из Inria, он обладает самым быстрым GC, пускай и однопоточным: при столь малых размерах получаемых бинарей программы на Ocaml могут позволить себе форки, и забить на треды.
Ещё такой момент: я не понимаю, каким образом у Java/Scala получаются такие хорошие результаты. Это AOT тому причиной? Я вот чего не знаю наверняка:
1) Jar-ники с jvm-байткодом можно полностью перегнать в нативный код для ускорения программы после старта?
2) В jvm есть gc, но ходят слухи, что работает он так "хорошо", что сжирает вообще все русурсы CPU, и потому его отключают. Вам известно, как дела обстоят на самом деле?
По поводу радости разработчиков Go улучшению производительности gc, думаю, тут всё весьма очевидно. Заставить хорошо работать многопоточный gc - та ещё головная боль, ocaml-исты с этой задачей уже собаку съели, но до сих пор не сделали. Если у Go он работает, причём быстро - так это большая победа.
| |
|
5.48, freehck (ok), 23:05, 18/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> 1) Jar-ники с jvm-байткодом можно полностью перегнать в нативный код для ускорения программы после старта?
Так с этим вроде стало яснее. Был AOT-compiler GCJ из набора, который похоже загнулся, ибо последние обновления датированы 2009-м. Сейчас осталось проприетарное поделие Excelsior JET, которое, впрочем, уже поддерживает восьмёрку.
Я так понял, что они перегоняют набор jar-ников в бинарь. А в самих jar-никах содержится исключительно jvm-байткод. Всегда.
Попровьте меня, если где-то ошибся.
| |
5.58, Лютый жабист (?), 05:26, 19/02/2016 [^] [^^] [^^^] [ответить]
| –4 +/– |
> Окей, значит я пока понял это дело так. Go процентов на 30%
> шустрее Java, но оба они примерно в 2 раза медленнее C.
Ты неправ. Во первых задачи бывают разные, я сталкивался с реальными задачами, на которых java быстрее си.
Во вторых, при большой сложности проекта java/c получается деление на ноль, т.к. на си надо бесконечное количество программистов с бесконечно крутыми познаниями на бесконечное время.
Ну, а так, в теории да, "сферическовакуумная сишечка быстрее в 2 раза".
| |
5.59, Лютый жабист (?), 05:31, 19/02/2016 [^] [^^] [^^^] [ответить]
| –5 +/– |
> 2) В jvm есть gc, но ходят слухи, что работает он так
> "хорошо", что сжирает вообще все русурсы CPU, и потому его отключают.
> Вам известно, как дела обстоят на самом деле?
Странно иметь какие-то мнение по вопросу вообще не будучи в теме. Сборщик мусора в java-программах часто вообще не запускается.
На очень жирных программах, в духе - системная интеграционная шина огромной организации, которая имеет потребление порядка 20ГБ ОЗУ и лютое количество enterprise java bean-ов ("потоков") может например срабатывать раз в 6-10 часов и тормозить программу на пару-тройку секунд. И что? Кто лучше-то может?
| |
5.67, Никто (??), 15:05, 19/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
>2) В jvm есть gc, но ходят слухи, что работает он так "хорошо", что сжирает вообще все
>русурсы CPU, и потому его отключают
GC в Oracle JVM работает куда лучше для модели Java чем GC в Go, но разработчики инструментария для Go не стоят на месте.
Потенциально Go предоставляет возможность для большей эффективности при работе с памятью поскольку в отличии от Java позволяет размещать переменные структурного типа статически. На практике это может никак не проявиться, потому что это сложнее, особенно для бывшего Джависта, который тянет в Go патерны из Java. С другой стороны, JVM в ряде случаев способна провести оптимизацию и разместить динамические с точки зрения языка данные статически. Это не говоря уже о AOT, который позволяет провести более глубокую оптимизацию за счёт меньших ограничений на время компиляции. С другой стороны JIT позволяет получить профиль использования программы и делать оптимизацию более предметно.
Вообще, в современном мире невменяемо сложных техник компиляторов и процессоров очень сложно разобраться что быстрее чего(обратите внимание, что результаты тестирования довольно существенно отличаются для разных процессоров).
| |
|
|
|
|
|
2.10, anonymous (??), 12:47, 18/02/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
Потому как язык изначально для толковых студней создавалася, поэтому, с кучей стандартных либ в Go проще стартануть.
Я, конечно, за минимальньное ядро языка (aka runtime) - работа со строками, числами, базовый I/O (сокеты, файлы) - должно быть достаточно.
| |
2.36, Crazy Alex (ok), 20:11, 18/02/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Потому что это означает, что оно всё будет развиваться в гармсонии с остальными частями языка, и будет какой-то понятный мейнстрим с понятным статусом, а не десяток "стандартов де-факто", тянущих каждый в свою сторону.
"Batteries included" - это сейчас вообще необходимость для любого нового языка.
| |
|
3.45, anonymous (??), 21:44, 18/02/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Пользователь IDE? :)
ЯП = синтаксис, и либы тут немного сбоку. Хороший пример - C/C++ к-ми можно пользоваться без стандартных либ.
| |
|
4.49, angra (ok), 23:23, 18/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Начни с ввода/вывода в консоль без стандартных либ в С/С++.
| |
|
5.52, anonymous (??), 00:10, 19/02/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ну посмотри как в линукс ядре, например, выводят на консоль. Без стандартных либ.
| |
|
6.63, . (?), 08:11, 19/02/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
Дооо - ты напиши корректный printf сначала чмо малолетнее :) Там и зубры тока так зубы ломают :-F
| |
6.76, Андрей (??), 05:14, 20/02/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Так в ядре же есть своя libc: klibc. И вот куча функций:
usr/klibc/printf.c
usr/klibc/vfprintf.c
usr/klibc/vsnprintf.c
usr/klibc/stdio/fwrite.c
usr/klibc/SYSCALLS.def
Происходит следующее:
--> printf()
--> vfprintf(stdout,... )
--> vsnprintf()
--> _fwrite(..., stdout)
--> fwrite_noflush()
--> write() (SYSCALL)
| |
|
|
|
|
2.37, Никто (??), 20:12, 18/02/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
Этих модулей нет в языке, они в стандартной библиотеке. Чем это хорошо при должном уровне разработки библиотек - понятно, чем плохо - не понятно.
| |
|
1.12, Аноним (-), 13:09, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> что позволяет добиться производительности, сопоставимой с программами на языке Си.
а затем:
> Сокращено число пауз, вызванных работой сборщика мусора, что особенно заметно в программах, расходующих большие объемы памяти;
Ну и его сраный рантайм, пихаемый прямо в код бинаря, никак не добавляет производительности, сравнимой с Си
| |
|
2.42, Никто (??), 21:14, 18/02/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Скорость только возрастает, если рантайм встраивается в исполняемый файл. Рантайм есть и у Си, но обычно идёт в виде динамической библиотеки при возможности статической компоновки. Для Go выбрали обратный подход - по умолчанию идёт статическая компоновка, но возможна и динамическая.
| |
|
1.18, Аноним (-), 13:35, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Изменён алгоритм сортировки, используемый в sort.Sort, что также позволило поднять производительность примерно на 10%
судя по коммиту, увеличили минимальный размер массива для сортировки вставками, но добавили сортировку Шелла.
Интересно, почему там не используется timsort, как в большинстве современных библиотек. (видимо потому что появился после 1990-го года. Все эти Коксы с Пайками - они такие)
| |
|
2.77, Андрей (??), 05:32, 20/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Интересно, почему там не используется timsort, как в большинстве современных библиотек
В большинстве??? Согласно википедии: питон, а также джава, андроид и октав. Всё.
> (видимо потому что появился после 1990-го года. Все эти Коксы с
> Пайками - они такие)
Ну, Роб Пайк, может, и да. Но Рас Кокс - поколение помоложе.
| |
|
1.19, Аноним (19), 14:25, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Добавлены экспериментальные порты для Linux на 64-рядных процессорах MIPS (linux/mips64 и linux/mips64le) и Android on 32-разрядных процессорах x86 (android/386);
прошу гугл добавить arm/arm64 и powerpc/powerpc64 - очень хочется докеры
| |
1.28, Аноним (-), 17:16, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Cтарый алгоритм сортировки доступен через вызов sort.Stable
Дезинформация. sort.Stable был и до этого, а sort.Sort был отличен от него.
| |
1.30, Андрей (??), 18:15, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> В Cgo, механизм для организации вызова кода на C/C++ из программ на языке Go
А вот этот последний пункт - самая большая головная боль для кучи проектов. Даже если ты передавал opaque указатель, теперь - нельзя! Указатели нужно хранить в map, и передавать можно только "указатели" на эти указатели.
| |
|
|
3.74, Андрей (??), 04:56, 20/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
Вообще, я - за Go! Но, признаю, что это решение выглядит неуклюже. Причина: сборщик мусора. Чтобы ему было удобней, решили пожертвовать удобством для cgo.
| |
|
|
|
2.43, Никто (??), 21:26, 18/02/2016 [^] [^^] [^^^] [ответить]
| +6 +/– |
Здравствуй, школьник. В привычном понимании этого слова никакие браузеры не поддерживают этот язык. Тем не менее и как это ни смешно, "привет, мир" можно попробовать прямо из браузера сразу на главной странице официального сайта https://golang.org/
| |
|
1.41, 321 (??), 21:11, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
версии слишком быстро плодятся. версия gccgo - не поспевает.
| |
|
2.70, Andrey Mitrofanov (?), 15:51, 19/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Что за версия языка еще? Это, типа, стандарт Go99 или Go14?
Чего https://golang.org/ref/spec (см.внизу: "Build version go1.6."!) непонятого-то? Спецификация - часть билда компилёра, компилёр - референсная (и единственная, надо полагать?) реализация, включённой в него спецификации, и т.д., и т.д -- чтобы понять рекурсию, надо понять: Ленин - Партия, Партия - Ленин.
| |
|
3.71, Аноним (-), 16:57, 19/02/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Версия компилятора все-таки? Вот есть GCC 5.3.1, поддерживающий C++11. 5.3.1 - версия GCC, а C++11 это версия стандарта языка С++. Сабж то какую версию Go поддерживает? И как у языка может быть версия?
| |
|
4.72, Andrey Mitrofanov (?), 17:21, 19/02/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Версия компилятора все-таки?
Многие жалуются, что я непонятно пишу, поэтому для тех, кто не понял: я написал "версия и того(компилятора=реализации), и другого(языка=спецификации)".
> C++11 это версия стандарта языка С++
>И как у языка может быть версия?
Это Вы так сам с собой разговариваете? Извините, если помешал.
Мне так казалось, что [как бы очевидно, что] язык=спецификация, версия языка=версия "стандарта".
| |
|
|
|
1.80, IvAnZ (?), 08:32, 22/02/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кто-нибудь Caddy производительность смотрел против nginx?
Я смотрю там reverse-proxy failover check из коробки, чего у nginx нет (есть в Plus версии или надо Lua прикручивать)
https://caddyserver.com/docs/proxy
Думаю есть ли смысл только как Load-Balancer Caddy поставить перед nginx?
| |
|