The OpenNET Project / Index page

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



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

Оглавление

Релиз языка программирования Go 1.17, opennews (??), 17-Авг-21, (0) [смотреть все]

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


6. "Релиз языка программирования Go 1.17"  –11 +/
Сообщение от Аноним (6), 17-Авг-21, 09:20 
Го включает уборку мусора где надо и не надо, порой высоконагруженное приложение проще написать на питоне, чем бороться с уборкой мусора и его нагрузкой на го. Раньше думал, что го это идеал, но теперь как-то он мне не очень.
Ответить | Правка | Наверх | Cообщить модератору

8. "Релиз языка программирования Go 1.17"  +4 +/
Сообщение от Аноним (5), 17-Авг-21, 09:26 
Вызывай уборку мусора руками. Делов-то.
Ответить | Правка | Наверх | Cообщить модератору

9. "Релиз языка программирования Go 1.17"  +4 +/
Сообщение от go (?), 17-Авг-21, 09:26 
Ты всегда можешь сделать это эффективнее сам. Все инструменты для этого есть.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

12. "Релиз языка программирования Go 1.17"  –4 +/
Сообщение от Аноним (12), 17-Авг-21, 09:31 
Да, опыт того же Дискорда подсказывает, что Го достаточно далёк от идеала
Но большинству далеко до Дискорда по нагрузке, а значит и Питона хватит
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

17. "Релиз языка программирования Go 1.17"  +6 +/
Сообщение от Мимокрокодил (?), 17-Авг-21, 09:43 
Это была откровенно тупая статья от чувака из дискорда. Ему там же в каментах насовали, что он чушь написал.   Так что опыт показывает, что люди нихера не читают, а слышат звон 😄
Ответить | Правка | Наверх | Cообщить модератору

144. "Релиз языка программирования Go 1.17"  +/
Сообщение от Аноним (144), 17-Авг-21, 18:56 
К тому же дискорд принадлежит microsoft, а этим ребятам нет веры. И надежды. И любви.
Ответить | Правка | Наверх | Cообщить модератору

181. "Релиз языка программирования Go 1.17"  +/
Сообщение от ghost (??), 18-Авг-21, 09:13 
> дискорд принадлежит microsoft

Откуда дровишки?

Ответить | Правка | Наверх | Cообщить модератору

127. "Релиз языка программирования Go 1.17"  +2 +/
Сообщение от John (??), 17-Авг-21, 16:59 
Статья дискорда устарела до ее выхода.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

16. "Релиз языка программирования Go 1.17"  +11 +/
Сообщение от Брат Анон (ok), 17-Авг-21, 09:40 
> Го включает уборку мусора где надо и не надо, порой высоконагруженное приложение
> проще написать на питоне, чем бороться с уборкой мусора и его
> нагрузкой на го. Раньше думал, что го это идеал, но теперь
> как-то он мне не очень.

Шта?)))
Ты мне не рассказывай. Даже когда Го не умел все ядра пользовать -- я не поленился и написал тест для сравнения Го 1.13 и питон 3.4 -- Го порвал питон на искусственном тесте в 40 раз (Компонентный Паскаль примерно в 35...38 раз. ФриПаскаль рвал питон в 40-50 раз, Си порвал питон в 60 раз, Visual Basic 6.5 порвал питон наравне с Си в 60 раз, чем старичок меня ОЧЕНЬ СИЛЬНО удивил, даже питон 2.7 сделал питон 3.4 примерно в 1.7 раза, PascalABC.Net уже умел многоядерность и порвал питон уже тогда примерно в 180..200 раз.). Теперь Го имеет многие оптимизации и многоядерность. На моей домашней машине Го 1.16 рвёт питон 3.8 (у которого теперь есть асинхронность) примерно в 200 раз по скорости и примерно 5 раз по потреблению памяти.

Ты так написал про СМ в Го, что можно подумать, что его в питоне нет. Ах да: задержки на стоп-ворлд в Го давно исчисляются временем по 10..15 мксек. В питоне -- 1...1.5 мсек. Это я тоже проверял лично, чтобы ты знал великий ыксперд.

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

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

29. "Релиз языка программирования Go 1.17"  –8 +/
Сообщение от uchiya (ok), 17-Авг-21, 10:16 
Си порвал в 60 раз, а Го в 200 раз. Держите его пацаны, сейчас расскажет, как го порвал ассемблер в  10 раз.
Ответить | Правка | Наверх | Cообщить модератору

35. "Релиз языка программирования Go 1.17"  –5 +/
Сообщение от Рева RarogCmex Денисemail (?), 17-Авг-21, 10:59 
Чувак просто не умеет в алгоритмы :)
Ответить | Правка | Наверх | Cообщить модератору

45. "Релиз языка программирования Go 1.17"  +3 +/
Сообщение от Аноним (45), 17-Авг-21, 11:30 
>Си порвал в 60 раз, а Го в 200 раз. Держите его пацаны, сейчас расскажет, как го порвал ассемблер в  10 раз.

во-первых, Го порвал в 40 раз, а во-ворых, С не делает программы быстыми магическим образм.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

65. "Релиз языка программирования Go 1.17"  –7 +/
Сообщение от хацкер (??), 17-Авг-21, 12:16 
> На моей домашней машине Го 1.16 рвёт питон 3.8 (у которого теперь есть асинхронность) примерно в 200 раз

вчитываться научись о потом спорь

Ответить | Правка | Наверх | Cообщить модератору

71. "Релиз языка программирования Go 1.17"  +4 +/
Сообщение от Аноним (45), 17-Авг-21, 12:24 
>вчитываться научись о потом спорь

Вот именно, научись.

В тесте, где учавствовали и Го и С тестировался питон 3.4.
А в тесте, где Го уделал питон в 200 раз, был уже 3.8.

Так что не надо тут мешать попугаев.

Ответить | Правка | Наверх | Cообщить модератору

107. "Релиз языка программирования Go 1.17"  +6 +/
Сообщение от Аноним (107), 17-Авг-21, 16:08 
Не только. В дополнение:
- в тесте, где учавствовали и Го и С, го быстрее в 40 раз, Си в 60. Си быстрее, как хочет этот хейтер. И Го "без многоядерности". Т.е. этот тест у си и го скорее всего одноядерный/однопоточный.

- в тесте, где Го уделал питон в 200 раз, про Си ничего не говорится, сишного теста не было, а Го к этому моменту "имеет оптимизации и многоядерность", что "какбе намекает", что там уже не одноядерность/однопоточность.

Ответить | Правка | Наверх | Cообщить модератору

124. "Релиз языка программирования Go 1.17"  +5 +/
Сообщение от Брат Анон (ok), 17-Авг-21, 16:52 
> - в тесте, где Го уделал питон в 200 раз, про Си
> ничего не говорится, сишного теста не было, а Го к этому
> моменту __"имеет оптимизации и многоядерность"__, что "какбе намекает", что там уже
> не одноядерность/однопоточность.

Неужели кто-то умеет читать?))

Ответить | Правка | Наверх | Cообщить модератору

49. "Релиз языка программирования Go 1.17"  –6 +/
Сообщение от Аноним (209), 17-Авг-21, 11:36 
> Си порвал в 60 раз, а Го в 200 раз. Держите его пацаны, сейчас расскажет...

Из написанного им похоже, что Сишное запускал он на одном ядре, а Гошное на всех доступных ядрах.
OpenMP он не осилил.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

55. "Релиз языка программирования Go 1.17"  +5 +/
Сообщение от Глеб Кузьминemail (?), 17-Авг-21, 11:49 
А нах**?
Человеку нравится го, он пишет на го, сравнивает многопоточку на го с многопоточкой на питоне. При чем тут Си?
Вы ещё скажите, что он плохой, потому что не включил в сравнение ассемблер и аду.
Ответить | Правка | Наверх | Cообщить модератору

69. "Релиз языка программирования Go 1.17"  –1 +/
Сообщение от OnTheEdge (ok), 17-Авг-21, 12:20 
> При чем тут Си?

а вы у этого человека и спросите к чему он всё это приплел

Ответить | Правка | Наверх | Cообщить модератору

130. "Релиз языка программирования Go 1.17"  +2 +/
Сообщение от Брат Анон (ok), 17-Авг-21, 17:25 
>> При чем тут Си?
> а вы у этого человека и спросите к чему он всё это приплел

Для чего написал? Т.е. то, что я даже процитировал то, зачем написал -- вы даже это не прочитали?

Ответить | Правка | Наверх | Cообщить модератору

198. "Релиз языка программирования Go 1.17"  +1 +/
Сообщение от Аноним (198), 18-Авг-21, 16:03 
> сравнивает многопоточку на го с многопоточкой на питоне

А чего их сравнивать? И так всё понятно. GIL же.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

126. "Релиз языка программирования Go 1.17"  +3 +/
Сообщение от Брат Анон (ok), 17-Авг-21, 16:54 
> Из написанного им похоже, что Сишное запускал он на одном ядре, а
> Гошное на всех доступных ядрах.
> OpenMP он не осилил.

Вроде по русски написал, что Го 1.13 в этой версии не умел многоядерность. OpenMP в Го? Ты немного неадекватный, брат анон. И текст про PascalABC.Net (в котором таки как раз есть OpenMP) ты тоже пропустил (судя по твоему комменту).

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

206. "Релиз языка программирования Go 1.17"  –4 +/
Сообщение от Аноним (209), 18-Авг-21, 19:15 
> Вроде по русски написал...

А как был ты необразованным чучмеком, так и остался.

Ответить | Правка | Наверх | Cообщить модератору

94. "Релиз языка программирования Go 1.17"  +7 +/
Сообщение от Аноним (107), 17-Авг-21, 15:13 
Читайте внимательно. Акцент при чтении делайте на поддержку многоядерности и сами цифры.

Вроде очевидно, что начало списка (превосходство в 40-50-60 раз) - это

> когда Го не умел все ядра пользовать

И сравнивая цифры можно сделать вывод, что тесты на других языках тоже на одном ядре/в однопоток выполнялись).

А потом уже
> PascalABC.Net уже умел многоядерность и порвал питон уже тогда примерно в 180..200 раз ...
> Теперь Го имеет многие оптимизации и многоядерность... рвёт питон 3.8 (у которого теперь есть асинхронность) примерно в 200 раз по скорости...

Вы где-то увидели упоминание про многоядерную/многопоточную вторую версию теста на Си?

Согласен, слегка сумбурно изложено, без деталей и уточнений, но понятно же, чего придираетесь?

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

175. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 18-Авг-21, 03:57 
> Го порвал питон на искусственном тесте в 40 раз (Компонентный Паскаль примерно в 35...38 раз. ФриПаскаль рвал питон в 40-50 раз, Си порвал питон в 60 раз

А я попробовал попарсить гигабайтный xml файлик с помощью Го и как-то подразочаровался. Свой парсер у него говённый, но даде с биндингами к либхмл он нещадно тормозит из за постоянного перераспределения памяти под строки.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

184. "Релиз языка программирования Go 1.17"  +/
Сообщение от Брат Анон (ok), 18-Авг-21, 10:10 
>> Го порвал питон на искусственном тесте в 40 раз (Компонентный Паскаль примерно в 35...38 раз. ФриПаскаль рвал питон в 40-50 раз, Си порвал питон в 60 раз
> А я попробовал попарсить гигабайтный xml файлик с помощью Го и как-то
> подразочаровался. Свой парсер у него говённый, но даде с биндингами к
> либхмл он нещадно тормозит из за постоянного перераспределения памяти под строки.

Наверное, потому что ты как-то не так готовил кошек? Прямо сразу из твоего сообщения я вижу, что как минимум, вместо того, чтобы использовать strings.Builder() ты использовал строки (которые в го -- неизменяемые сущности, поэтому таки да -- использовать строки налево и направо - -в го весьма дорого). Типичное решение в го в таких случаях -- использовать срез рун. А уж как ты там парсил и почему ты не посмотрел решения на github.com с кодогенерацией, которая даёт ускорение под конкретный XML в 5-10 раз -- вот тут мне понятно, что навыки программирования у тебя на уровне джуниора.


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

Ответить | Правка | Наверх | Cообщить модератору

187. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 18-Авг-21, 10:43 
Я на чтение пробовал, а не на запись. Мне нужен был SAX парсер - гигабайтный файл был маленьким семплом.  Нахера там стрингбилдер? Строки, полученные из ХМЛ - зачем их менять? Просто Го делает обычные энтерпрайзные вещи крайне медленно. Не так медленно как перл или, наверное, петон, но медленнее опасных языков в разы.
Ответить | Правка | Наверх | Cообщить модератору

188. "Релиз языка программирования Go 1.17"  +/
Сообщение от Брат Анон (ok), 18-Авг-21, 10:50 
> Я на чтение пробовал, а не на запись. Мне нужен был SAX
> парсер - гигабайтный файл был маленьким семплом.  Нахера там стрингбилдер?
> Строки, полученные из ХМЛ - зачем их менять? Просто Го делает
> обычные энтерпрайзные вещи крайне медленно. Не так медленно как перл или,
> наверное, петон, но медленнее опасных языков в разы.

Даже если ты просто читаешь -- ты выделяешь память. Если ты просто заполняешь поля структур строками -- ты выделяешь память. Так вот, если бы ты использовал срезы рун -- ты бы память выделял -- ровно один раз. А strings.Builder() -- довольно не дурно сам понимает -- сколько ему памяти удерживать, а сколько отдать назад сборщику мусора (т.е. нет лишнего выделения памяти). Кроме того, эта штука умеет очень быстро почти без накладных расходов преобразовывать свой буфер в байты/руны/строки. Так что, инструмент надо не только уметь держать, но ещё и пользоваться им. Так что ты бы попробовал кодогенерацию. Безопасно, достаточно быстро для безопасного парсинга, ещё и код писать не надо руками -- только описать структуры в шаблоне.

Ответить | Правка | Наверх | Cообщить модератору

191. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 18-Авг-21, 11:13 
Ты не понимаешь как работает SAX - библиотека дергает твои колбеки и передаёт им полученные значения. Всё. Сам ты там ничего не выделяешь. И к библиотекам нет вопросов, я попробовал их все, что были на тот момент за исключением родной гошной укуренной. На Го быстрее просто невозможно - копируешь строку как минимум один раз, что из го-кода, что при передаче из опасной libxml. Там и тормозить-то больше нечему.
Ответить | Правка | Наверх | Cообщить модератору

192. "Релиз языка программирования Go 1.17"  +/
Сообщение от Брат Анон (ok), 18-Авг-21, 12:00 
> Ты не понимаешь как работает SAX - библиотека дергает твои колбеки и
> передаёт им полученные значения. Всё. Сам ты там ничего не выделяешь.

Я прекрасно понимаю, как работает эта либа. Она дёргает колбеки. А это значит, что вся конкурентность го идёт псу под хвост. Если у тебя даже 128 ядер будет -- фактически работать у тебя за счёт сишной либы всегда будет только одно ядро.

> И к библиотекам нет вопросов, я попробовал их все, что были
> на тот момент за исключением родной гошной укуренной. На Го быстрее
> просто невозможно - копируешь строку как минимум один раз, что из
> го-кода, что при передаче из опасной libxml.

Таким образом ты ещё и убиваешь инварианты памяти. Кодогенерация, ещё раз -- волшебное слово.
На го можно достаточно быстро, чтобы сравнивать с чистым си (не на порядок будет отставание, а в типовом случае в 2х..4х раза -- это плата за безопасность, но стоит она дороже, чем 2х...4х).
Родная гошная библиотека просто даёт возможность что-то сделать. Фактически, существует по 3-5 реализаций каждой гошной библиотеки с оптимизациями 5х..20х раз. Что JSON, что XML, что HTTP.

> Там и тормозить-то больше
> нечему.

А так-то да. Всё что мог затормозить -- ты успешно затормозил))


Ответить | Правка | Наверх | Cообщить модератору

195. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 18-Авг-21, 15:04 
> Я прекрасно понимаю, как работает эта либа. Она дёргает колбеки. А это
> значит, что вся конкурентность го идёт псу под хвост. Если у
> тебя даже 128 ядер будет -- фактически работать у тебя за
> счёт сишной либы всегда будет только одно ядро.

Зачем там 128 ядер!? Эта задача вообще в IO должна упираться, а не в ЦПУ :-D


> Таким образом ты ещё и убиваешь инварианты памяти. Кодогенерация, ещё раз --
> волшебное слово.

Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не сможет.

> А так-то да. Всё что мог затормозить -- ты успешно затормозил))

Ну разве что тебя, да и то не хотел, прости ;-D

Ответить | Правка | Наверх | Cообщить модератору

213. "Релиз языка программирования Go 1.17"  +/
Сообщение от Брат Анон (ok), 18-Авг-21, 23:34 
> Зачем там 128 ядер!? Эта задача вообще в IO должна упираться, а
> не в ЦПУ :-D

Задачу парсинга XML вполне можно параллелить.

> Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не
> сможет.

Зато параллельно парсить сможет.

Ответить | Правка | Наверх | Cообщить модератору

215. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 19-Авг-21, 01:42 
> Задачу парсинга XML вполне можно параллелить.

Задачу парсинга параллелить не нужно. IO тормознее всех остальных операций.Параллелить лучше то, что происходит уже после парсинга. Собственно с этой целью я на Го и смотрел. Но горутины когда начинешь их обмазывать каналами и прочей мутотой начинают захламлять код не хуже многопоточных реализаций на каких-нибудь опасных языках. И ещё куча всяких мелочей делающих бессмыссленным переход на Го. Но тормоза при работе с данными - это первая причина. БОльшая часть того, с чем работает энтерарайз - это не какие-то космические вычисления, это просто парсинг потоков данных вагинирующих от одного сервиса к другому с какми-то элементарными операциями над ними. А Го в это не может. И тут ещё такой момент - теоретический предел  производительности при парсинге XML, безразлично каким количеством потоков, это биндинг опасной libxml2. Есть поделки и намсамом Го со сравнимой производительностью, но они сильно срезают углы ради этого: ничего не знают про кодировки, например. И меня бы это устроило в том конкретном случае потому, что данный тип файлов у меня в ASCII и го вообще хоть регэкспами чеши. Но кто гарантирует что так будет всегда? А случись пояаиться кодировкам в даанных и эти поделки придется заменять на те, что будут перекодировать данные внося очередной раунд аллокации-копирования-удаления строк. Нет никакого смысла закладываться на такой ущербный инструмент. Тем более, что если мы пишем приложение на опасном языке, и наши данные не требуют особой магии, то появляется возможность маневра в сторону реализаций вообще без аллокации памяти: просто отображаем фай в память и используем строки прямо из этой памяти - такие парсеры прямо в мапе разбрасывают нули в конце строк и передают адрес строки пользователю. Быстро, дёшево и сердито. Но в Го такое випринципе невозможно.  

>> Ты можешь укодогененироваться в труху, вот только XML оно быстрее читать не
>> сможет.
> Зато параллельно парсить сможет.

И что нам это даёт? Неконкурентоспособное решение, которому нужно несколько ядер там, где и одного-то за глаза?


Ответить | Правка | Наверх | Cообщить модератору

207. "Релиз языка программирования Go 1.17"  –2 +/
Сообщение от Аноним (209), 18-Авг-21, 20:59 
> Ты не понимаешь как работает SAX - библиотека дергает твои колбеки...

Этот чел вообще мало что понимает. Полный п-ц, на самом деле.

Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

216. "Релиз языка программирования Go 1.17"  +/
Сообщение от edo (ok), 19-Авг-21, 01:46 
> По третьей ссылке (на Хабре) ты бы мог узнать, что биндинги в Го -- это не Го-вей, так как прыжки туда-обратно стоят очень дорого. Кроме того, посмотри новость рядом -- неуправляемая память в Си кладёт целые процессы. Таким образом, используя Си в Го -- ты просто убиваешь всю идею Го на корню. Как по инвариантам памяти, так и по быстродействию.

Постоянно вижу сишный sqlite в программах на go

Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

219. "Релиз языка программирования Go 1.17"  +1 +/
Сообщение от x3who (?), 19-Авг-21, 02:50 
>> По третьей ссылке (на Хабре) ты бы мог узнать, что биндинги в Го -- это не Го-вей, так как прыжки туда-обратно стоят очень дорого. Кроме того, посмотри новость рядом -- неуправляемая память в Си кладёт целые процессы. Таким образом, используя Си в Го -- ты просто убиваешь всю идею Го на корню. Как по инвариантам памяти, так и по быстродействию.
> Постоянно вижу сишный sqlite в программах на go

Я вообще не понимяу какая там разница. Ну вот допустим кто-то перепишет sqlite на Го.Что изменится? на каком-то этапе Го всё равно придётся взаимодействовать с опасным внешним миром, написанном на сях. Только это будут сырыа данные из файла, не отфильтрованные опасной библиотекой sqlite, т.е. копирований опасного контента в безопасный будет только больше, производительность будет хуже.. Так чем же это лучше??

Ответить | Правка | Наверх | Cообщить модератору

212. "Релиз языка программирования Go 1.17"  +/
Сообщение от anonymous (??), 18-Авг-21, 23:18 
А не могли бы вы поделиться кодом и sample-ом (который парсите)? Может быть я могу помочь вам с оптимизацией :)
Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

217. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 19-Авг-21, 02:10 
> А не могли бы вы поделиться кодом и sample-ом (который парсите)? Может
> быть я могу помочь вам с оптимизацией :)

Нет. Ни тем ни другим. Там в тесте банально было - никакой осмысленной логики: парсер нашел тег, создаём соответствующего типа объект (просто заглушки со списком детей, на такой случай дженериков тоже языку не хватает кстати), говорим паренту, что у него родился сын - и всё. По возвращении на верхний уровень, скидываем объект верхнего уровня в канал на обработку и всё начинается сначала. Иерархии там не очень большие, каждый такой тег верхнего уровня килобайт примерно сто наверное, хотя бывают всплески и до пары сотен МБ. Но это не важно с т.з. парсинга - что что миллионов раз по сто тысяч байт байт переварить, что сто тыщ раз по сто миллионов байт - без разницы просто.

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

Я не хочу показаться хейтером Го. Есть куча ПО, написанного на Го, которое наглядно демонстрирует преимущества этого средства на петоном и прочей "безоппасной" лабудой. Приложения, написанные на Го как правило значительно шустрее и надежнее написанных на этих странных ЯП. Я просто не понимаю зачем на н1м писать :)

Ответить | Правка | Наверх | Cообщить модератору

225. "Релиз языка программирования Go 1.17"  +1 +/
Сообщение от anonymous (??), 19-Авг-21, 11:15 
Вы код и sample дайте. Я просто уже давненько применяю Go в high performance, и частенько вижу жалобы (вроде вашей), но в >95% люди просто не правильно использовали Go для своей задачи. И каждый раз твёрдо верят, что такого не может быть.
Ответить | Правка | Наверх | Cообщить модератору

233. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 19-Авг-21, 19:50 
Увы, не выйдет. Это было более полутора лет назад - я уже повыкидывал и Го и хелловорлды свои, да и синтаксис самого Го успел забыть.
Ответить | Правка | Наверх | Cообщить модератору

244. "Релиз языка программирования Go 1.17"  +/
Сообщение от anonymous (??), 20-Авг-21, 09:55 
Ну что тогда сказать? В общем, на самом деле Go нормально подходит для почти любой высокопроизводительной задачи (хотя это нередко приводит к заменителям стандартных package-ей). Реальная проблема там с safety, а не performance. И вызвана она, например, отсутствием immutable переменных (там нет ДАЖЕ аналога Сишного const) и вообще невыразительной системой типов.
Ответить | Правка | Наверх | Cообщить модератору

245. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 20-Авг-21, 11:23 
Так я об этом и говорю, что по всей видимости потери идут при переходе данных из опасного внешнего мира в безопасные потроха гошной программы, на парсинге ХМЛ это очень заметно, потому что очень много строк приходит. Константных, одинаковых. Не знаю, возможно что-то с этим можно что-то сделать на уровне биндинга к libxml2 - например не конвертировать строку, содержащую имя тега каждый раз как его надо отдавать в Го-программу, а держать таблицу гошных строк и на них ссылаться если такая строка уже есть.
Ответить | Правка | Наверх | Cообщить модератору

20. "Релиз языка программирования Go 1.17"  +8 +/
Сообщение от Нанобот (ok), 17-Авг-21, 09:58 
>высоконагруженное приложение проще написать на питоне

ага. просто "высоконагруженное приложение на питоне" потребует от 64гб памяти и 32+ ядра, плюс его нужно будет раз в пару часов перезапускать. но ты прав, написать проще

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

38. "Релиз языка программирования Go 1.17"  –4 +/
Сообщение от Урри (ok), 17-Авг-21, 11:13 
для пруф-оф-консепта сойдет, а потом можно нанять нормальных программистов и переписать на с.
Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз языка программирования Go 1.17"  +2 +/
Сообщение от Аноним (70), 17-Авг-21, 11:34 
Если хочется ещё больше багов понаделать - можно и на си. Кто там у нас пишет распределённые системы на сях? Ух ты, никто, здравый смысл видимо ещё есть.
Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз языка программирования Go 1.17"  –2 +/
Сообщение от Пппппп (?), 17-Авг-21, 11:39 
Очень много пишут рапределёных систем на Си до который недоязычкам никогда не дотянуть. Пример Oracle.
Ответить | Правка | Наверх | Cообщить модератору

52. "Релиз языка программирования Go 1.17"  +1 +/
Сообщение от Аноним (70), 17-Авг-21, 11:41 
Класс, целый один пример. И то без пруфов. Ясно, понятно :)
Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз языка программирования Go 1.17"  +/
Сообщение от Аноним (66), 17-Авг-21, 12:16 
Tarantool, PostgreSQL
Ответить | Правка | Наверх | Cообщить модератору

96. "Релиз языка программирования Go 1.17"  –2 +/
Сообщение от Аноним (107), 17-Авг-21, 15:32 
> Очень много пишут рапределёных систем на Си до который недоязычкам никогда не дотянуть. Пример Oracle.

Ха! Уморили! Худшего примера привести не могли. Я средненький ораклоид-быдлокодер, с этого только и живу, эту БД уважаю, но почитайте из первых рук про тот ад в разработке этого проекта. От бывшего разработчика, поучаствовавшего в разработке Oracle Database 12.2:

https://news.ycombinator.com/item?id=18442941

"Oracle Database 12.2.

It is close to 25 million lines of C code.

What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.
...
The only reason why this product is still surviving and still works is due to literally millions of tests!
...
The fact that this product even works is nothing short of a miracle!

I don't work for Oracle anymore. Will never work for Oracle again!
"

Вольный перевод
https://habr.com/ru/post/429946/

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

125. "Релиз языка программирования Go 1.17"  –3 +/
Сообщение от Пппппп (?), 17-Авг-21, 16:52 
Посмейся ещё. С версии не позже чем с 11 Oracle делают почти одни индусы. Когда делали белые американцы всё было отлично. Я Oracle Юзал когда он ещё был версии 9.x.

Нужно отделять проблему быдлокодинга индусов и возможности Си. Если кривые руки индусов исправить нельзя то Сишный код можно дробить на модули, так делают все. Если всё свалить в один большой проект то в нём будет трудно ориентироваться.

Ответить | Правка | Наверх | Cообщить модератору

218. "Релиз языка программирования Go 1.17"  +/
Сообщение от x3who (?), 19-Авг-21, 02:12 
> Посмейся ещё. С версии не позже чем с 11 Oracle делают почти
> одни индусы. Когда делали белые американцы всё было отлично. Я Oracle
> Юзал когда он ещё был версии 9.x.
> Нужно отделять проблему быдлокодинга индусов и возможности Си. Если кривые руки индусов
> исправить нельзя то Сишный код можно дробить на модули, так делают
> все. Если всё свалить в один большой проект то в нём
> будет трудно ориентироваться.

Возвращаясь к топику - если Оракл переписать на Го, то что-нибудь улучшится?

Ответить | Правка | Наверх | Cообщить модератору

247. "Релиз языка программирования Go 1.17"  +/
Сообщение от Аноним (107), 20-Авг-21, 13:25 
> Посмейся ещё

Спасибо, посмеялся. Прям оборжался. По ссылкам, видимо, не сходил?

Там про проблемы еще с Oracle8i и даже с 1980-90-х тянутся.

Самое с чего оборжался, это

> Когда делали белые американцы всё было отлично. Я Oracle Юзал когда он ещё был версии 9.x.

Вы работали в Оракле над их БД и видели исходники "до индусов" и после? Я юзал Оракл с 8i и юзаю поныне. И? Факт того, что я юзаю, как-то круто улучшило оракловский код?
И еще - ты думаешь, пришли индусы и всё там переписали с нуля в лапшу, не оставив старого кода? Тот ад, что описали разрабочики, в большей степени связаны со старым кодом и невозможностью рефакторинга. И индусы и белые американцы просто уже не могут его отрефакторить.

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

104. "Релиз языка программирования Go 1.17"  –3 +/
Сообщение от n00by (ok), 17-Авг-21, 16:03 
> Если хочется ещё больше багов понаделать - можно и на си. Кто
> там у нас пишет распределённые системы на сях?

Интернет -- это достаточно распределённая система? Из чего она состоит?

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

160. "Релиз языка программирования Go 1.17"  +/
Сообщение от funny.falcon (?), 17-Авг-21, 22:50 
> для пруф-оф-консепта сойдет, а потом можно

Ни кого не нанимать, и силами тех же питонщегов переписать на Go.

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

41. "Релиз языка программирования Go 1.17"  –1 +/
Сообщение от Вася (??), 17-Авг-21, 11:26 
Это правда на половину. Память там не "течет" бесконечно, она отжирается до определенного объёма в свой аллокатор. Потом перестает отжираться когда внутри ее достаточно.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

98. "Релиз языка программирования Go 1.17"  +2 +/
Сообщение от Аноним (97), 17-Авг-21, 15:41 
На практике надо очень сильно постараться, чтобы GC pause стала критичной. При этом в языке с ручным управлением памятью в аллокатор упереться можно даже раньше.

То есть проблема, конечно, существует, но большинство типичных для go I/O-bound проектов просто никогда в нее не упрутся.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

170. "Релиз языка программирования Go 1.17"  +10 +/
Сообщение от Led (ok), 18-Авг-21, 00:21 
> надо очень сильно постараться, чтобы GC pause стала критичной.

Ну, разработчики жабы, похоже, таки очень сильно постарались.

Ответить | Правка | Наверх | Cообщить модератору

211. "Релиз языка программирования Go 1.17"  +1 +/
Сообщение от Аноним (211), 18-Авг-21, 23:00 
В java и golang очень разные GC.
Ответить | Правка | Наверх | Cообщить модератору

173. "Релиз языка программирования Go 1.17"  +/
Сообщение от Аноним (171), 18-Авг-21, 00:40 
Го "включает сборку мусора" там, где происходит передача переменной по ссылке за пределы контекста создания переменной.
Передавай небольшие структуры по значению, не кидайся лишний раз данными за пределы скоупа, а когда таки нужно постоянно передавать много экземпляров одной структуры, юзай sync.Pool, чтобы снизить объем работы для gc.
Ну и pprof в помощь.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

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

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




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

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