forum.opennet.ru - "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала модулей Go" (147)

"Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала модулей Go"

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

"Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала модулей Go"	+/–
Сообщение от opennews (??), 02-Фев-23, 11:04
Представлен релиз языка программирования Go 1.20, который развивается компанией Google при участии сообщества как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58586
Ответить \| Правка \| Cообщить модератору

Оглавление

посмотрим, возможно, на фоне увольнений гугол это последний релиз, Аноним (1), 11:04 , 02-Фев-23, (1) –1

Скрыто модератором, анон (?), 11:31 , 02-Фев-23, (19) –2

Скрыто модератором, Аноним (24), 11:44 , 02-Фев-23, (24) –1

Скрыто модератором, анон (?), 11:48 , 02-Фев-23, (28) +2

Скрыто модератором, Аноним (1), 11:56 , 02-Фев-23, (35) +2

Скрыто модератором, Аноним (31), 11:49 , 02-Фев-23, (31) +1

Скрыто модератором, НяшМяш (ok), 12:00 , 02-Фев-23, (38) +1

Скрыто модератором, Аноним (1), 12:02 , 02-Фев-23, (41) +4
Скрыто модератором, Аноним (1), 12:03 , 02-Фев-23, (43) +1
Скрыто модератором, Аноним (31), 12:09 , 02-Фев-23, (48) +2

Скрыто модератором, Старший аноним (?), 12:37 , 02-Фев-23, (77)

А там всю команду уволили, или только массовиков-затейников с развитыми мягоньки, RomanCh (ok), 12:18 , 02-Фев-23, (68) +5
Руководство Гугла - не эксцентричный Маск, дойную корову никто выгонять не будет, Аноним (124), 18:39 , 02-Фев-23, (124) +1

Скрыто модератором, Аноним (24), 11:07 , 02-Фев-23, (3) –1

Скрыто модератором, НяшМяш (ok), 12:02 , 02-Фев-23, (40) –6

Скрыто модератором, Аноним (1), 12:04 , 02-Фев-23, (44) +1
Скрыто модератором, Вечно недовольный аноним (?), 12:26 , 02-Фев-23, (72)
Скрыто модератором, Аноним (24), 12:40 , 02-Фев-23, (80) +2

Скрыто модератором, Аноним (82), 12:58 , 02-Фев-23, (82) +3

Скрыто модератором, Placeholder (ok), 12:18 , 02-Фев-23, (67) +1

Для микроконтроллера можно скомпилировать , Аноним (5), 11:12 , 02-Фев-23, (5)

tinygo, анон (?), 11:25 , 02-Фев-23, (12) +5
Даже для Lego конструктора можно , RomanCh (ok), 12:19 , 02-Фев-23, (69) +1

чочо, ryoken (ok), 13:14 , 02-Фев-23, (84) +1

https github com ev3go ev3dev, RomanCh (ok), 14:26 , 02-Фев-23, (98) +3
Скрыто модератором, Аноним (-), 13:38 , 04-Фев-23, (183)

Скрыто модератором, Аноним (18), 11:30 , 02-Фев-23, (18)

Скрыто модератором, Аноним (1), 11:38 , 02-Фев-23, (23) –4

Скрыто модератором, Аноним (24), 11:45 , 02-Фев-23, (25) –2

Скрыто модератором, Аноним (31), 11:50 , 02-Фев-23, (32) –1

Скрыто модератором, 1 (??), 11:56 , 02-Фев-23, (36) –1

Скрыто модератором, Аноним (31), 12:10 , 02-Фев-23, (50)

Скрыто модератором, анон (?), 12:12 , 02-Фев-23, (55)

Скрыто модератором, Аноним (31), 12:14 , 02-Фев-23, (58)

Скрыто модератором, Аноним (24), 12:16 , 02-Фев-23, (63)
Скрыто модератором, анон (?), 12:16 , 02-Фев-23, (64) +1

Скрыто модератором, 4op (?), 11:45 , 02-Фев-23, (26) +4

Скрыто модератором, Аноним (24), 12:13 , 02-Фев-23, (56) –1

Го отличный язык при разумном применении Раст отличный язык при разумном примене, Аноним (37), 11:58 , 02-Фев-23, (37) +9

X_PROGRAMMING_LANGUAGE отличный язык при разумном применении , Аноним (1), 12:01 , 02-Фев-23, (39) +8

brainfack отличный язык при разумном применении yoptascript отличный язык при р, Аноним (74), 12:31 , 02-Фев-23, (74) +1

Английский отличный язык при разумном применении , anonist (?), 20:09 , 02-Фев-23, (136) +2

Это исключение, Аноним (156), 08:19 , 03-Фев-23, (156) –1

Русский отличный язык при разумном применении, RarogCmex (ok), 19:19 , 04-Фев-23, (193) +1

Разумное применение -- отличная штука, при наличии , Аноним (192), 19:11 , 04-Фев-23, (192)

Именно поэтому на го гораздо больше софта, чем на расте, Аноним (207), 22:53 , 06-Фев-23, (207)

Го с растом сравнивать как-то бредово Они для разного Но вместе они заменят пл, Аноним (51), 12:10 , 02-Фев-23, (51) –7

Никто не заменит плюсы, раст - это новый паскаль, Аноним (31), 12:12 , 02-Фев-23, (54) +1
Перепиши Qt, OpenCV и многое многое другое, заменятель близорукий , ihatenpm (?), 14:04 , 02-Фев-23, (92) +4

У вас в работе много задач, которые требуют всего функционала QT , Прохожий (??), 14:37 , 02-Фев-23, (102) –4

Разговор на этом можно заканчивать, ihatenpm (?), 17:53 , 02-Фев-23, (116) +4

А на чём, кстати, написан QT что плюсовые привязки есть -- понимаю , Michael Shigorin (ok), 00:32 , 03-Фев-23, (143) –2

QuickTime был написан на C и Objective C , Perlovka (ok), 04:54 , 03-Фев-23, (151) +5

ЧятГПТ скоро перепишет Уверен через год-два появятся инструменты транспайлинга , Анонус (?), 17:36 , 02-Фев-23, (115)

Посмотрим, пока плохо получается , ihatenpm (?), 17:55 , 02-Фев-23, (117) +1
И прикол кстати в том, что может быть наоборот он будет полезен в переводе с мак, ihatenpm (?), 17:57 , 02-Фев-23, (118)

Например, пишешь на модном расте, потом транспайлишь в классический си с сохране, Аноним (153), 07:28 , 03-Фев-23, (153)

Никто, конечно, не будет переписывать проекты которым по 20 и более лет Раст выб, Советский инженер (?), 10:04 , 03-Фев-23, (165) +2

Конечно, заменят Всё в твоих руках , Аноним (106), 15:38 , 02-Фев-23, (106)
Не могу себе представить системное програмиирование на языке, hello world которо, Аноним (207), 22:54 , 06-Фев-23, (208)

Срезы, это массивы динамического размера, т е это достаточно низкоуровневая а, RomanCh (ok), 12:17 , 02-Фев-23, (65) +2

Во-первых, не запятая, а тире Во-вторых, размер ни разу не 171 динамический , pashev.ru (?), 18:29 , 02-Фев-23, (123) +1

Ну, с таким знанием предмета, вам только и остаётся, что до пунктуации докапыват, RomanCh (ok), 18:55 , 02-Фев-23, (128) –1

Теперь с гошистами всё окончательно понятно , pashev.ru (?), 19:41 , 02-Фев-23, (131) –2

Поясню изменение полей структуры это не изменение размера структуры И да, барда, pashev.ru (?), 19:56 , 02-Фев-23, (133) –1

Ну, с таким знанием предмета, вам только и остаётся, что до пунктуации докапы, QrKot (?), 19:42 , 03-Фев-23, (170)

Ошибаетесь, append не всегда будет выделять новый слайс А если и будет, то зар, Аноним (207), 22:56 , 06-Фев-23, (209)

Фиксированный размер и статически фиксированный размер -- это разные вещи Т, Аноним (-), 18:50 , 02-Фев-23, (127) +3

И откуда вас таких выпустили См соседний камент и вот это, специально для ва, RomanCh (ok), 18:58 , 02-Фев-23, (129) –2

Из вуза, после того, как мы честно свой диплом отработали Откуда ты такой вылез , Аноним (-), 19:35 , 02-Фев-23, (130) –3

Ну то есть, будучи пойманным на глупости, остаётся только перевести разговор на , RomanCh (ok), 19:49 , 02-Фев-23, (132) –1

Мэн, вам вдвоем с оппонентом надо таки в доку внимательно заглянуть Слайс таки И, QrKot (?), 19:58 , 03-Фев-23, (171)

Аа, ну вот и объявился человек, который весь в белом пальто красивый, а все оста, RomanCh (ok), 22:19 , 03-Фев-23, (174) –1

Ну, ссылаться на GoTour - мощный аргумент, конечно Особенно учитывая, что A sl, cheshirekot (ok), 08:42 , 04-Фев-23, (178)

Нда Либо вы не умете считать до двух, т к смотреть надо было ВТОРУЮ ссылку, , RomanCh (ok), 11:42 , 04-Фев-23, (181) –1

Отлично Из вашей фразы Да, переприсваиванием исходной переменной, в которой ук, cheshirekot (ok), 13:42 , 04-Фев-23, (184)
Окей, короче, давайте просто сравним две абстракции плюсовый std vector динам, cheshirekot (ok), 13:57 , 04-Фев-23, (185)

Бегло прочитав данный пост, я вижу, что вы по прежнему пытаетесь использовать ко, RomanCh (ok), 14:44 , 04-Фев-23, (188)

Окей, перейдем к официальной терминологии языка Ну, как бэ, вот Это ваша форм, cheshirekot (ok), 15:38 , 04-Фев-23, (189)
Рад, что вы открыли для себя страницы спецификации Нет, в спеке написано то, что, RomanCh (ok), 17:58 , 04-Фев-23, (190)
Да, действительно, неудобно очень читать до второго предложения и не видеть трет, cheshirekot (ok), 20:21 , 04-Фев-23, (194)
Отлично, я вас научил читать документацию Правда, похоже это без толку, потому , RomanCh (ok), 21:09 , 04-Фев-23, (196)
Кроме срезы - это массивы динамического размера , что, по прежнему, неправда,, QrKot (?), 22:01 , 04-Фев-23, (197)
Не, это было бы грустно Динамическим называется массив, размер которого может, cheshirekot (ok), 22:56 , 04-Фев-23, (199)
Забавно, комментарий с нейросетью удалили Так вот, у нас с вами сугубо термино, RomanCh (ok), 10:58 , 05-Фев-23, (202)
Разрешите воспользоваться вашей же аналогией с автомобилем Вот есть автомобиль -, cheshirekot (ok), 19:41 , 06-Фев-23, (206)
На что, простите намекает В effective Go слово object встречается 10 раз Наприм, cheshirekot (ok), 22:37 , 04-Фев-23, (198)

Попробуй, ну, я даже не знаю, ковырнуть исходник и посмотреть что такое слайс и , Аноним (205), 09:10 , 06-Фев-23, (205)

Функциональность - новая мода, с которой все носятся как дурни с писанной торбой, Neon (??), 21:50 , 02-Фев-23, (138)
Не обязательно, и это страшноappend может изменить исходный слайс, т к у слайсов, morphe (?), 22:08 , 02-Фев-23, (140) +3

В отличии от языков с нормальным дизайном, разработчики golang решили сделать чт, morphe (?), 22:15 , 02-Фев-23, (141) +4

А что предполагалось увидеть на выхлопе Если заменить а int 0 на предсказуе, OpenEcho (?), 03:21 , 03-Фев-23, (145) –1

Человек написал что append в golang функциональный, и исходный буфер не трогаетЕ, morphe (?), 03:34 , 03-Фев-23, (146)

Сорри, не понял, согласен, с append-om нужно быть осторожным, точнее просто знат, OpenEcho (?), 04:32 , 03-Фев-23, (150)
если места нет - то создаёт новый слайс, в котором в 2 раза больше местаПрости, QrKot (?), 21:20 , 03-Фев-23, (173)

А как на счёт посмотреть исходник, и не писать результаты своих гаданий Ведь за, RomanCh (ok), 22:36 , 03-Фев-23, (175)

А, ну да, в 2 раза, my bad При размере слайса до 256 элементов А дальше таки, cheshirekot (ok), 11:12 , 04-Фев-23, (180)

Вот нет бы тут остановиться, и было бы красиво Ну бывает, люди совершают ошибки, RomanCh (ok), 11:56 , 04-Фев-23, (182)
Дык, а давайте прямо комментарии в коде и почитаем Строка 126 growslice allo, cheshirekot (ok), 14:27 , 04-Фев-23, (187)
В старом изменяется длина, но остаётся прежним capacity Т е слайс таки имеет ди, morphe (?), 18:27 , 04-Фев-23, (191)
Ну вот нет же s0 make int, 10, 10 fmt Printf len d 124 cap d n ,, cheshirekot (ok), 20:47 , 04-Фев-23, (195)

Я пример кода скинул, который демонстрирует этоНули на позициях 2,4,8,16,32, име, morphe (?), 06:49 , 04-Фев-23, (177)

Просто в качестве занудства это только до 256 элементов в массиве Дальше прира, qrKot (?), 10:57 , 07-Фев-23, (211)

У меня на Go код работает так, как я от него ожидаю, что я делаю не так Ах, да,, RomanCh (ok), 22:42 , 03-Фев-23, (176)

При чем тут, простите, функциональное АПИ Слайс к функциональщине не имеет ника, QrKot (?), 20:04 , 03-Фев-23, (172)

https bluxte net musings 2018 04 10 go-good-bad-ugly slice-gotchasВ go слайсы, Аноним (204), 00:46 , 06-Фев-23, (204)

В Go слайсы - это дескриптор непрерывного сегмента нижележащего массива, предос, qrKot (?), 10:10 , 07-Фев-23, (210)

Скрыто модератором, Аноним (75), 12:33 , 02-Фев-23, (75) –1

Скрыто модератором, Аноним (24), 12:41 , 02-Фев-23, (81) +2
Скрыто модератором, leap42 (ok), 13:22 , 02-Фев-23, (85) +1

Скрыто модератором, Michael Shigorin (ok), 00:34 , 03-Фев-23, (144)

В блоге есть, в статье пропущено Начиная с версии Go 1 21 не будет больше работ, Старший аноним (?), 13:10 , 02-Фев-23, (83) +6

тех кто пишет на Go под Win7 уж точно не жалко xD, leap42 (ok), 13:26 , 02-Фев-23, (86) –2

Конечно, это же не Windows 10 c телеметрией ис каропки А чо - стальна, модна,, Старший аноним (?), 13:38 , 02-Фев-23, (87) +2

Телеметрия или 0-day эксплоиты для неподдерживаемой ос, что же выбрать старшему , анон (?), 13:49 , 02-Фев-23, (88)

Скрыто модератором, Аноним (-), 13:55 , 02-Фев-23, (89) +4
И кому нужна эксплутация зеродеев, если там одни неуловимые джо , ihatenpm (?), 14:07 , 02-Фев-23, (94)

Удобно так думать, с такой логикой можно вообще наплевать на безопасность А чо,, анон (?), 14:34 , 02-Фев-23, (101)

Так и писать тогда можно на любом языке безопасность же не нужна , Аноним (110), 15:57 , 02-Фев-23, (110) –1
Для вашей уязвимости достаточно жить в крупном городе и смартфона , ihatenpm (?), 18:00 , 02-Фев-23, (120) –1

От этого неуловимый джо только станет еще неуловимее , Neon (??), 21:51 , 02-Фев-23, (139)

Нет, не так Я уже 15 лет виндой не пользуюсь Но вместо 7-ки взял бы 10-ку из-з, leap42 (ok), 17:06 , 02-Фев-23, (114)

А ты не пробовал WSL пользоваться то взрослому, как на никсах , OpenEcho (?), 03:51 , 03-Фев-23, (148)

Нет, я же уже лет 15 виндой не пользуюсь Но я имел опыт с pussy exe и попытал б, leap42 (ok), 04:58 , 03-Фев-23, (152)

ой https github com golang go discussions 58409, Annonim (?), 19:32 , 14-Фев-23, (212)

Я на виртуалке запускаю, когда надо виндо-специфичное, т к она легковеснее, и в, ihatenpm (?), 14:08 , 02-Фев-23, (95)

10 легковесней раз в 100, попробуй тот билд для банкоматов там практически весь , Аноним (96), 14:16 , 02-Фев-23, (96) –1

Я и так без васяносборок не обхожусь IoT попробую , ihatenpm (?), 17:59 , 02-Фев-23, (119)

Я имею в виду не васяносборку Но МС её не продаёт в ритейле, она оемная Кмс-ак, Аноним (96), 18:15 , 02-Фев-23, (122)

Слабо рейтлимитер вкрутить , Аноним (97), 14:22 , 02-Фев-23, (97) –1

так и вкрутили, в новости об этом и написали, Аноним (100), 14:28 , 02-Фев-23, (100)

Так это держателям веб-сервиса надо было самим сделать А так получается, что по, www2 (??), 18:40 , 02-Фев-23, (125) –1

Т е надо сделать как в npm единую помойку, которую условно сложно положить , Аноним (24), 20:07 , 02-Фев-23, (135) +4
Кстати да, почему-то другие хостинги, включая живущие исключительно на поддержку, Аноним (100), 22:57 , 02-Фев-23, (142)

Так пусть напрямую выполняется, а если указано GO_PROXY импортируется через како, Аноним (126), 18:40 , 02-Фев-23, (126)

Давай по-порядку 1 Go простой 2 Go безопасно работает с памятью3 Go быстрее п, Аноним (24), 20:06 , 02-Фев-23, (134) +1

Может присутствие , Вы забыли заполнить поле Name (?), 21:49 , 02-Фев-23, (137) +6

Отсутствие необходимости иметь себе мозги гарбеджколлектором , Аноним (24), 11:12 , 03-Фев-23, (166)

Но ты им себе имеешь, когда привет энтерпрайз и хайлоад с конским RPS Как-нибуд, Аноним (169), 18:04 , 03-Фев-23, (169)

Я не разобрался, но я точно знаю proxy пакетов сделан для того, что бы не бы, OpenEcho (?), 04:11 , 03-Фев-23, (149) –1

Go хорош На нем можно писать классные программы вроде VictoriaMetrics, Аноним (154), 07:34 , 03-Фев-23, (154) +1
Самого вкусного в новости нет Теперь можно врапать несколько типов ошибок И , Аноним (155), 08:13 , 03-Фев-23, (155) +1
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствования, анонимит (?), 10:02 , 03-Фев-23, (164) –1
Go безопасный язык Угу если не пользоваться библиотеками обёртками над си кодом, Аноним (168), 16:56 , 03-Фев-23, (168) –1
Питоном, к счастью, в нём и не пахнет, зато авторы говорили, что заимстования , vadiml (ok), 10:18 , 04-Фев-23, (179) –1
достаточно бредовый язык делал сравнения для оценки производительности, так вот, anonbrain (?), 14:24 , 04-Фев-23, (186)

Делать энтерпрайзу нечего, как микросервисы на C пилить для задач, которые в I, Аноним (169), 15:28 , 05-Фев-23, (203)

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

1. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от Аноним (1), 02-Фев-23, 11:04

посмотрим, возможно, на фоне увольнений гугол это последний релиз

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

19. Скрыто модератором –2 +/–

Сообщение от анон (?), 02-Фев-23, 11:31

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

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

24. Скрыто модератором –1 +/–

Сообщение от Аноним (24), 02-Фев-23, 11:44

Так она и прекратилась. Там в каждой новой версии в лучшем случае багфиксы.

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

28. Скрыто модератором +2 +/–

Сообщение от анон (?), 02-Фев-23, 11:48

И святой дух релизы делает, а может даже ИИ.

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

35. Скрыто модератором +2 +/–

Сообщение от Аноним (1), 02-Фев-23, 11:56

святой дух безопасной работы с памятью

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

31. Скрыто модератором +1 +/–

Сообщение от Аноним (31), 02-Фев-23, 11:49

Это потому что раст - новый паскаль

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

38. Скрыто модератором +1 +/–

Сообщение от НяшМяш (ok), 02-Фев-23, 12:00

То есть идеальный?

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

41. Скрыто модератором +4 +/–

Сообщение от Аноним (1), 02-Фев-23, 12:02

Да, раст действительно хорош. Не зря же его включили в ядро линукс.

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

43. Скрыто модератором +1 +/–

Сообщение от Аноним (1), 02-Фев-23, 12:03

а го кстати нет

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

48. Скрыто модератором +2 +/–

Сообщение от Аноним (31), 02-Фев-23, 12:09

Старый паскаль лучше нового раста

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

77. Скрыто модератором +/–

Сообщение от Старший аноним (?), 02-Фев-23, 12:37

Лучшй Pascal - это ADA

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

68. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +5 +/–

Сообщение от RomanCh (ok), 02-Фев-23, 12:18

А там всю команду уволили, или только массовиков-затейников с развитыми мягонькими навыками и высоким "эмоциональным интеллектом"?

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

124. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от Аноним (124), 02-Фев-23, 18:39

Руководство Гугла - не эксцентричный Маск, дойную корову никто выгонять не будет. Внутри Гугла слишком много всего завязано на golang. Там люди прагматичные. В первую очередь под нож пойдут розовые пони, набранные ради diversity, экономическая польза от которых отрицательна.

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

3. Скрыто модератором –1 +/–

Сообщение от Аноним (24), 02-Фев-23, 11:07

Ни слова про безопасную работу с памятью. Хотя Go работает с памятью даже безопаснее чем раст.

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

40. Скрыто модератором –6 +/–

Сообщение от НяшМяш (ok), 02-Фев-23, 12:02

Язык с указателями безопасен? Всё что нужно знать про экспертизу на опеннете.

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

44. Скрыто модератором +1 +/–

Сообщение от Аноним (1), 02-Фев-23, 12:04

будто мы не знали)

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

72. Скрыто модератором +/–

Сообщение от Вечно недовольный аноним (?), 02-Фев-23, 12:26

А если это умные указатели?

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

80. Скрыто модератором +2 +/–

Сообщение от Аноним (24), 02-Фев-23, 12:40

И что в го можно делать арифметические операция или разыменованный указатель не null? По безопаснее чем в расте будет.

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

82. Скрыто модератором +3 +/–

Сообщение от Аноним (82), 02-Фев-23, 12:58

Любой язык с GC предлагает безопасную работу с памятью. А особенность раста в том, что он предлагает безопасную работу с памятью без GC.

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

67. Скрыто модератором +1 +/–

Сообщение от Placeholder (ok), 02-Фев-23, 12:18

Языки с gc не считаются, естественно.

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

5. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (5), 02-Фев-23, 11:12

Для микроконтроллера можно скомпилировать?

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

12. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +5 +/–

Сообщение от анон (?), 02-Фев-23, 11:25

tinygo

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

69. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от RomanCh (ok), 02-Фев-23, 12:19

> Для микроконтроллера можно скомпилировать?
Даже для Lego конструктора можно.

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

84. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от ryoken (ok), 02-Фев-23, 13:14

>>Даже для Lego конструктора можно.
чочо

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

98. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +3 +/–

Сообщение от RomanCh (ok), 02-Фев-23, 14:26

>>>Даже для Lego конструктора можно.
> чочо
https://github.com/ev3go/ev3dev

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

183. Скрыто модератором +/–

Сообщение от Аноним (-), 04-Фев-23, 13:38

> чочо
Там программируемые кирпичи есть.

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

18. Скрыто модератором +/–

Сообщение от Аноним (18), 02-Фев-23, 11:30

Кстати на Go переписано уже пол мира. На расте же до сих пор написано примерно ничего.

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

23. Скрыто модератором –4 +/–

Сообщение от Аноним (1), 02-Фев-23, 11:38

странный выбор, ведь раст лучше во всём

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

25. Скрыто модератором –2 +/–

Сообщение от Аноним (24), 02-Фев-23, 11:45

раст худший язык в любой сфере. Для сравнения питон второй лучший язык в любой сфере.

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

32. Скрыто модератором –1 +/–

Сообщение от Аноним (31), 02-Фев-23, 11:50

Но раст же новый паскаль

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

36. Скрыто модератором –1 +/–

Сообщение от 1 (??), 02-Фев-23, 11:56

там begin end нет и точки в конце.
Не катит на паскаль.

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

50. Скрыто модератором +/–

Сообщение от Аноним (31), 02-Фев-23, 12:10

Так раст это для тех кто бегинэнд не осилил

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

55. Скрыто модератором +/–

Сообщение от анон (?), 02-Фев-23, 12:12

Всю шкалу осиляторства пожалуйста в студию

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

58. Скрыто модератором +/–

Сообщение от Аноним (31), 02-Фев-23, 12:14

всю ты не осилишь, учи сначала раст, потом паскаль, потом приходи

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

63. Скрыто модератором +/–

Сообщение от Аноним (24), 02-Фев-23, 12:16

А как же модула-2?

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

64. Скрыто модератором +1 +/–

Сообщение от анон (?), 02-Фев-23, 12:16

То есть ты наивно думаешь что я ещё не знаю оба этих языка? Да уж, мельчает Аноним нынче.

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

26. Скрыто модератором +4 +/–

Сообщение от 4op (?), 02-Фев-23, 11:45

А можно почитать где то такую статистику про пол мира? Я без сарказма, реально интересно. Откуда такая информация?

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

56. Скрыто модератором –1 +/–

Сообщение от Аноним (24), 02-Фев-23, 12:13

На го написан докер. Этого более чем достаточно.

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

37. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +9 +/–

Сообщение от Аноним (37), 02-Фев-23, 11:58

Го отличный язык при разумном применении.
Раст отличный язык при разумном применении.

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

39. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +8 +/–

Сообщение от Аноним (1), 02-Фев-23, 12:01

X_PROGRAMMING_LANGUAGE отличный язык при разумном применении.

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

74. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от Аноним (74), 02-Фев-23, 12:31

brainfack отличный язык при разумном применении.
yoptascript отличный язык при разумном применении.
HQ9+ отличный язык при разумном применении.

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

136. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +2 +/–

Сообщение от anonist (?), 02-Фев-23, 20:09

Английский отличный язык при разумном применении.

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

156. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от Аноним (156), 03-Фев-23, 08:19

Это исключение

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

193. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от RarogCmex (ok), 04-Фев-23, 19:19

Русский отличный язык при разумном применении

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

192. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (192), 04-Фев-23, 19:11

Разумное применение -- отличная штука, при наличии.

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

207. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (207), 06-Фев-23, 22:53

Именно поэтому на го гораздо больше софта, чем на расте

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

51. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –7 +/–

Сообщение от Аноним (51), 02-Фев-23, 12:10

Го с растом сравнивать как-то бредово. Они для разного. Но вместе они заменят плюсы. Го в веб-бэкэнде, раст - в системном программировании.

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

54. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от Аноним (31), 02-Фев-23, 12:12

Никто не заменит плюсы, раст - это новый паскаль

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

92. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +4 +/–

Сообщение от ihatenpm (?), 02-Фев-23, 14:04

Перепиши Qt, OpenCV и многое многое другое, заменятель близорукий.

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

102. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –4 +/–

Сообщение от Прохожий (??), 02-Фев-23, 14:37

У вас в работе много задач, которые требуют всего функционала QT?

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

116. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +4 +/–

Сообщение от ihatenpm (?), 02-Фев-23, 17:53

> QT
Разговор на этом можно заканчивать

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

143. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –2 +/–

Сообщение от Michael Shigorin (ok), 03-Фев-23, 00:32

А на чём, кстати, написан QT? (что плюсовые привязки есть -- понимаю)

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

151. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +5 +/–

Сообщение от Perlovka (ok), 03-Фев-23, 04:54

QuickTime был написан на C и Objective C.

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

115. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Анонус (?), 02-Фев-23, 17:36

ЧятГПТ скоро перепишет. Уверен через год-два появятся инструменты транспайлинга с любого языка на любой.

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

117. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от ihatenpm (?), 02-Фев-23, 17:55

Посмотрим, пока плохо получается.

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

118. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от ihatenpm (?), 02-Фев-23, 17:57

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

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

153. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (153), 03-Фев-23, 07:28

Например, пишешь на модном расте, потом транспайлишь в классический си с сохранением гарантий безопастности. И все довольны.

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

165. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +2 +/–

Сообщение от Советский инженер (?), 03-Фев-23, 10:04

Никто, конечно, не будет переписывать проекты которым по 20 и более лет.
Раст выбрал другую стратегию: embrace, extend, and extinguish.
Раст закрепился в файрфоксе, пролез в ядро, его одобрили для использования в хроме. Он уже в месе и гстимере. И т.д и т.п.

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

106. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (106), 02-Фев-23, 15:38

Конечно, заменят. Всё в твоих руках :)

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

208. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (207), 06-Фев-23, 22:54

Не могу себе представить системное програмиирование на языке, hello world которого весит 10 Мб

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

65. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +2 +/–

Сообщение от RomanCh (ok), 02-Фев-23, 12:17

> В пакет unsafe добавлены функции SliceData, String и StringData для низкоуровневых манипуляций со срезами (массивы фиксированной длины)
Срезы, это "массивы" динамического размера, т.е. это достаточно низкоуровневая абстракция над массивами. А вот массивы в Go как раз имеют фиксированный размер.
Отправил правку в статью.

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

123. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от pashev.ru (?), 02-Фев-23, 18:29

> Срезы, это "массивы" динамического размера
Во-первых, не запятая, а тире. Во-вторых, размер ни разу не «динамический». Можно создавать несколько срезов разных размеров, но не срез «динамического» размера.
Отправил в биореактор.

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

128. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от RomanCh (ok), 02-Фев-23, 18:55

> Во-первых, не запятая, а тире. Во-вторых, размер ни разу не «динамический». Можно
> создавать несколько срезов разных размеров, но не срез «динамического» размера.
Ну, с таким знанием предмета, вам только и остаётся, что до пунктуации докапываться.
Просвещайтесь, вот тут для самых маленьких: https://go.dev/tour/moretypes/7
>  A slice, on the other hand, is a dynamically-sized, flexible view into the elements of an array.
А тут для тех, кто постарше: https://go.dev/src/runtime/slice.go
Замечу, что фраза "низкоуровневая абстракция" была написано выше не просто так.
PS Забавно, что ваш предыдущий бессмысленный комментарий удалили, но вы не сдаётесь и пытаетесь родить что-то более осмысленное. Комплексы?

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

131. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –2 +/–

Сообщение от pashev.ru (?), 02-Фев-23, 19:41

> Просвещайтесь, вот тут для самых маленьких: https://go.dev/tour/moretypes/7
>>  A slice, on the other hand, is a dynamically-sized, flexible view into the elements of an array.
Теперь с гошистами всё окончательно понятно.

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

133. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от pashev.ru (?), 02-Фев-23, 19:56

Поясню: изменение полей структуры это не изменение размера структуры.
И да, бардак в голове проявляется и в пунктуации.

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

170. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от QrKot (?), 03-Фев-23, 19:42

≥≥ Ну, с таким знанием предмета, вам только и остаётся, что до пунктуации докапываться.
Мэн, сорян, конечно, но в этот раз не он о бо ср ался, а ты(
≥≥  A slice, on the other hand, is a dynamically-sized, flexible view into the elements of an array.
И переводится это так: Слайс, с другой стороны - гибкое представление элементов массива динамической длины.
Короче, поясню: Слайс - обёртка над массивом. Он имеет длину, вместимость (капасити) и нижележащий массив. Капасити - константна, т.е. Слайс НЕ УМЕЕТ в ресайз. append при превышении капасити создаёт НОВЫЙ слайс, а не изменяет ресайзит текущий.

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

209. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (207), 06-Фев-23, 22:56

Ошибаетесь, append не всегда будет выделять новый слайс. А если и будет, то "зарезервирует запас"

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

127. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +3 +/–

Сообщение от Аноним (-), 02-Фев-23, 18:50

"Фиксированный размер" и "статически фиксированный размер" -- это разные вещи. Ты не можешь изменить размер слайса. Если в слайсе три элемента, ты не можешь добавить туда ещё один, чтобы их стало четыре.

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

129. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –2 +/–

Сообщение от RomanCh (ok), 02-Фев-23, 18:58

> Если в слайсе три элемента, ты не можешь добавить туда ещё один, чтобы их стало четыре.
И откуда вас таких выпустили?.. См. соседний камент и вот это, специально для вас: https://go.dev/tour/moretypes/15

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

130. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –3 +/–

Сообщение от Аноним (-), 02-Фев-23, 19:35

> И откуда вас таких выпустили?
Из вуза, после того, как мы честно свой диплом отработали.
Откуда ты такой вылез неясно.
Глянь на эту запись:
s = append(s, 2, 3, 4)
Ты видишь "функциональность" этого append'а? Он не меняет переданный ему слайс, он возвращает новый слайс, созданный на основе s и остальных аргументов.
Функциональное программирование, ты слышал про него? Есть разница между императивным API вида s.append(2, 3, 4), которое подразумевает изменение s, и функциональным, которое изменения не предполагает, которое вместо изменений существующих объектов создаёт новые объекты.

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

132. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от RomanCh (ok), 02-Фев-23, 19:49

> Ты видишь "функциональность" этого append'а? Он не меняет переданный ему слайс, он
> возвращает новый слайс, созданный на основе s и остальных аргументов.
Ну то есть, будучи пойманным на глупости, остаётся только перевести разговор на другую тему и заняться буквоедством. Слив засчитан.
Но раз уж вы предпочли буквоедство, то:
> которое вместо изменений существующих объектов создаёт новые объекты.
А в Go есть объекты? Не знал, не знал... Впрочем, создатели языка тоже не знают. Зато они знают, что в срезы можно добавлять объекты. Я вам даже ссылку привёл где прямым текстом про это сказано.
И я так и знал, что вы будете докапываться до того, как это пишется. Что уморительно, будто от того, что вместо s.append() делается s = append(s, ...) - чото-то меняется.
> после того, как мы честно свой диплом отработали.
Оно и видно. Наверное, на кассе отрабатывали.

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

171. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от QrKot (?), 03-Фев-23, 19:58

Мэн, вам вдвоем с оппонентом надо таки в доку внимательно заглянуть.
Слайс таки ИМЕЕТ статическую длину, о чем совершенно верно говорит он. Но его обоснование "это неправильный объект" - ересь, о чем совершенно верно говоришь ты.
Просто поясню: Слайс - обёртка над массивом. А массив имеет таки константную длину, его длина НЕ меняется.
Весь фокус в том, что у слайса есть 2 важных параметра: cap (капасити, вместимость) и len (длина). В целом Слайс - это мощный массив статической длины cap, в котором заняты len элементов. Т.е. у тебя статический массив из, допустим, 10 элементов, в который ты уже "зааппендил" 9 штук. При этом память у тебя выделена для 10 элементов. Когда ты говоришь append ещё одного массива, он просто пишется в 10 позицию. И все норм, он "как бы изменил размерность", хотя мы оба отлично понимаем, что ничего он не делал...
Но это все фигня, веселье начинается, когда ты ещё раз говоришь append. Это одиннадцатый элемент, а памяти - только на 10. Что происходит в этот момент?
В этот момент создаётся НОВЫЙ слайс с cap1 = cap0*1.5, где cap0 - капасити исходного слайса. Потом элементы исходного слайса копируются в новый, и вот это ты получаешь на выходе.
Именно и только поэтому это выглядит не как someSlice.append(newElement), а как someSlice = append(someSlice, newElement). А "объекты" тут не при чем, хотя они в Go таки есть. Классов нет, а объекты - есть. Просто Слайс таки статический, а ресайз "резолвится" в создание нового объекта.

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

174. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от RomanCh (ok), 03-Фев-23, 22:19

> Мэн, вам вдвоем с оппонентом надо таки в доку внимательно заглянуть.
Аа, ну вот и объявился человек, который весь в белом пальто красивый, а все остальные известно кто. Ну спасибо, разъяснил)
А ты не пробовал ну хотя бы вот этот пост прочитать и по второй ссылке в нём пройти перед тем, как включать менторский тон и пытаться объяснить азбуку? https://www.opennet.ru/openforum/vsluhforumID3/129670.html#128
Хотя, возможно ты просто решил похвататься, что сам знаешь азбуку? В этом случае ты преуспел.
Ещё, советую внимание обратить на то, что сейчас идёт спор о терминологии, а не о сути. И в терминологии Go срез это составной тип с изменяемым размером, добавление в который производится при помощи append. Да, переприсваиванием исходной переменной, в которой указатель на данные может измениться, а может и нет, изменится поле len, и возможно изменится поле cap.
> А "объекты" тут не при чем, хотя они в Go таки есть. Классов нет, а объекты - есть.
Пруфлинки на "объекты в Go" в студию! Уверен, что у такого грамотного специалиста не должно быть с этим проблем. Только пожалуйста, не от анонимных ыкспертов или с какого-нибудь стекворерфлоу, а от разработчиков языка.

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

178. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 08:42

>> А ты не пробовал ну хотя бы вот этот пост прочитать и по второй ссылке в нём пройти перед тем, как включать менторский тон и пытаться объяснить азбуку?
Ну, ссылаться на GoTour - мощный аргумент, конечно. Особенно учитывая, что "A slice, on the other hand, is a dynamically-sized, flexible view into the elements of an array." переводится как "Слайс, с другой стороны, (динамической размерности) гибкое ПРЕДСТАВЛЕНИЕ элементов массив". Это, блин, вьюха.
И ссылка на реализацию именно это и подтверждает.
>> Ещё, советую внимание обратить на то, что сейчас идёт спор о терминологии, а не о сути. И в терминологии Go срез это составной тип с изменяемым размером, добавление в который производится при помощи append.
Да вот ни разу. В Go срез - это динамическое ПРЕДСТАВЛЕНИЕ элементов статического массива, о чем вам в доке явно и говорят.
Просто на пальцах:
sliceA := make([]int, 2, 5) - создать массив из 5 элементов, первые два инициализировать дефолтными значениями, поднять вьюху над полученным. В сухом остатке мы ВЫДЕЛИЛИ ПАМЯТЬ под 5(пять) элементов, и это РЕАЛЬНАЯ(предельная) длина слайса. Увеличить этот массив ВНУТРИ слайса мы не можем.
sliceB := append(sliceA, 1, 2, 3, 4) - что только что произошло? что лежит в sliceA, и что лежит в sliceB?
>> Да, переприсваиванием исходной переменной, в которой указатель на данные может измениться, а может и нет, изменится поле len, и возможно изменится поле cap.
Вот по этой вашей фразе я, видимо, имею право предположить, что вы считаете, что sliceA и sliceB идентичны? Ну вот нет, например!
"в которой указатель на данные может измениться" - нееееет, не так это работает. Внутри слайса "указатель на данные", который array unsafe.Pointer НЕ меняется. На выходе у нас будет ДВА РАЗНЫХ СЛАЙСА. Потому что там СЛАЙС целиком новый создается, а не указатель на нулевой элемент массива внутри слайса меняется.
Если бы у нас внутрь существующего слайса складировался новый массив - вопросов бы не было. Но. У нас создается НОВЫЙ слайс с новым массивом внутри, который и возвращается.
Уберите из инструкции присваивание, оставьте только append(sliceA, 1, 2, 3, 4) - знаете, что будет? Будет слайс с массивом [0,0,1,2,3] внутри. А все потому, что слайс, буквально, динамическое ПРЕДСТАВЛЕНИЕ элементов массива. Он умеет менять элементы массива, сам массив внутри константен со всеми вытекающими.
>> изменится поле len, и возможно изменится поле cap
Да что ж вы такое говорите, милчеловек. Поле cap НЕ изменится. Оно в пределах слайса КОНСТАНТА, о чем я вам уже вторые сутки и говорю
Поле cap внутри слайса неизменно. Если в cap появилась другая циферка, значит это другой слайс. Тчк.
>> Пруфлинки на "объекты в Go" в студию! Уверен, что у такого грамотного специалиста не должно быть с этим проблем. Только пожалуйста, не от анонимных ыкспертов или с какого-нибудь стекворерфлоу, а от разработчиков языка.
CS50 - достаточно авторитетный источник? "Объект - переменная, структура данных, функция или метод, значение в памяти, на который ссылается идентификатор."
Вы, видимо, сагрились на слово "объект" из-за ложной ассоциации с ООП? Нет. В базе любая инстанцированная сущность является объектом. Термин используется для того, чтобы четко разграничить тип (класс, декларацию) сущности и экземпляр (инстанцированный) этой сущности.
На всякий случай:
есть декларация struct A {} - это ТИП.
Если переменные a1, a2, a3 типа A - это экземпляры этой сущности, т.е. ОБЪЕКТЫ.

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

181. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от RomanCh (ok), 04-Фев-23, 11:42

> Ну, ссылаться на GoTour - мощный аргумент, конечно.
Нда... Либо вы не умете считать до двух, т.к. смотреть надо было ВТОРУЮ ссылку, либо таки - тред не читай, сразу отвечай. Наверное, от неудержимого желания показать собственную экспертность.
> Вот по этой вашей фразе я, видимо, имею право предположить, ...
Нет, не имеете. Дальше вы спорите с воображаемым оппонентом. Что не удивительно, исходя из того, что у вас проблемы со счётом до двух.
У вас острое желание подогнать терминологию и концепции конкретного случая под привычные вам термины и абстракции. Зачем? Не знаю, возможно недостаточная гибкость мышления, не позволяющая полноценно осваивать новые концепции и вынуждающая страдать синдромом утёнка. В терминологии и концепциях Go нет ни объектов, ни тем более view.
> CS50 - достаточно авторитетный источник?
Это достаточно авторитетный источник для общих случаев. И по тому, что вы цитируете, объектом можно назвать что угодно, и именно потому оно теряет смысл в данном случае. В котором исходный посыл был ООП vs "функциональщина" (которой там нет). Там ещё приводились примеры "доступа к методу" через оператор точки и противопоставлялся ему пример с присвоением через append(), или уже забыли с чего всё началось?
Достаточно авторитетным источником в данном случае будет источник от тех, кто создаёт язык. Ссылка на спецификацию, ну или хотя бы интервью или блог одного из тех, кто его пишет и имеет право задавать терминологию и концепции в данной предметной области. Даже комментарии в исходном коде ЯП возможно подойдут.
PS У вас вот-вот порвётся сова в попытке натянуть её на глобус, остановитесь, сове больно.

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

184. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 13:42

>>>>Вот по этой вашей фразе я, видимо, имею право предположить, ...
>>Нет, не имеете.
Отлично! Из вашей фразы "Да, переприсваиванием исходной переменной, в которой указатель на данные может измениться, а может и нет, изменится поле len, и возможно изменится поле cap" я не имею права предположить, что вы считаете, что поле cap может измениться, и что внутрь слайса может лечь указатель на новый массив? Реально я не имею права предполагать, что если вы говорите "внутри существующего слайса при append'е может измениться указатель на массив и значение поля cap", вы считаете, что внутри существующего слайса при append'е может измениться указатель на массив и значение поля cap? Ну, круто, чо.
Поясню, что в вашей фразе не так. Значение поля cap при append'е в слайсе НЕ меняется. И указатель на массив внутри НЕ меняется.
Вы же, вроде, аналогии с vector'ом проводили? Ну вот, собственно, слайс НЕ вектор. И ключевое отличие ИМЕННО в том, что вектор - динамическая обертка над массивом. При аппенде ВНУТРИ вектора может измениться указатель на массив. Т.е. при реаллокации о копировании содержимого у вас остается ТОТ ЖЕ САМЫЙ вектор, внутри которого лежит ДРУГОЙ массив.
А в Go у вас ДРУГОЙ слайс, внутри которого лежит указатель на ДРУГОЙ массив. Понимаете, в чем разница, и почему таки slice1 = append(slice1, 1)?
Я так и понял, что вы заметили кострукцию, которую видели в соседнем языке, и предположили, что она работает так же. Ну вот нифига, указатель на массив внутри слайса константный, слайс НЕ УМЕЕТ ресайзить массив. Сбоку от всего этого (не внутри слайса, не инкапсулированное поведение, а именно сбоку) есть отдельная конструкция append, которая пишет значения в слайс и возвращает его, или, если слайс слишком маленький, создает новый слайс, и возвращает новый.
У плюсового вектора это поведение ВНУТРИ объекта, а у гошного слайса - СНАРУЖИ. Поэтому вектор - это динамический массив (потому что САМ умеет ресайзить массив), а слайс - представление над статическим массивом (потому что САМ не умеет ресайзить массив, за него это append делает).
Почему вы спроецировали поведение вектора на слайс? Ну, видимо, нужно вернуть вам ваши слова: "Не знаю, возможно недостаточная гибкость мышления, не позволяющая полноценно осваивать новые концепции и вынуждающая страдать синдромом утёнка"
>>  В терминологии и концепциях Go нет ни объектов, ни тем более view.
>> Достаточно авторитетным источником в данном случае будет источник от тех, кто создаёт язык. Ссылка на спецификацию, ну или хотя бы интервью или блог одного из тех, кто его пишет и имеет право задавать терминологию и концепции в данной предметной области. Даже комментарии в исходном коде ЯП возможно подойдут.
Ну, окей, таки поцитируем... Навскидку:
"Like arrays, slices are always one-dimensional but may be composed to construct higher-dimensional objects." (обратите внимание на слово objects) - взято тут https://go.dev/ref/spec, официальная спецификация языка Go.
"""
type T struct {
    name string // name of the object
    value int // its value
}
"""
Обратите внимание на комментарий name of the OBJECT. https://go.dev/doc/effective_go - официальные рекомендации по бестпрактисам го-разработки от создателей языка.
Там же: " it can be more efficient to construct the object with a single allocation". И про объекты, и даже намек, что оно как-то связано с аллокацией.
Думаю, в коде упоминаний объекта тоже достаточно много. Ну, наверное, потому, что объект - базовая концепция CS, совсем не эксклюзивная для ООП. Более того, объект назывался объектом задолго ДО появления ООП, а Алан Кей (создатель концепции ООП) даже утверждал, что, когда он придумывал концепцию, он вообще не C++ имел в виду.
>> В терминологии и концепциях Go нет ни объектов, ни тем более view.
Ну, объекты я вам уже показал. А про view (абстрагируясь от того, что это не языковая концепция, она несколько в другой плоскости лежит), разрешите таки сослаться на go tour:
"A slice, on the other hand, is a dynamically-sized, flexible view into the elements of an array." - вот тут написано, что слайс - это VIEW. Прямо можно побуквенно проверить, перечитать 10 раз, присесть и 4 раза перекувыркнуться, но там все так же будет написано, что слайс - это view, т.е. представление. БУКВАЛЬНО так и написано. И с вашей стороны таки странно давать прямую ссылку на фразу "слайс - это представление" и вдогонку с пеной у рта доказывать, что там ни слова про представление не написано...
>> объектом можно назвать что угодно, и именно потому оно теряет смысл в данном случае
Ну нет же. Класс, например, объектом назвать нельзя... Тип нельзя... Много чего нельзя. Вот функцию можно, но только при условии, что язык поддерживает функции первого порядка. А если не поддерживает, то нельзя. Короче, подскажу: то, что можно положить в переменную, как правило, таки является объектом. Если в переменную положить нельзя - то не объект. Могу еще эвристику дать: если у этого есть адрес в памяти, и вы этим адресом как-то можете воспользоваться - это объект.
То, что, в конечном итоге, более-менее все языки программирования так или иначе пляшут вокруг этой самой концепции объекта, не делает концепцию менее ценной. И то, что в Java той же у вас есть базовый класс с названием object, не делает Java-Object каким-то особенно правильным объектом, на фоне которого объекты (по сути, тупо адресуемые куски памяти), созданные менее-ООПшными языками, менее "объективными". Блин, а JSный object - это объект, в конце концов, или не объект? А в TS? А в спецификации C слово "объект" поищем?
Объект НЕ является ООП-специфичной сущностью. ООП - это один из концептов, построенный вокруг концепции объекта, а собственно объекты - они и в функциональных языках, вы не поверите, таки объекты.
>>  В котором исходный посыл был ООП vs "функциональщина" (которой там нет).
Про то, что функциональщины там нет, это, собственно, я и писал...
А главная ловушка, что ООП "функциональщине" строго ортогонален. Блин, если что-то противопоставлять начинаете, противопоставляйте "императивщину" и "функциональщину" - они хоть в одной плоскости лежат, и в какой-то мере антонимами являются. ООП - вообще про другое, блин.

>> Там ещё приводились примеры "доступа к методу" через оператор точки и противопоставлялся ему пример с присвоением через append(), или уже забыли с чего всё началось?
Помню-помню. И я еще тогда сказал, что спор был на уровне "теплое" vs "мягкое". Там один про "функциональный интерфейс" вещал, а второй контраргументировал вектором. При том, что слайс ни функциональным интерфейсом не является, ни к вектору особого отношения не имеет.

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

185. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 13:57

Окей, короче, давайте просто сравним две абстракции: плюсовый std::vector (динамический массив) и гошный slice (динамическое представление над элементами массива).
1. Внутри у обоих тупо массив, он по определению непрерывный кусок памяти фиксированной длины, ресайзиться не умеет (но нам и пофигу, что оно там внутри, хоть реаллокация, хоть ссылки, хоть 15 тренированных бобров, которые умеют быстро запоминать цифры, до тех пор пока эти инкапсулированные детали реализации не начинают лезть наружу).
2. Пока нам не требуется ресайз, и вектор, и слайс совершенно одинаково тупо пишут/читают элементы массива по смещению.
3. И вот тут нам при очередном append'е места в массиве не хватило... Что дальше?
3.1. В обоих случаях аллоцируется НОВЫЙ МАССИВ, в который гарантированно влезет все, что нужно, содержимое старого копируется в новый.
3.2. Возникают нюансы. Вектор - в поле данных пишет ссылку на новый массив. Слайс? А вот слайс - нифига, он ПРЕДСТАВЛЕНИЕ, он не управляет своим массивом. Да и append'а у него нет, append - сбоку. И этот append берет слайс, видит, что места не хватает, и создает НОВЫЙ СЛАЙС, в который кладет НОВЫЙ МАССИВ.
Понимаете, в чем суть: вектор УМЕЕТ создавать массив нужной длины и копировать, а слайс - НЕТ. Сколько ни append'и чего угодно в std::vector - это будет ТОТ ЖЕ САМЫЙ вектор, у которого внутри происходит какая-то магия. А вот append слайса - это вещь сбоку (т.е. та же самая магия происходит СБОКУ слайса, а не внутри него), и при append'е может вернуться ДРУГОЙ СЛАЙС.
Еще раз, при аллокации:
- std::vector - тот же самый вектор, но с новым массивом внутри.
- slice - новый слайс.
Чуете же разницу?

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

188. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от RomanCh (ok), 04-Фев-23, 14:44

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

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

189. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 15:38

>> Бегло прочитав данный пост, я вижу, что вы по прежнему пытаетесь использовать концепции привычного вам языка, в языке совершенно ином.
Окей, перейдем к официальной терминологии языка... Ну, как бэ, вот:
Это ваша формулировка: "Срезы, это "массивы" динамического размера"
А вот это - из спецификации языка: A slice is a descriptor for a contiguous segment of an underlying array and provides access to a numbered sequence of elements from that array.
Переведем? Слайс есть дескриптор непрерывного сегмента нижележащего массива, предоставляющий доступ к упорядоченной последовательности элементов этого массива.
Прямо вот в спеке написано, что это, де факто, представление. При этом ни слова про "динамический размер" нет. И даже чуть ниже написано, что слайс ассоциируется с массивом единожды при инициализации, т.е. менять размерность не может.
Зачем мне сову на глобус тянуть? Официальная спецификация языка, видимо, все сделала за меня?

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

190. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от RomanCh (ok), 04-Фев-23, 17:58

> A slice is a descriptor for a contiguous segment of an underlying array and provides access to a numbered sequence of elements from that array.
Рад, что вы открыли для себя страницы спецификации.
> Прямо вот в спеке написано, что это, де факто, представление.
Нет, в спеке написано то, что там написано. А не то, что вы там хотите видеть. А ещё, там написано то, что вы видеть не хотите:
> При этом ни слова про "динамический размер" нет.
А что будет, если читать дальше первого предложения? А будет неудобно:
> The length of a slice s can be discovered by the built-in function len; unlike with arrays it may change during execution.
Лол! :-D
> Зачем мне сову на глобус тянуть?
Самоутвердиться хотите - видимо за этим, но получается плохо. Хотя, вот вы спеку уже начали читать,  это уже некоторый успех нашей дискуссии. Совсем хорошо будет, если вы не будете останавливаться на первом же предложении...
PS В спеке слово "object" встречается один раз, слово "view" - 0. Это нам как бы намекает... Поразмыслите об этом.

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

194. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 20:21

>> А что будет, если читать дальше первого предложения? А будет неудобно:
> The length of a slice s can be discovered by the built-in function len; unlike with arrays it may change during execution.
Да, действительно, неудобно очень читать до второго предложения и не видеть третье...
```
make([]T, length, capacity)
produces the same slice as allocating an array and slicing it, so these two expressions are equivalent:
make([]int, 50, 100)
new([100]int)[0:50]
```
ВНИМАТЕЛЬНО прочтите, что тут написано. Вот прямо дословно написано: "allocating array and slicing it". Даже для удобства гиперссылкой помечено, что такое "slicing". Вот там такое "Slice expressions construct a substring or slice from a string, array, pointer to array, or slice."
Понимаете, аллоцируется массив, слайс аллоцироваться не умеет, он просто диапазон "с элемента X по элемент Y массива Z". Вот прямо здесь, в примере из официальной спецификации, мы выделили массив на 100 элементов, и из этого уже алоцированного массива получили слайс - view'ха на первые 50 из них. И append'ить вы можете, но только в пределах cap'а, который равен длине массива. Если за cap вылазите, создается НОВЫЙ СЛАЙС. Потому и append так странно выглядит.
Еще раз повторю: слайс - это диапазон, определенный над массивом, о чем вам в ОФИЦИАЛЬНОЙ СПЕЦИФИКАЦИИ прямым текстом говорят. В связи с этим слайс не умеет ничего алоцировать и ресайзить, что делает его буквально представлением над обычным массивом константной длины. Он, в конце концов, даже называется, прямым текстом, "slice". Не dynamic array, не list, не vector, он именно slice - погуглите перевод.
Вот вы прямым текстом тут писали, что у слайса cap измениться может.
Давайте попробуем:
a := make([]int, 0, 10) // очевидно, cap=10 же?
Подскажите мне, пожалуйста, каким штатным образом (без рефлексии и unsafe-блоков) я могу изменить cap конкретно этого слайса. Покажете - 10 баксов дам! Не покажете - слайс не является динамическим массивом (ЧИТД)

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

196. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от RomanCh (ok), 04-Фев-23, 21:09

Отлично, я вас научил читать документацию! Правда, похоже это без толку, потому что вы определённо не умеете понимать тексты написанные другими людьми. Но зато активно насилуете сов и пытаетесь пихать привычную вам терминологию туда, где она чужеродна. И видимо, разучились методу познания отличному от метода "по аналогии". Мои соболезнования.
> слайс не является динамическим массивом (ЧИТД)
Я конечно мог бы вас потроллить на тему "а что такое динамический массив, и кто на самом деле аллоцирует?" и было бы забавно. Но ситуация и без того до грустного абсурдна. Дело в том, что вы пытаетесь опровергнуть заявление, которое никто и не говорил. А что я писал, я вам напомню:
> Срезы, это "массивы" динамического размера
Заключение слова в кавычки вам ни о чём не говорит? Тогда ещё раз мои соболезнования. И если вы столь бурно готовы спорить с воображаемым собеседником, то это уже ко врачу.

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

197. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от QrKot (?), 04-Фев-23, 22:01

Кроме "срезы - это "массивы" динамического размера", что, по прежнему, неправда, вы ещё говорили о том, что в срезе cap может измениться. Очень хотелось бы понять, как вы себе это представляете.

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

199. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 22:56

>> Я конечно мог бы вас потроллить на тему "а что такое динамический массив, и кто на самом деле аллоцирует?" и было бы забавно.
Не, это было бы грустно...
"Динамическим называется массив, размер которого может изменяться во время исполнения программы" - собственно, все. В понимании того, что такое собственно массив мы с вами, вроде, сходимся.
Ну т.е. нам нужна штука, которая выглядит как массив, ведет себя как массив, и при этом, самое важное, умеет менять свой размер. Монотонно, однообразно, без сюрпризов, просто тупо менять свой размер...
Ну, собственно, слайс не умеет (если вы срочно не покажете мне, как изменить cap существующего инициализированного слайса). Финал.
>> кто на самом деле аллоцирует
Аллоцирует make, например. В спеке же написано, что make делает. Он аллоцирует массив с размерностью cap и отдает этот массив в функцию slice, которая на выходе тупо возвращает структуру, содержащую 2 int'а и один unsafe.Pointer.
make([]int, 50, 100) - полный эквивалент new([100]int)[:50].
При этом никто не запрещает сделать так:
```
array := new([100]int)
slice1 := array[:50]
slice2 := array[50:]
```
Что мы только что посмотрели? Ну, как бэ, у нас 1(один) массив и 2(два) слайса над ним. Представляете, ДВА слайса ссылаются на ДВА разных диапазона ОДНОГО массива! Как эту концепцию принято в программировании называть? Представление же? Да? А по английски оно же view будет?
Теперь внимательно посмотрим, кто на самом деле аллоцировал... Ну, очевидно, не слайс... Аллоцировала директива make... А слайс тут не при чем, он аллоцировать не умеет, он ПРИ ИНИЦИАЛИЗАЦИИ принимает массив, и положить внутрь себя другой не может. Если надо новый массив, т.к. в старый уже не лезет... Ну, вот вам append, он может создать ДРУГОЙ массив и нарезать НОВЫЙ слайс из него. А вот cap старого изменить, или внутрь старого новый массив положить - нет, не может... Поэтому и не динамический. Потому что при увеличении размера массива создается новый слайс.

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

202. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от RomanCh (ok), 05-Фев-23, 10:58

Забавно, комментарий с "нейросетью" удалили.
Так вот, у нас с вами сугубо терминологический спор уровня:
- Это автомобиль, то есть - самодвижущаяся повозка!
- Нет, вы не правы! Автомобиль движется совершенно не сам, это сложная система, внутри которой есть двигатель (ВС/электро/паровой) управляемый водителем, работа двигателя происходит за счёт преобразования одного вида энергии в другой, и чтобы это случилось водитель должен ...(много-букв)... что запускает механизмы ....(ещё больше букв)...
У вас проблема в том, что вы не можете отделить в тексте абстракцию от подробностей её реализации. Либо требуете чтобы абстракция выглядела ровно так, как вы привыкли, для того, чтобы вы её признали "автомобилем". Не желая понимать, что автомобили могут быть немножко разными, и управляться немного по разному. И они по прежнему будут считаться автомобилями. Почитайте например, как управлялся Ford Model T1.
И в Go срез используется *как* динамический массив (коих в нём нет, и никто не утверждал, что они там есть), чей размер в логике принятой в языке модели абстракций можно изменять, как бы вы не пытались доказать обратное давя оппонента тоннами очевидных ему подробностей реализации абстракции.
Итого, это моё последнее слово:
> The length of a slice s can be discovered by the built-in function len; unlike with arrays it may change during execution.
А вам остаётся пожелать только быть немножко меньше нейросетью. Либо, уметь понимать, что вы иногда можете оказываться неправы и тратить время на что-то более полезное.

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

206. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 06-Фев-23, 19:41

>> У вас проблема в том, что вы не можете отделить в тексте абстракцию от подробностей её реализации.
Разрешите воспользоваться вашей же аналогией с автомобилем:
Вот есть автомобиль - "Самодвижущееся транспортное средство с двигателем для перевозки грузов и пассажиров по безрельсовым путям". В целом, у него внутри может быть ДВС, может быть электродвигатель, может быть паровой котел - вообще по барабану. Пока оно само едет - это автомобиль, остальное - детали реализации. Это наш условный std::vector либо любая другая реализация динамического массива.
А вот рядом с ним стоит прицеп. У него и колеса, как у автомобиля, и блестит так же... Всего один недостаток у прицепа - у него нет внутри двигателя. Вот не едет он сам, и все. Хоть лошадь запрячь - но надо. Но вы не волнуйтесь, это не беда. Для того, чтобы он ехал (в нашем случае, менял размер), вам дают стандартный мотоблок (append). Он немного с причудами, отказывается один и тот же прицеп дальше установленного производителем расстояния везти, поэтому раз в 50 км приходится цеплять к нему новый прицеп, пересаживаться, и только потом ехать дальше.
Ну вот я говорю, что автомобиль - транспортное средство С ДВИГАТЕЛЕМ, а потому прицеп автомобилем не считается, даже если есть всегда доступный напрокат мотоблок. А вы говорите, что если в ближайшем пункте проката есть доступные мотоблоки, то любая хрень с колесами считается автомобилем.
Ну а про абстракцию: абстракция на то и абстракция, что АБСТРАГИРУЕТ нас от деталей реализации. От ручного ресайза нас слайс не абстрагирует, поэтому он нифига и не динамический.
>> The length of a slice s can be discovered by the built-in function len; unlike with arrays it may change during execution.
Блин:
slice := make([]int, 1, 1)
Покажите мне, пожалуйста, как вы штатными средствами измените length (ну или, хотя бы, capacity) этого слайса, тогда признаю себя неправым. Просто маааленький кусочек кода...
Ну, не покажете - тогда он не динамический, ЧИТД.

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

198. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 22:37

>> В спеке слово "object" встречается один раз, слово "view" - 0. Это нам как бы намекает...
На что, простите намекает?
В effective Go слово object встречается 10 раз. Например, авторы напрямую называют экземпляр/инстанс любой адресуемой сущности объектом, их это не смущает.
А в исходниках Go слово object используется 15921 раз...
Вот, например: ERROR "cannot slice|attempt to slice object that is not"
Они пытаются слайсить какой-то object... Погодите, их же нет в Go??? Надо им срочно написать, мужики-то не знают!
These tests check that allocating a 0-size object does not... - аллоцировать еще какие-то объекты пытаются...
object pointers and token positions always match - долбаные указатели на несуществующие объекты с какими-то токенами не совпадают...
Не дофига ли проблем с несуществующей вещью?
Ну, или, может быть, все проще? И разработчики языка просто CS50 проходили, и позволяют себе называть то, что является объектом, объектом?

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

205. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (205), 06-Фев-23, 09:10

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

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

138. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Neon (??), 02-Фев-23, 21:50

Функциональность - новая мода, с которой все носятся как дурни с писанной торбой

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

140. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +3 +/–

Сообщение от morphe (?), 02-Фев-23, 22:08

> Ты видишь "функциональность" этого append'а? Он не меняет переданный ему слайс, он возвращает новый слайс, созданный на основе s и остальных аргументов.
Не обязательно, и это страшно
append может изменить исходный слайс, т.к у слайсов есть capacity, это у них оптимизации такие :D
Но да, если исходный слайс не имеет лишнее место - то новый слайс возвращается
https://stackoverflow.com/questions/68042972/why-append-slic...

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

141. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +4 +/–

Сообщение от morphe (?), 02-Фев-23, 22:15

В отличии от языков с нормальным дизайном, разработчики golang решили сделать чтобы слайс работал как вектор, и футганов тут дофигища.
    package main

    import "fmt"

    func main() {
            a := []int{0}
            for i := 0; i < 40; i++ {
                    b := append(a, 0)
                    a[i] = 1
                    fmt.Printf("%d ", b[i])
                    a = b
            }
    }
→ 0 0 1 0 1 1 1 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1

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

145. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от OpenEcho (?), 03-Фев-23, 03:21

> → 0 0 1 0 1 1 1 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1
А что предполагалось увидеть на выхлопе?
Если заменить
а := []int{0}
на предсказуемый размер (как и других языках)
а := маке([]int,40)
то получится предсказуемое заполнение единицей  вместо абракадабры. Но это все равно туфта, потому что тогда "b" будет как минум в два раза больше "а"

а = b
Это копирование указателя дескриптора слайса B в A , а не копирование содержимого одного слайса в другой и поведение вполне следует логике, что незжаем на родительский массив.
Если же заменить a=b на
_ = copy(a,b)
то тогда это будет копирование и получится бегущая единичка вместо заполнения, и память расти не будет
Я не спорю, что без четния доки можно нарваться, но язык то все таки низкоуровневый хоть и простой.

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

146. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от morphe (?), 03-Фев-23, 03:34

> А что предполагалось увидеть на выхлопе?
Человек написал что append в golang функциональный, и исходный буфер не трогает
Если бы это было так, то на выходе были бы всегда нули, однако на деле append трогает исходный слайс, если в нём есть свободное место, а если места нет - то создаёт новый слайс, в котором в 2 раза больше места
> Я не спорю, что без четния доки можно нарваться, но язык то все таки низкоуровневый хоть и простой.
Ну вот он нифига не низкоуровневый, ибо подобную мешанину слайсов и векторов надо ещё постараться сделать, в golang существованию всего этого помогает GC
А по простоте - не проще ли использовать тот же самый Rust, в котором слайсы, массивы, и вектора явно разделены, и никаких подобных футганов просто не существует, а код работает ровно так, как ты от него это ожидаешь?)
Это же даже не единственная проблема в golang, кривой дизайн языка тут на каждом шагу

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

150. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от OpenEcho (?), 03-Фев-23, 04:32

> Человек написал что append в golang функциональный, и исходный буфер не трогает
Сорри, не понял, согласен, с append-om нужно быть осторожным, точнее просто знать как он работает

> А по простоте - не проще ли использовать тот же самый Rust,
> в котором слайсы, массивы, и вектора явно разделены, и никаких подобных
> футганов просто не существует, а код работает ровно так, как ты
> от него это ожидаешь?)
Теоритически, согласен, но вот его ржавый ситаксис... разработка одного и того же продукта на го и расте значительно отличается по времени. Го он как отпрыск php, легко понимается но уже и повзрослел и поэтому выдать на нем продукт значительно быстрее чем на расте

> Это же даже не единственная проблема в golang, кривой дизайн языка тут
> на каждом шагу
А в каком языке его (кривого дизайна) нет? С? ну да, если человек правда любит свою работу, то практически это легкий ассемблер, но как много таких гиков чтоб управлять им без ошибок... С++ с его 1000+ страниц спецификации языка? Сравним с Го-шкой с их всего навсего 50 страниц спецификации. Что легче поднять? Чем проще, тем надежнее, именно поэтому язык и взлетел ИМХО

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

173. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от QrKot (?), 03-Фев-23, 21:20

≥≥если места нет - то создаёт новый слайс, в котором в 2 раза больше места
Простите, чуть-чуть поправлю: не в 2, там по дефолту в полтора, вроде. Ну и чуть-чуть ещё условий сверху.
Но в целом все верно написано, это да, Слайс именно такой.
≥≥ мешанину слайсов и векторов надо
А вот тут не понял, вектора тут вообще каким боком?
≥≥ не проще ли использовать тот же самый Rust
А вот тут вопрос абсолютно правильный. И ответ очевиден: не проще. Раст значительно более требователен к когнитивным способностям кожаного мешка перед клавиатурой, поэтому "рыночек порешал", и победитель уже определен.
Да и по фичам: "математическая доказуемость корректности кода" vs "M:N асинхронность из коробки". Внутренний пурист и тщательно скрываемый сноб сколько угодно может требовать первого, но бизнес готов массово давать деньги только за второе.
≥≥ Это же даже не единственная проблема в golang, кривой дизайн языка тут на каждом шагу
Кривой дизайн не является исключительной фичей Go, злые языки, например, утверждают, что Раст тоже небезгрешен.

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

175. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от RomanCh (ok), 03-Фев-23, 22:36

> Простите, чуть-чуть поправлю: не в 2, там по дефолту в полтора, вроде.
А как на счёт посмотреть исходник, и не писать результаты своих гаданий? Ведь за минуту можно найти и "распарсить" как оно работает. Или это слишком низко для вашего уровня? )

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

180. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 11:12

А, ну да, в 2 раза, my bad. При размере слайса до 256 элементов... А дальше таки с нюансом "в 1.25 раза для больших слайсов (более 256 элементов) с плавным изменением коэффициента в зависимости от размера слайса", да ведь?
Вы же тоже читали growSlice метод целиком? Или это слишком низко для вашего уровня?)

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

182. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от RomanCh (ok), 04-Фев-23, 11:56

> А, ну да, в 2 раза, my bad.
Вот нет бы тут остановиться, и было бы красиво. Ну бывает, люди совершают ошибки, все, даже самые опытные. Признать ошибку - нормально и хорошо для состоявшегося специалиста. Но нет, вы просто неудержимы...
> Вы же тоже читали growSlice метод целиком? Или это слишком низко для вашего уровня?)
1. Очень "умное" замечание, с учётом того, что это именно я вас туда и отправил.
2. Опять вы самоподорвались на терминологической мине. Нет никакого *метода* growSlice... Да и регистр букв имеет значение.
3. К вашему не умению использовать более одной концепции и соответствующей ей терминологии. Т.е. о том, что у среза фиксированная длина - а вам не кажется странным, что функция в названии содержит слово grow? Не make, create или new, а именно grow? А если комментарии в коде почитать?
Ещё раз повторюсь - у нас терминологический спор, а не спор о том, как оно там на самом деле работает. Хотя, как мы на этом примере видим, с тем как оно на самом деле работает, у вас тоже не всегда всё гладко, но это правда мелочи.
Советую не тратить время пытаясь мне "объяснить" то, что я не хуже вас знаю, а попробовать взглянуть на предмет иначе - в оригинальной терминологии и концепциях авторов. А не так, как вам привычно. Тогда многое станет проще и понятней.

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

187. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 14:27

>> Т.е. о том, что у среза фиксированная длина - а вам не кажется странным, что функция в названии содержит слово grow? Не make, create или new, а именно grow? А если комментарии в коде почитать?
Дык, а давайте прямо комментарии в коде и почитаем.
Строка 126: // growslice allocates new backing store for a slice.
Ну и в код заглянем, в сам метод, с 281 строки:
```
    memmove(p, oldPtr, lenmem)
    return slice{p, newLen, newcap}
}
```
внимательно смотрим...
делай раз: копируем содержания старого слайса в новый
делай два: возвращаем новый слайс
Понимаете, в чем фокус? Там НЕ в существующем слайсе указатель на массив меняется, а НОВЫЙ СЛАЙС создается! Т.е., дословно, мы НЕ МЕНЯЛИ размер текущего слайса, мы СОЗДАЛИ НОВЫЙ СЛАЙС. Не новый массив в слайс положили, что было бы логично, исходя из концепции "слайс - это динамический массив", а создали ДРУГОЙ СЛАЙС (что логично, исходя из концепции "слайс - это динамическое представление").
Динамический массив - это штука, у которой мы можем поменять размер.
Вот вектор - это реализация "динамического массива". Да, внутри точно так же создается новый массив, но это происходит внутри вектора. Т.е. в результате мы получаем ТОТ ЖЕ САМЫЙ вектор, внутри которого лежит новый массив. И это законно, нам по барабану, что там с массивами, мы с вектором работаем, а с ним ничего странного не происходит, это все тот же вектор, у него даже адрес в памяти тот же самый. Что у него внутри изменилось - это его головняк, он на то и абстракция.
А в случае со слайсом - кухня-то та же самая. Но, при append'е, вызвавшем resize массива мы получаем ДРУГОЙ слайс. Не другой массив, не слайс, у которого изменился содержащийся в нем массив... Там другой слайс! Вот ровно для этого пишут:
slice1 = append(slice1, 10)
Не потому что оно "функциональное" и т.д. и т.п. А потому что при append'е может вернуться ДРУГОЙ СЛАЙС. Это другой объект, другой инстанс, у него другой адрес в памяти. Вот это присвоение - оно для того, чтобы в переменную, в которой лежал слайс, в случае чего, не забыть положить новый.
При этом вы совершенно законно можете ничего никуда не присваивать. Просто написать append(slice1, 10). И ничего не случится. И даже все будет хорошо... Ну, пока за cap не заступите. После этого на каждый append будет создаваться новый слайс, будет выделяться память, слайс будет инициализироваться и... и тупо отдаваться сборщику мусора... В старом ничего не изменится.
>> Хотя, как мы на этом примере видим, с тем как оно на самом деле работает, у вас тоже не всегда всё гладко, но это правда мелочи.
Не, это не я пытаюсь доказать, что слайс работает так, как std::vector... Ну вот он не так работает. Вектор умеет ресайз. Слайс - нет, зато append умеет создавать новый слайс по необходимости.
>> попробовать взглянуть на предмет иначе - в оригинальной терминологии и концепциях авторов.
Ну вот я вам в оригинальной терминологии и концепциях авторов говорю, дословно: слайс - это "flexible view into the elements of an array" (гибкое представление элементов массива).  А вы мне: слайс - это динамический массив.
Вот даже в спецификацию заглянул, не поленился:
"A slice is a descriptor for a contiguous segment of an underlying array and provides access to a numbered sequence of elements from that array. " - слайс является дескриптором непрерывного сегмента нижележащего массива и предоставляет доступ к перечислимой последовательности элементов из этого массива.
Оттуда же почитаем?
"A slice, once initialized, is always associated with an underlying array that holds its elements." - слайс, будучи инициализированным, всегда ассоциирован с нижележащим массивом, содержащим его элементы. Прям так и говорят - слайс ассоциируется с массивом при инициализации...
Короче, найдите мне в спецификации хотя бы слово про том, что слайс - динамический массив, и я вам пива куплю (подскажу, там такого нет).

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

191. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от morphe (?), 04-Фев-23, 18:27

> В старом ничего не изменится
В старом изменяется длина, но остаётся прежним capacity. Т.е слайс таки имеет динамический РАЗМЕР, а capacity это всё же деталь реализации, которая и делает из слайсов какую-то херь

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

195. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от cheshirekot (ok), 04-Фев-23, 20:47

>> В старом изменяется длина, но остаётся прежним capacity. Т.е слайс таки имеет динамический РАЗМЕР, а capacity это всё же деталь реализации, которая и делает из слайсов какую-то херь
Ну вот нет же...
```
    s0 := make([]int, 10, 10)
    fmt.Printf("len=%d|cap=%d\n", len(s0), cap(s0))
    _ = append(s0, 10)
    fmt.Printf("len=%d|cap=%d\n", len(s0), cap(s0))
```
Запустите, не поленитесь. Ни len ни cap не изменились. Ну т.е. вот это "В старом изменяется длина, но остаётся прежним capacity." - неправда. Длина не может быть выше вместимости, и слайс динамического РАЗМЕРА не имеет. Он вообще размера не имеет, размер есть у нижележащего массива, который таки массив статической длины.
А вот когда аппендить надо, а оно не лезет, создается НОВЫЙ массив, в который влезет, в него копируется содержимое старого массива + то, что должно влезть, и поверх этого берется НОВЫЙ слайс.
Если бы при этой операции был СТАРЫЙ слайс с указателем на НОВЫЙ массив внутри - я бы слова не сказал, это бы и были внутренние детали реализации. Но это именно что НОВЫЙ слайс. Т.е. не "я тут в слайсе массив пересоздал, пользуйся", а "твой старый слайс пришел в негодность, вот тебе новый". А "старый" в негодность пришел именно по причине, что он НЕ МОЖЕТ двигаться за пределы массива, т.е. он вообще ни разу не динамический.
Ну или мы обычный массив динамическим считать начинаем. Просто представьте ситуацию:
1. Нам нужен массив примерно на 10-15 элементов.
2. Мы, чтобы не наступать в излишнии аллокации, выделяем массив на 20.
3. Начинаем append'ить элементы... Ну, точнее, просто по индексу значения выставлять, ничего никуда мы не append'им, просто устанавливаем значения в имеющемся массиве.
4. И тут выясняется, что мы обсчитались, нужен 21-й элемент...
5. Мы выделяем новый массив, на всякий случай на 40 элементов, копируем туда первые 20, потом устанавливаем 21-й по индексу, работаем дальше с новым массивом, старый забываем.
Это у нас сейчас "динамический массив" сейчас был? Я правильно понял?
Или для того, чтобы называть некую сущность динамическим массивом, таки нужно, чтобы это поведение было ВНУТРИ этой сущности?
>>  Т.е слайс таки имеет динамический РАЗМЕР
Слайс, к сожалению, динамического размера не имеет. Слайс - это структура, состоящая из 3 полей: len, cap, array. Два int'а и один unsafe.Pointer. Ну, т.е. в сумме 3 машинных слова, получается.
Все потому, что слайс - это диапазон элементов массива. У него, заметьте, даже offset'а никакого нет, т.е. в unsafe.Pointer'е не на начало массива указатель, а на нулевой элемент слайса.
Спека:
```
make([]T, length, capacity)
produces the same slice as allocating an array and slicing it, so these two expressions are equivalent:
make([]int, 50, 100)
new([100]int)[0:50]
```
Вот прямо тут - аллоцируется массив, и от него берется слайс. Слайс - это диапазон с 1-го по 50-й элемент этого массива, в cap ложится 100. Напишите [1:51] - будет со второго по 51-й, с cap'ом 99. И вот до конца массива слайс может что-то делать. При выходе за cap - уже нет, там уже новый слайс.

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

177. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от morphe (?), 04-Фев-23, 06:49

> Простите, чуть-чуть поправлю: не в 2, там по дефолту в полтора, вроде.
Я пример кода скинул, который демонстрирует это
> → 0 0 1 0 1 1 1 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1
Нули на позициях 2,4,8,16,32, именно тогда и проходили реаллокации. Но не суть)
> А вот тут не понял, вектора тут вообще каким боком?
Потому что динамического размера массивы - вектора, изменяемого размера view на массив даже звучит дико
> Кривой дизайн не является исключительной фичей Go, злые языки, например, утверждают, что
> Раст тоже небезгрешен.
Я не говорю что Rust не имеет косяков, однако в нём никогда не делали вещи намеренно некорректными ради "простоты", и не забивали на достижения в языкостроении совершённые с 1980х годов. Утиная типизация интерфейсов? Нулевые значения для всех типов? Конечно, хочешь отличать пустую строку и её отсутствие - заводи отдельную переменную/уводи её под указатель, что с nil интерфейсами может очень весело обсираться. Для языков со встроенной многозадачностью, в golang слишком просто получить data race/дедлок. Менджмент пакетов, if err != nill {return err}, дичь с монотонным и wallclock временем, процессоры кода смотрящие на комментарии и игнорирующие их в случае ошибки, реализация unionов через структуру с одним заданным полем... И это лишь то, что я сходу помню и не поленился написать.
Конечно, внимательное чтение документации по golang делает может спасти от многих проблем, однако никто не идеален, все допускают ошибки, и язык должен предотвращать как можно больше из них, с чем в golang ситуация обстоит ужасно. В golang решили упростить множество вещей, чтобы они "правильно" работали в большинстве случаев, однако в остальных случаях код просто молча начинает работать некорректно, что допустимо по большей части лишь для разработки CRUDов.

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

211. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от qrKot (?), 07-Фев-23, 10:57

>> Нули на позициях 2,4,8,16,32, именно тогда и проходили реаллокации. Но не суть)
Просто в качестве занудства: это только до 256 элементов в массиве. Дальше приращивается с шагом по 1.25.
Но действительно, не суть.
>> Потому что динамического размера массивы - вектора, изменяемого размера view на массив даже звучит дико
Вот именно поэтому, как мне кажется, молодежи с горящими глазами, несущими свет знания о динамических массивах в го, по ошибке названных срезами, нужно совершенно недвусмысленно доводить простую мысль: в Go динамических массивов нет. От "гибкого динамического представления элементов массива" меня тоже слегка в оторопь бросает, но суровая правда жизни в том, что слайсы - это именно оно и есть. Собственно, концепция слайсов не нова, она в том же Python'е во все поля есть. Специфика Go в том, что некий гениальный сумасшедший учёный запилил чудодейственный append, который позволяет этими слайсами через хитрозаверченную жопу сэмулировать поведение, издалека похожее на динамический массив.
По хорошему, нормальную реализацию бы запилить... Но, эту штуку придется согласовывать по поведению со слайсами, которые уже завезли... Решили, что и так достаточно изящно, на этом и успокоились.
>> Утиная типизация интерфейсов? Нулевые значения для всех типов? Конечно, хочешь отличать пустую строку и её отсутствие - заводи отдельную переменную/уводи её под указатель, что с nil интерфейсами может очень весело обсираться.
Ну, типобезопасность никто и не декларировал... К сожалению... Фишка Go, КМК, причина достаточно бодрого взлета, "в отличие от" - его УТИЛИТАРНОСТЬ. Вот прям девиз языка: УТИЛИТАРНОСТЬ. В Rust принято возбуждаться от КОРРЕКТНОСТИ, в Go - дрочат вприсядку на УТИЛИТАРНОСТЬ.
Ну, т.е., в своей нише Go, несмотря на всю общую "некузявость" подхода, вполне себе вне конкурренции.
>> Для языков со встроенной многозадачностью, в golang слишком просто получить data race/дедлок.
А вот этот пункт бы оспорил. Собственно, M:N, если мне память не изменяет, "искаропки" есть, собственно, только в Go и Haskell. В связи с этим сравнивать-то и не с чем, собственно. Да, в том же Python с M:1 или Java с 1:N дедлок словить сложнее... дык, они и M:N не умеют, а сложность имеет свойство возрастать квадратично. Так что в Go еще вполне себе ничего, могло быть сильно хуже.
>> Менджмент пакетов, if err != nill {return err}, дичь с монотонным и wallclock временем, процессоры кода смотрящие на комментарии и игнорирующие их в случае ошибки, реализация unionов через структуру с одним заданным полем... И это лишь то, что я сходу помню и не поленился написать.
Ну, как говорится, жить можно. Примерно такой же списочек можно на любой, имхо, язык написать. С единственным нюансом: if err != nil - то за что? Ну, нет исключений. Ну, их много где нет, да и сама по себе концепция исключений достаточно перегруженная, а некоторые реализации (кто сказал Java) - монструозны и вылазят лютейшим боком спустя десятилетия. Обработка ошибок - тупо данность, не хорошо и не плохо. Что лучше "if err != nil" на месте, или "иерархия классов исключений" где-то хрен знает где в спецификации языка - вполне дискуссионный вопрос.
>> Конечно, внимательное чтение документации по golang делает может спасти от многих проблем, однако никто не идеален, все допускают ошибки, и язык должен предотвращать как можно больше из них, с чем в golang ситуация обстоит ужасно.
Поэтому, видимо, в golang и не тащат все, что блестит. А язык... Язык должен закрывать потребности в своей нише. Гоша справляется, и достаточно хорошо справляется, с очевидными "продаваемыми" фичами.
Доказать менеджменту, что "надо дать денег, чтобы переписать на Go. На этом мы сможем выключить 89 серверов из 100, и сэкономим 80% операционного бюджета" гораздо проще, чем "надо дать еще больше денег, чтобы переписать на Rust. На этом мы сможем быть уверены, что наш код корректен" (угадайте вопрос, который вам менеджмент задаст сразу после этой фразы!)
>> В golang решили упростить множество вещей, чтобы они "правильно" работали в большинстве случаев, однако в остальных случаях код просто молча начинает работать некорректно
Да не, код ВСЕГДА работает корректно. Просто молодежь раз за разом наступает на грабли типа "слайс - это динамический массив" (грешен, сам наступал, сам так думал, был искренне удивлен, когда понял, что это не так). Почему она так думает? Ну, собственно, оно издалека очень похоже. А еще специалист, как правило, парочку соседних языков щупал. Вот собственно вектор примерно везде одинаково и работает. Вот и специалист думает, что "вот эта блестящая штука выглядит как вектор, наверное это вектор". На возражения - отмахивается, мол, "у нас тут утиная типизация".
А утиная типизация - это "выглядит как утка И крякает как утка". Выглядит оно как утка, а крякать-то и не умеет(. Вот именно слайс - самая проблемная для ПОНИМАНИЯ вещь в Go. Но язык УТИЛИТАРНЫЙ - ничего не изменится. Хотя вектор накидать можно минут за 10 - дженерики-то подвезли уже.
В общем, код-то работает КОРРЕКТНО, просто не так, как ожидал тот, кто его написал, опираясь на неверные представления о том, что пишет... Больно - да. Справедливо - тоже да. Что делать? - да хз. Когда это починят? - никогда.
Просто вы целый воз недостатков вывалили (и они, в целом, все есть, даже особо спорить не буду, хотя лично я часть этих недостатков недостатками не считаю). При этом в Go есть две вещи: горутины и каналы. Вот это - те самые две штуки, за которые языку прощают весь ваш список, и еще много чего сверху простят. Так что за дизайн ругайте, пофиг ваще. А про многозадачную асинхронность - не смейте! Руки прочь от СВЯТОГО!)))

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

176. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от RomanCh (ok), 03-Фев-23, 22:42

> а код работает ровно так, как ты от него это ожидаешь?)
У меня на Go код работает так, как я от него ожидаю, что я делаю не так? Ах, да, читаю документацию перед тем, как что-то делать, а не после того, как всё сломалось...
> Это же даже не единственная проблема в golang, кривой дизайн языка тут на каждом шагу
Принесите же наконец нам ваш божественный язык с идеальным дизайном на все случаи жизни!
Или быть может, просто надо понять, что люди разные, и разным людям нравятся несколько разные вещи и подходы? Вас ведь вроде, никто не заставляет писать на Go, пишите на том, на чём вам нравится.
В чём смысл ваших лучей поноса?

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

172. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от QrKot (?), 03-Фев-23, 20:04

При чем тут, простите, функциональное АПИ? Слайс к функциональщине не имеет никакого отношения, ну вообще никакого, он императивный в хлам.
А запись такая потому, что таки да, Слайс не умеет ресайзиться, Слайс вообще есть грязный хак по своей природе. В функциональном подходе за такое по рукам бьют.
≥≥ Он не меняет переданный ему слайс, он возвращает новый слайс, созданный на основе s и остальных аргументов
Ну вот неправда же. Он МЕНЯЕТ переданный ему Слайс, именно меняет. А в случае, если капасити слайса не хватает, создаёт новый, чтобы дописать то, что в старый не влезло.
А уже потом возвращает либо переданный Слайс, если влезло, либо новый, если в старый не поместилось

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

204. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (204), 06-Фев-23, 00:46

https://bluxte.net/musings/2018/04/10/go-good-bad-ugly/#slic...
В go слайсы это полный треш, нихрена не такие удобные как их хорошо пропиарили, да и вообще языку нужны нормальные типы контейнеров, нормальный синтаксис для классов (можно хоть не вводить this). Они бы могли базироваться на llvm как rust, но в те древние времена в llvm не было сигментмрованного стека. Рефлексии для приватных объектов нет. Если написать свой тип данных то вся type safety исчезает. В одном его рантайме целый вагон различных моментов где можно словить panic. По сути нужно знать дофига моментов почему тут нужно делать не так, а вот здесь nil не nil. Абсолютно такие же "мелкие ляпы" там сям есть и в nim.

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

210. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от qrKot (?), 07-Фев-23, 10:10

>> В go слайсы это полный треш, нихрена не такие удобные как их хорошо пропиарили
В Go слайсы - это "дескриптор непрерывного сегмента нижележащего массива, предоставляющий доступ к перечислимой последовательности элементов этого массива". Именно в этой роли - вполне себе не ужас. Ужас - это считать, что слайс - реализация динамического массива, потому что он вообще не массив (и не связный список, и внутри у него ни того, ни другого нет) и ни разу не динамический.
В конечном итоге, динамических массивов в Go нет, как, впрочем, и в десятках других языков. А функциональную потребность в динамическом массиве принято закрывать набором обвязок из make и append. Собственно, ровно так же, как это делается в том же C, например.
Ничего страшного в этом нет, а миф о том, что слайс - плохой динамический массив, проистекает из того факта, что слайс НЕ динамический массив. Собственно, лошадь с телегой тоже хреновый грузовой автомобиль, хотя функциональную потребность и закрывает.
>> да и вообще языку нужны нормальные типы контейнеров
В целом, скорее соглашусь. Только не языку, а стандартной библиотеке языка. К слову, можете даже написать, это быстро.
Навскидку, наивное решение, вот прямо так и будет выглядеть:
```
var ErrLengthExceeded = errors.New("index out of range")
type DynamicArray[T any] struct {
    slice []T
}
func NewDynamicArray[T any](cap int) *DynamicArray[T] {
    return &DynamicArray[T]{
        slice: make([]T, 0, cap),
    }
}
func (da *DynamicArray[T]) Append(values ...T) {
    da.slice = append(da.slice, values...)
}
func (da *DynamicArray[T]) At(index int) (T, error) {
    if len(da.slice) <= index {
        return nil, ErrLengthExceeded
    }
    return da.slice[index], nil
}
```
>> нормальный синтаксис для классов (можно хоть не вводить this)
А вот классов-то в Go и нет... Отсутствие синтаксиса для отсутствующей сущности - нормальный синтаксис, ничего менять не надо.
>> Рефлексии для приватных объектов нет.
А она для чего-то реально нужна?
>> Если написать свой тип данных то вся type safety исчезает.
Вот это неправда. То, чего изначально нет, исчезнуть не может. В Go нет type safety, никогда не было, и даже не декларировалось.
>> В одном его рантайме целый вагон различных моментов где можно словить panic.
Собственно, как и в любом рантайме любого языка...
>> По сути нужно знать дофига моментов почему тут нужно делать не так, а вот здесь nil не nil.
Ну, блин, можно заучить мантру "в слайс (это типа динамический массив такой) значения добавляются неуклюжей конструкцией slice = append(slice, value)", и с этим сокровенным знанием идти работать, нести откровение в мир... А можно, блин, прочитать, что такое слайс в спецификации языка, и вопрос о неуклюжести конструкции отпадет сам собой...

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

75. Скрыто модератором –1 +/–

Сообщение от Аноним (75), 02-Фев-23, 12:33

А то что ссылку на него открыть нельзя в России писать ненужно?
Ни https://go.dev/blog/go1.20
ни https://openwrt.org/
не открываются.
Но в OpenWRT все еще работает ссылка на скачивание
https://downloads.openwrt.org/
Странно что нет указания что такая педерастия имеет место быть и вместо открытия вкладки вас ждет крутой облом.

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

81. Скрыто модератором +2 +/–

Сообщение от Аноним (24), 02-Фев-23, 12:41

Все ссылки открылись завязывай с бухлом.

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

85. Скрыто модератором +1 +/–

Сообщение от leap42 (ok), 02-Фев-23, 13:22

ссылки работают, ТТК
чините свой инет

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

144. Скрыто модератором +/–

Сообщение от Michael Shigorin (ok), 03-Фев-23, 00:34

Аналогично; ростелек.

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

83. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +6 +/–

Сообщение от Старший аноним (?), 02-Фев-23, 13:10

В блоге есть, в статье пропущено:
Начиная с версии  Go 1.21 не будет больше работать на Windows 7,8 и соответствующих им Windows Server 2008, 2012.
За Windows 7 жалко - многие ее еще используют как для домашнего использования, так и для разработки.

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

86. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –2 +/–

Сообщение от leap42 (ok), 02-Фев-23, 13:26

тех кто пишет на Go под Win7 уж точно не жалко xD

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

87. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +2 +/–

Сообщение от Старший аноним (?), 02-Фев-23, 13:38

Конечно, это же не Windows 10 c телеметрией "ис каропки". А чо - стальна, модна, маладежно. Так?

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

88. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от анон (?), 02-Фев-23, 13:49

Телеметрия или 0-day эксплоиты для неподдерживаемой ос, что же выбрать старшему анону в этой непростой ситуации?

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

89. Скрыто модератором +4 +/–

Сообщение от Аноним (-), 02-Фев-23, 13:55

Ты забыл зеродеи для поддерживаемой.

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

94. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от ihatenpm (?), 02-Фев-23, 14:07

И кому нужна эксплутация зеродеев, если там одни неуловимые джо?

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

101. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от анон (?), 02-Фев-23, 14:34

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

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

110. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от Аноним (110), 02-Фев-23, 15:57

Так и писать тогда можно на любом языке безопасность же не нужна.

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

120. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от ihatenpm (?), 02-Фев-23, 18:00

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

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

139. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Neon (??), 02-Фев-23, 21:51

От этого неуловимый джо только станет еще неуловимее.)))

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

114. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от leap42 (ok), 02-Фев-23, 17:06

> Конечно, это же не Windows 10 c телеметрией "ис каропки". А чо
> - стальна, модна, маладежно. Так?
Нет, не так. Я уже 15 лет виндой не пользуюсь. Но вместо 7-ки взял бы 10-ку из-за WSL. Всю телеметрию из 10-ки кстати обновлениям встроили и в 7-ку ЕМНИП.

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

148. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от OpenEcho (?), 03-Фев-23, 03:51

> Но вместо 7-ки взял бы 10-ку из-за WSL
А ты не пробовал WSL пользоваться то взрослому, как на никсах?

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

152. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от leap42 (ok), 03-Фев-23, 04:58

>> Но вместо 7-ки взял бы 10-ку из-за WSL
> А ты не пробовал WSL пользоваться то взрослому, как на никсах?
Нет, я же уже лет 15 виндой не пользуюсь. Но я имел опыт с pussy.exe и попытал бы счастья с WSL.

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

212. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Annonim (?), 14-Фев-23, 19:32

ой https://github.com/golang/go/discussions/58409

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

95. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от ihatenpm (?), 02-Фев-23, 14:08

Я на виртуалке запускаю, когда надо виндо-специфичное, т.к. она легковеснее, и в отличие от 11 не 5 FPS как в анимэ

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

96. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от Аноним (96), 02-Фев-23, 14:16

10 легковесней раз в 100, попробуй тот билд для банкоматов там практически весь мусор изкоробки отключен.

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

119. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от ihatenpm (?), 02-Фев-23, 17:59

Я и так без васяносборок не обхожусь. IoT попробую.

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

122. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (96), 02-Фев-23, 18:15

Я имею в виду не васяносборку. Но МС её не продаёт в ритейле, она оемная. Кмс-активатор с ней работал по-моему, так что апдейты были.

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

97. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от Аноним (97), 02-Фев-23, 14:22

> Подобные загрузки выполняются независимо от выполнения пользователями "go get" и создают большую нагрузку на серверы
Слабо рейтлимитер вкрутить?

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

100. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (100), 02-Фев-23, 14:28

так и вкрутили, в новости об.этом и написали

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

125. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от www2 (??), 02-Фев-23, 18:40

Так это держателям веб-сервиса надо было самим сделать. А так получается, что после этой новости кто угодно сможет чисто ради прикола положить их сайт. Проблема же не ограничивается одним только криво сделанным go.

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

135. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +4 +/–

Сообщение от Аноним (24), 02-Фев-23, 20:07

Т.е. надо сделать как в npm единую помойку, которую условно сложно положить?

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

142. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (100), 02-Фев-23, 22:57

> Так это держателям веб-сервиса надо было самим сделать.
Кстати да, почему-то другие хостинги, включая живущие исключительно на поддержку пользователей, сильно не жалуются. Может быть, ДеВольту стоило лишь порою возвращать на их запросы 304 Not Modified?

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

126. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (126), 02-Фев-23, 18:40

> Проблема была связана с тем, что при выполнении команд, таких как "go get", импорт модулей из внешних репозиториев осуществляется не напрямую...
Так пусть напрямую выполняется, а если указано GO_PROXY импортируется через какой-то прокси, а то выдумали своим инструментом вылавливать пакеты в том числе и из приватных источников. Я щитаю, что если пользователь хотел бы разместить пакет, то он бы взял и разместил, а тту на лицо какое-то толи жульничество, толи развед действия.
Идея язычка пропихнуть в базовые типы slice, map и т.д. напрашивается, но давайте спросим честно, что даст Golang когда эти типы наконец-то IEEE протащит в стандартную stdc библиотеку?
Вообщем какой-то подмножество языка непонятно зачем нужное да еще и с зондами из коропки

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

134. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от Аноним (24), 02-Фев-23, 20:06

Давай по-порядку
1) Go простой
2) Go безопасно работает с памятью
3) Go быстрее питон чего достаточно
Больше ему ничего не надо. Отсутствие гарбеджколлектора это плюс к простоте. Запиши в блокнотик заучивай каждый день.

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

137. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +6 +/–

Сообщение от Вы забыли заполнить поле Name (?), 02-Фев-23, 21:49

> Отсутствие гарбеджколлектора это плюс к простоте
Может присутствие?

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

166. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (24), 03-Фев-23, 11:12

Отсутствие необходимости иметь себе мозги гарбеджколлектором.

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

169. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (169), 03-Фев-23, 18:04

Но ты им себе имеешь, когда привет энтерпрайз и хайлоад с конским RPS. Как-нибудь чекните докладчиков из Wildberries/Avito, как они увлекательно сидят профилируют, чтобы в узких местах писать сервачки в garbage free стиле, чтобы свести к минимуму stop-the-world сборщика мусора и поменьше аллоцировать в куче принципе.

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

149. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от OpenEcho (?), 03-Фев-23, 04:11

> Я щитаю, что если пользователь хотел бы разместить пакет, то он бы взял и разместил, а тту на лицо какое-то толи жульничество, толи развед действия.
"Я не разобрался, но я точно знаю ?!"
proxy пакетов сделан для того, что бы не было чудаков которые удалют пакеты и просят потом бабло у тех кто в зависимостях (привет npm!) а также чтобы быть 3rd verifier контента, что бы от имени авторов не гнали или внедряли дрянь в случае утечек
> Идея язычка пропихнуть в базовые типы slice, map и т.д. напрашивается
Они не пропихивают, Го имеет полностью свою независимую std (стандартную библиотеку) и без проблем обходится без зондированной glibc

> Вообщем какой-то подмножество языка непонятно зачем нужное
:)) А ты смешной! Хоть бы по гитхабу прошвырнулся что бы понять где и кому язык нужен
> да еще и с зондами из коропки
Ну давай, крутизна, ткни носом на зонды.. из коропки

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

154. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от Аноним (154), 03-Фев-23, 07:34

Go хорош. На нем можно писать классные программы вроде VictoriaMetrics

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

155. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +1 +/–

Сообщение от Аноним (155), 03-Фев-23, 08:13

Самого вкусного в новости нет. Теперь можно врапать несколько типов ошибок... И выкинуть наконец-то сторонние библиотеки.

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

164. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от анонимит (?), 03-Фев-23, 10:02

"Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python." и Pascal 🤭 C++ с модулями имеет схожий подход

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

168. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от Аноним (168), 03-Фев-23, 16:56

Go безопасный язык? Угу если не пользоваться библиотеками обёртками над си кодом, в которых тонны gc keepalive. А еще целый вагон не однозначно себя ведущих стандартных функций, прямо как в nim. Зато IDE для него очень шустрые да. В отличие от С++ которые зависят от clangd который тот еще тормоз.

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

179. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." –1 +/–

Сообщение от vadiml (ok), 04-Фев-23, 10:18

> с отдельными заимствованиями из языка Python
Питоном, к счастью, в нём и не пахнет, зато авторы говорили, что "заимстования" из Оберона, который врос из паскаля.

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

186. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от anonbrain (?), 04-Фев-23, 14:24

достаточно бредовый язык. делал сравнения для оценки производительности, так вот он всего в полтора раза быстрее последних версий PHP, но это абсолютная шляпа, учитывая что он вобще то компилируемый. короче на помойку его, используйте C/C++

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

203. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..." +/–

Сообщение от Аноним (169), 05-Фев-23, 15:28

Делать энтерпрайзу нечего, как микросервисы на C++ пилить для задач, которые в I/O упираются, а не вычисления. Go дубовый и прямолинейный, код плоский и очевидный, дебажить просто, но ценой многословности. По совокупной стоимости владения проект на гошке обходится в разы дешевле какой-нибудь джавы или С# или, тем более, С++.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..."	–1 +/–
Сообщение от Аноним (1), 02-Фев-23, 11:04
посмотрим, возможно, на фоне увольнений гугол это последний релиз
Ответить \| Правка \| Наверх \| Cообщить модератору


	19. Скрыто модератором	–2 +/–
	Сообщение от анон (?), 02-Фев-23, 11:31
	Само собой, всем известно что разработка rust прекратилась после того как Mozilla выкинула команду на помойку.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. Скрыто модератором	–1 +/–
	Сообщение от Аноним (24), 02-Фев-23, 11:44
	Так она и прекратилась. Там в каждой новой версии в лучшем случае багфиксы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. Скрыто модератором	+2 +/–
	Сообщение от анон (?), 02-Фев-23, 11:48
	И святой дух релизы делает, а может даже ИИ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. Скрыто модератором	+2 +/–
	Сообщение от Аноним (1), 02-Фев-23, 11:56
	святой дух безопасной работы с памятью
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. Скрыто модератором	+1 +/–
	Сообщение от Аноним (31), 02-Фев-23, 11:49
	Это потому что раст - новый паскаль
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	38. Скрыто модератором	+1 +/–
	Сообщение от НяшМяш (ok), 02-Фев-23, 12:00
	То есть идеальный?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. Скрыто модератором	+4 +/–
	Сообщение от Аноним (1), 02-Фев-23, 12:02
	Да, раст действительно хорош. Не зря же его включили в ядро линукс.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. Скрыто модератором	+1 +/–
	Сообщение от Аноним (1), 02-Фев-23, 12:03
	а го кстати нет
	Ответить \| Правка \| К родителю #38 \| Наверх \| Cообщить модератору


	48. Скрыто модератором	+2 +/–
	Сообщение от Аноним (31), 02-Фев-23, 12:09
	Старый паскаль лучше нового раста
	Ответить \| Правка \| К родителю #38 \| Наверх \| Cообщить модератору


	77. Скрыто модератором	+/–
	Сообщение от Старший аноним (?), 02-Фев-23, 12:37
	Лучшй Pascal - это ADA
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..."	+5 +/–
	Сообщение от RomanCh (ok), 02-Фев-23, 12:18
	А там всю команду уволили, или только массовиков-затейников с развитыми мягонькими навыками и высоким "эмоциональным интеллектом"?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	124. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..."	+1 +/–
	Сообщение от Аноним (124), 02-Фев-23, 18:39
	Руководство Гугла - не эксцентричный Маск, дойную корову никто выгонять не будет. Внутри Гугла слишком много всего завязано на golang. Там люди прагматичные. В первую очередь под нож пойдут розовые пони, набранные ради diversity, экономическая польза от которых отрицательна.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору

3. Скрыто модератором	–1 +/–
Сообщение от Аноним (24), 02-Фев-23, 11:07
Ни слова про безопасную работу с памятью. Хотя Go работает с памятью даже безопаснее чем раст.
Ответить \| Правка \| Наверх \| Cообщить модератору


	40. Скрыто модератором	–6 +/–
	Сообщение от НяшМяш (ok), 02-Фев-23, 12:02
	Язык с указателями безопасен? Всё что нужно знать про экспертизу на опеннете.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. Скрыто модератором	+1 +/–
	Сообщение от Аноним (1), 02-Фев-23, 12:04
	будто мы не знали)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. Скрыто модератором	+/–
	Сообщение от Вечно недовольный аноним (?), 02-Фев-23, 12:26
	А если это умные указатели?
	Ответить \| Правка \| К родителю #40 \| Наверх \| Cообщить модератору


	80. Скрыто модератором	+2 +/–
	Сообщение от Аноним (24), 02-Фев-23, 12:40
	И что в го можно делать арифметические операция или разыменованный указатель не null? По безопаснее чем в расте будет.
	Ответить \| Правка \| К родителю #40 \| Наверх \| Cообщить модератору


	82. Скрыто модератором	+3 +/–
	Сообщение от Аноним (82), 02-Фев-23, 12:58
	Любой язык с GC предлагает безопасную работу с памятью. А особенность раста в том, что он предлагает безопасную работу с памятью без GC.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. Скрыто модератором	+1 +/–
	Сообщение от Placeholder (ok), 02-Фев-23, 12:18
	Языки с gc не считаются, естественно.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору

5. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..."	+/–
Сообщение от Аноним (5), 02-Фев-23, 11:12
Для микроконтроллера можно скомпилировать?
Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..."	+5 +/–
	Сообщение от анон (?), 02-Фев-23, 11:25
	tinygo
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..."	+1 +/–
	Сообщение от RomanCh (ok), 02-Фев-23, 12:19
	> Для микроконтроллера можно скомпилировать? Даже для Lego конструктора можно.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	84. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..."	+1 +/–
	Сообщение от ryoken (ok), 02-Фев-23, 13:14
	>>Даже для Lego конструктора можно. чочо
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Выпуск языка Go 1.20. SourceHut отменил блокировку зеркала м..."	+3 +/–
	Сообщение от RomanCh (ok), 02-Фев-23, 14:26
	>>>Даже для Lego конструктора можно. > чочо https://github.com/ev3go/ev3dev
	Ответить \| Правка \| Наверх \| Cообщить модератору


	183. Скрыто модератором	+/–
	Сообщение от Аноним (-), 04-Фев-23, 13:38
	> чочо Там программируемые кирпичи есть.
	Ответить \| Правка \| К родителю #84 \| Наверх \| Cообщить модератору

18. Скрыто модератором	+/–
Сообщение от Аноним (18), 02-Фев-23, 11:30
Кстати на Go переписано уже пол мира. На расте же до сих пор написано примерно ничего.
Ответить \| Правка \| Наверх \| Cообщить модератору


	23. Скрыто модератором	–4 +/–
	Сообщение от Аноним (1), 02-Фев-23, 11:38
	странный выбор, ведь раст лучше во всём
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. Скрыто модератором	–2 +/–
	Сообщение от Аноним (24), 02-Фев-23, 11:45
	раст худший язык в любой сфере. Для сравнения питон второй лучший язык в любой сфере.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. Скрыто модератором	–1 +/–
	Сообщение от Аноним (31), 02-Фев-23, 11:50
	Но раст же новый паскаль
	Ответить \| Правка \| Наверх \| Cообщить модератору