Представлен релиз языка программирования Go 1.19, который развивается компанией Google при участии сообщества как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57591
Каждый раз, когда плюсы начинали казаться слишком сложными, они хватались, жали кулаки и с криками "Ну, всё! Сейчас напишем свой язык, проще и круче, с форматированием и мусоросборщиками" писали свою очередную жабу. А потом всегда оказывалось, что, проектируя что-то упрощённое, они призывают всё менее адекватных пользователей этого самого. В общем, как кто-то говорил "создаёшь среду для дебилов - не удивляйся что только дебилы и будут ей пользоваться".
1. Полезные фичи одних языков влияют на другие.
И в Си и С++ вносятся изменения. Неспешно.2. Есть задачи, когда "непопулярный язык" может оказаться оптимальным.
При этом оптимальность языка еще не повод для.. Влияет время жизни проекта, пользователи и программисты, которые будут с этим работать, и специфика самой задачи.
3.
>>только дебилы и будут ей пользоватьсяЕсли такая постановка задачи, и за это платят (Те кто будет этим пользоваться), то работа будет выполнена с учетом пожеланий заказчика.
И Go их вносит зачем тогда C++? С++ в вебе не существует, вон Яндекс недавно выпустил единственную поделку и то, которая им самим не нужна.
было бы пофиг на яндэкс, если бы они не лезли в стандарт своими мерзкими ручонками
всю зависит от задач. когда у тебя десятки тысяч серверов на каком-то амазоне, за которые ты платишь десятки тысяч бакинских в месяц и все из-за того, что php/python/java жрет ресурсы и тормозит, вот тогда ты берешь тот же boost beast, переписываешь весь свой бэканд и уменьшаешь затраты на железо в 2-3 раза с пол пинка.
а так да, для бложика на 5 пользователей php решает.
Фейсбук написан на PHP, хотя и модифицированном. Всё зависит от количества серверов. Иной раз их содержание обходится дешевле содержания программистов. А ещё есть такой показатель, как time to market. Он тоже часто решает в пользу отнюдь не производительности ЯП.
> когда у тебя десятки тысяч серверов на каком-то амазонеТо ты либо размером с SalesForce, и всё равно пишешь на Яве, либо давно пора нанимать архитектора, и продолжать писать на Яве. Десятки тысяч серверов в клауде — влажные мечты недалёких «системных» «админисраторов» вручную вылизывающих 3½ сервера и свой локалхост.
>>>только дебилыОни минусуют меня ...
Согласно твоей деградантской логике, все должны пользоваться Vim для написания кода, старыми версиями Blender3D для трёхмерного моделирования, старыми версиями GIMP.
Жаль только, что это так просто не работает.
А вы вообще поняли в чём изменения-то состоят? А то, похоже, не особо. Перескажите своими словами, а мы проверим что вы материал усвоили. А то только турбонаддув в лужу пока что.
Самый лучший, быстрый и безопасный язык ever.
самый худший, медленный и дырявый язык ever
Э, тут мной занято
Медленнее раста
А куда ты так торопишься? Зато код писать быстрее.
> Зато код писать быстрее.Правильно, всегда нужно больше времени оставлять на дебаг очередного NPE.
Vala же!
Не медленнее, не беспокойся.
сортировка вектора/слайса была медленнее в 7 раз, теперь будет в 10
Сортировка вектора/слайса на расте не выражается. Есть ансэйф - это не раст, т. к. ансэйф не обладает заявляемыми свойствами. Например, вот этими:> Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами и учёт времени жизни объектов (области видимости)
Для вас это новость, но в unsafe работают все те же гарантии Rust, как и в safe коде. За временем жизни ссылок продолжает следить borrow checker.
Ты какой-то совсем плохой пропагандист. Тебе стоит повторно пройти подготовку.Во первых, гарантий в ансэйф нет. Простейший пример - две мут ссылки на объект - и всё поломалось.
Во вторых, чекера не существует. Все лайфтаймы пишутся вручную. Если чекер есть - никакие лишние аннотации не нужны.
В третьих, ты умножил на ноль всю методичку. Если разницы никакой нет - ансэйф не нужен совсем. Иди расскажи остальным, тем же писателям стд, что ансэйф ничего не даёт. А то они не в курсе и пихают его через строку.
Ты злой
Это скорее всего попытки увести тему в сторону, попытка спасти того пропагандиста - уж слишком явно он обделался. Нужно как-то прикрыть этот позор, и тут как раз можно съехать на "злой"/"оскорбления"/"опечатки" и так далее. Но то ладно, я отвечу на всякий случай, мало ли чего.С чего вдруг такие выводы? Во первых, то что он пропагандист - уже много раз доказано, в том числе вне опеннета. Тебе не помешало бы обновить методичку, а то назвал пропагандиста пропагандистом и скриптуху скриптухой - и вот ты уже "злой".
Во вторых, люди не любят, когда им врут, особенно так нагло. И в таком случае даже просто послать нахрен балабола - нормально. Это не означает какую-то там злость и прочее.
А теперь пойди, прочитай про unsafe в Rust, что он реально дает, и еще раз зачитай этот свой опус себе перед зеркалом. И не говори потом, что ты "объелся скриптухи" и перепутал ссылки и указатели.
в расте нет ссылок, есть толко указатели (сырые и не сырые) которые ведут себя как ссылки(если мы говорит в сравнение с c++)
В Rust есть ссылки, просто ведут они себя частично как плюсовые ссылки, частично как плюсовые указатели, частично сами по-себе с уникальными для раста свойствами. Мы сейчас говорим именно про Rust, и в терминологии языка ссылка (заимствование) отличается от указателя (сырого). Отождествлять ссылки Rust и C++ - некорректно, потому что совпадение там только в названии и в части свойств.
> Во первых, гарантий в ансэйф нет. Простейший пример - две мут ссылки на объект - и всё поломалось.
fn main() {
let mut x = 5;
unsafe {
let y = &mut x;
let z = &mut x;
*y + *z;
}
}error[E0499]: cannot borrow `x` as mutable more than once at a time
--> src/main.rs:5:17
|
4 | let y = &mut x;
| ------ first mutable borrow occurs here
5 | let z = &mut x;
| ^^^^^^ second mutable borrow occurs here
6 | *y + *z;
| -- first borrow later used herehttps://play.rust-lang.org/?version=stable&mode=debug&editio...
Этот хейтер сдулся. Давайте следующего!
> Сортировка вектора/слайса на расте не выражаетсяПесдешь
fn bubble_sort<T: PartialOrd>(a: &mut [T]) {
for i in 0..a.len()-1 {
for j in (i..a.len()).rev() {
if a[i] < a[j] {
a.swap(i, j);
}
}
}
}
сразу предупреждаю, код гумно, используй итпраторы.
Угу https://xakep.ru/2022/08/03/parsethru/
И что ты за параметр такой волшебный отправишь на бек, что он там хоть что-то сможет сделать, только если ты сам на беке дописал обработку параметров, которые пропустит функция проверки урла, короче бредовую ссылку ты дал. Это даже не SQL-инъекция.
> отправишь на беккуда назад? взад? в зад? обратно? на зад?
Это отстойная уязвимость. Чтобы она работала нужно отправить запрос на сервер который компилили версией 1.17 и старше на внутренний сервер где крутится сервис скомпиленный версией младше 1.17.
Вощем надо еще поискать чудаков которые компилируют свои бинарники разными версиями golang.
> Вощем надо еще поискать чудаков которые компилируют свои бинарники разными версиями golang.Админы локалхоста снова выходят на связь. Вообще говорят, что бывают такие большие компании, где несколько команд разработчиков в разных отделах и иногда так случается, что кто-то обновляется раньше других. Вот для них эта уязвимость и может использоваться.
Актуальная версия голанг - начиная с 1.18 т.к. там появились дженерики. Так что уязвимость очень неактульна, т.к. никто не использует версии младше 1.18 - банально обновленные под дженерики либы не скомпилишь.
> банально обновленные под дженерики либы не скомпилишь.Таких либ подавляющее меньшинство, потому что люди пишущие либы обычно адекватные и оставляют обратную совместимость. В гошке есть условная компиляция, поэтому можно 2 версии в 1 либе раскатывать.
Поэтому повторяю (хотя наверное проще бетонную стенку кулаком пробить, чем опеннет эксперту что-то пояснить) - никто не обновляется на следующий день как выходит новая версия. У нас на работе сервисы не то что на 1.17 есть, а даже на 1.16. Вот теперь у ребят головняк, потому что нельзя просто обновиться и раскатать сервис - для начала нужно обосновать всякому менеджменту и прочим безопасникам задлянафига это надо и может пройти не одна неделя пока одобрят только обновление версии языка после всестороннего тестирования. А ведь есть уже упомянутые библиотеки...
Сочувствую вашим бизнес процессам. Пояснять кому то почему важно использовать версии в которых пофиксили уязвимости это конечно такое себе. Хорошо хоть не на джаве пишете а то там был баг в Log4j и у многих БД утекли в сеть и руткиты стоят невидимые. Тоже наверно долго не могли объяснить безопасникам зачем обновлять версию библиотеки для ведения логов :^)
> Сочувствую вашим бизнес процессам.Крупные конторы они такие. Чувствуешь себя элитной ш***ой - е**т много, но и платят хорошо.
> Хорошо хоть не на джаве пишете а то там был баг в Log4j и у многих БД утекли в сеть и руткиты стоят невидимые.Использовали как-то внешнюю апишку как зависимость - как обычно шефство решило, что проще кому-то другому бабки отвалить, чем сделать самим. В итоге оказалось что у них ещё 8 джава и их ломанули как раз через устаревший на 4 года! логгер. К счастью не прилетело никому из наших девелоперов, к сожалению не прилетело никому из лоббистов этой сами апишки.
Самый худший из компилируемых, получается:
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
Берд какой-то. От "нет дженериков, как мне теперь жить после того как джава навседа мой мозг отформатировала" до "айайай, оказывается нельзя код на разные ОС писать абсолютно платформонезависимым если ты в коде используешь результаты системных вызовов, а под Растом можно (нельзя, но мы притворимся что можно)".
Ты ещё скалу принизь. В любом языке адекватном есть параметрический полиморфизм, либо через дженерики, либо через шаблоны. Потому что DRY через них достигается естественным образом.
лучший язык из всех что я видел, если бы не менеджмент зависимостей
Так не тащи зависимости пиши всё сам.
Тогда можно и на Си остановиться
Справедливо.
Так оно так и есть, берёшь boehm gc и спокойно себе пишешь на си, не прося у хозяина аудиенции, чтобы он издал высочайшую корпоративную указивку по дженерикам, ведь есть препроцессор, который такими делами и занимается, если очень уж не хочется дёргать указатели.И даже госпецифичные штуки уже давно есть на си в пакете портированного с plan9, если это, конечно, особо нужно.
Просто всё, что для этого необходимо - уметь идти своей дорогой, а не быть леммингом. А это трудно, на софтскиллах и копипастинге не уедешь.
> boehm gcа как вызывается free() после выхода из функции?
> берёшь boehm gcКонсервативное г-но. Требует полного неразборчивого сканирования всей памяти, с тем чтобы найти всё что похоже на указатели в выделенные области, чтобы понять, какие из них не надо освобождать. Невозможно перемещать данные, чтобы провести дефрагментацию или чтобы не возиться с освобождением объектов по-одному, а переместить из блока памяти всё что нужно, и освободить блок целиком со всем ненужным. gc в принципе сомнительная штука, но чтобы использовать gc в языке не заточенном под gc, надо вообще без мозгов быть.
А что с ним?
язык - шлак, там из адекватного только менеджер зависимостей
Ну это ты уже про node.js и npm.
нет, это я про go
Go со мной, друг! Я обучу тебя премудростям 1С ...
if err != nil
Когда писал на Go, никогда это не бесило. Наоборот, приятно видеть, что все ошибки обработаны :). Конечно, лучше, когда компилятор (Rust) тебя заставляет обработать, но Go выбрал путь упрощения компилятора и возлагания большего количества обязательств на программиста.
Зато неприятно искать, в каком конкретно месте вылезла эта ошибка. Исключений языку явно не хватает.
В Go есть исключения. И сделанны они именно так, как это должно быть. А не так, как в Java/C#/Python/PHP..., когда варианты результата множества неправильно спроектированных функций отлавливаются через try/catch
А чем лучше? Скоростью?
> А чем лучше? Скоростью?И скоростью, и более наглядной обработкой результата функции
> В Go есть исключения. И сделанны они именно так, как это должно
> быть. А не так, как в Java/C#/Python/PHP..., когда варианты результата множества
> неправильно спроектированных функций отлавливаются через try/catchУ них прямо в FAQ есть раздел "почему в Go нет исключений": https://go.dev/doc/faq#exceptions
Для справки: паника != исключение.
В стандартной библиотеке нет возможности получить stack trace для ошибки (только для паники). Это реализовано сбоку в https://pkg.go.dev/github.com/pkg/errors#hdr-Retrieving_the_... и не будет работать для подобных случаев:
```
var ErrSomethingHappened = errors.New("some error happened")
function someFunc() error {
return ErrSomethingHappened
}
```
А если возвращать ошибки через `return errors.New("something happened")` - то будет невозможно проверить эту ошибку иначе как сравнением текста. Самая жопа с этим - для ошибок, возвращаемых через `fmt.Errorf`, их только в лог выводить.
Вот и получается, что в Go нельзя одновременно:
- определить, что за ошибка;
- получить stack trace этой ошибки;
- сделать вышеуказанное для всех библиотек.
И приходится ползать отладчиком по коду чужих библиотек, разбираясь, откуда эта ошибка вообще вылезла.
Если бы в языке были исключения как в нелюбимыми вами Java/C#/Python/PHP/..., можно было бы увидеть весь stack trace и сразу определить место, где оно было брошено.
А так язык классный и быстрый, да. Но не без недостатков.
>[оверквотинг удален]
> Вот и получается, что в Go нельзя одновременно:
> - определить, что за ошибка;
> - получить stack trace этой ошибки;
> - сделать вышеуказанное для всех библиотек.
> И приходится ползать отладчиком по коду чужих библиотек, разбираясь, откуда эта ошибка
> вообще вылезла.
> Если бы в языке были исключения как в нелюбимыми вами Java/C#/Python/PHP/..., можно
> было бы увидеть весь stack trace и сразу определить место, где
> оно было брошено.
> А так язык классный и быстрый, да. Но не без недостатков.Учитывая, что паника в Go - гораздо более редкое явление, чем исключения в других языках, то я не вижу ничего страшного в том, чтобы найти в коде нкжную строку сообщения. Стектрейс очень нужен именно в тех языках, в которых неудачный результат функции возвращается через исключение
Это ты сам себя убедил, что "так и должно быть". На самом деле go-вно у вас, а не "обработка ошибок"! Исключения потому так резко и обрели популярность, что являются удобным способом обработки: там, где важно - мы словим исключения (причём только нужного типа). А где неважно - мы НЕ ЗАМУСОРИВАЕМ КОД, потому что всё равно ошибку отловят выше. Полная гибкость.
> Это ты сам себя убедил, что "так и должно быть". На самом
> деле go-вно у вас, а не "обработка ошибок"! Исключения потому так
> резко и обрели популярность, что являются удобным способом обработки: там, где
> важно - мы словим исключения (причём только нужного типа). А где
> неважно - мы НЕ ЗАМУСОРИВАЕМ КОД, потому что всё равно ошибку
> отловят выше. Полная гибкость.Вы просто проглотили маркетологическую наживку относительно удобства исключений. Хайп прошел, и современные языки выбросили ваши исключения в мусорное ведро так же, как и многоуровневое ООП-наследования, вместо которого используется простая композиция
Если бы не автоматическая сборка мусора
Я человек простой: вижу слова "выпуск языка программирования" - понимаю, что этот язык умрёт вслед за своей единственной и неповторимой реализацией и никакой gccgo его не спасёт, а потому учу языки, у которых главное - это стандарт, а не реализация сиюминутных хотелок, которые за год поменяют под десять раз кряду туда и обратно.
Действительно, это камент к языку, который выдерживался 30 лет
ты про плюсы? ибо как go без году неделя
Я про go. Нет, не неделя
Откуда ты эти сказки вообще берешь? Не больше 15 лет твоему го от идеи до сегодня. Если создатели что-то и делали это не было языком программирования и к го отношения не имеет. Еще один на голову фанатик.
До Go Пайк создал несколько языков, по которым видно, чего он хотел. Так что история Go довольно глубокая.
блаблабла. го выкатил гугл лет пять назад, это исключительно их (c)(tm), до этого момента его не существовало. можешь бабкам на лавке рассказывать, насколько глубоко оно корнями уходит в язык ассемблера
Многие программисты писали "свой язык".
Делают как и нуля, так и "улучшают" существующие. Второе менее велосипедостроение.
Практической пользы от этих изделий для общего программирования как бы нет.
Но бывает самодельные языки перерастают с средства для спецфических задач, например во встраиваемой технике, или где то в недрах движка трудится свой язык, но пользователю он не виден.
Самые примитивные такие языки были подобны бейсикам, ассемблерам и скриптам. Но по мере роста уровня знаний среднего программиста, языки получаются более навороченными, и изящными. Понравившиеся фичи или наоборот, упрощения заимствуются.Писать на обсуждаемом языке я точно не буду, но для кругозора потискаю.
(Какая универсальная фраза вышла, актуальная почти для всех подобных языков)
Как это нет практической пользы? Надо писать меньше когда, например. И код понятнее. Нифига себе нет пользы. У тебя наверно настолько замылился глаз что ты не видишь очевидного. Или ты считаешь что программисты подкидывают кубик и выбирают будут ли они сегодня писать новый велосипед или нет. Нет это так не работает. Больше того сначала надо найти клиента велосипеда, а потом только его писать (это кстати называется маркетинг почитай прикольная штука)
> маркетинг почитай прикольная штукаНет, спасибо, не нужно. От этого бежать и избавлятся нужно.
Вы писали свой язык?
Использовали? Давно?Вот у меня сейчас используется и развивается во встраиваемых приборах самодельный язык, компилируемый в Си. Упор на малые ресурсы железа, абстрагирование от разношерстной аппаратной части, и упор на работу с сетевыми протоколами,и базами данных, возможность машинной генерации кода, но чтоб читалось. Кстати цель создать язык не ставилась, вначале были библиотеки, потом плюсом скрипты, и уже потом это стало переростать в язык более лаконично общающийся с библиотеками.
ты всё неправильно написал, кругом неправ
На всю жизнь вперед планирование? Выучить один единственный и потом до пенсии на нем писать? Только ой, фреймворк каждый год новый, тулкиты, сборочные системы - жизнь бурлит. И в конце концов, каждые 2 года выходит новый стандарт и все на него мигрируют, чуть попроще, чем на новый язык. Не хватает мозгов на все это - вон из профессии.
Уж лучше новые языки учить, интереснее кодить, проекты не замшелые.
Ага, я так и выбрал жизненный путь - часто менять языки и предметные области. Да, экспертом не стану, зато весело :). Заходил недавно к другу-учёному... сидит 30 лет в одном и том же кабинете :). Ну, тоже жизнь.
У них там еще компы пентиумы и винда хп, зато стабильность.
У го есть стандарт: https://go.dev/doc/go1compat
Хорошая замена Python.
Однозначно.
осталось только терабайтный веник купить для компилятора и второй для зависимостей. и кластер райзенов, чтобы не так лагало
про 128 гигов оперативки забыл. а ещё думаю, чего верхний коммент минусуют
Закрывать каналы и за гороутинами следить надо, и не будет жрать память.
Худший ЯП! Ктати, от Go там тоже что-то было, вроде. :)))))
watch?v=vcFBwt1nu2U
Я так не смеялся оооооочень давно )
Спасибо за видео, добрый человек. Вы, судя по всему, сэкономили мне просто вагон времени. Я то сомнительные артефакты языка коллекционирую, вопросы по форумам задаю, а нужно было просто прочитать про парсинг дат и времени в Go и не связываться с наркоманами.https://www.delftstack.com/howto/go/how-to-parse-date-string.../
Всем тем, кто поставил человеку минус, не посмотрев видос: там не Go называют самым плохим языком, там конструируют самый плохой язык, беря особенности других языков. В том числе и Go
Я назову вашим именем кота!
> Спасибо за видео, добрый человек.На здоровье ) Я сам не очень точно выразился - да, ОНО НЕ ПРО Go.
> Я назову вашим именем кота!
Не надо, кот этого не переживёт! :_D Потому что "Inu" - это "собак" по-японски.
Зашибись, эти придурки заменили quicksort на pdq.
Теперь sort.Slice работает в полтора раза медленнее. Сливает даже самопальному пузырьку.
Попытайся отсортировать что-то большее чем три числа.
А ничего, что мне надо именно три (десять) чисел?
Всем пофиг возьми побольше и отсортируй побыстрее. Делов-то пока не набралось нужное количество не сортируй.
И вот детишки мы смотрим на современных макак.
Отличный совет. Осталось придумать как миллион сортировок 10значного массива превратить в 10 сортировок миллионозначного.Причем, подумал что интовый массив это искусственно, для него простой сорт есть, сделал структуры "type srt struct {i int; w float64}".
1.19 (pdq) тормознее 1.18 (quick) на 20 процентов.
Ссылку кинете?
pdq - это тоже quicksort
https://go.dev/play/p/20tolOaK2Yr
> добавленной в прошлом выпуске поддержки обобщённых функций и типов (дженериков)Так и пишем, превращают в нечитабельное гуано как и ряст.
Гугл сейчас вместо Go выпустит Carbon и вы жестко обломитесь, Майки.
>С целью усиления защиты модуль os/exec теперь не учитывает относительные пути при раскрытии переменной окружения PATH (например, при определении пути для исполняемого файла теперь не проверяется текущий каталогИ эти по наклонной... Вот это то что мне не нравится в линуксе до сих пор. Вот вспоминаю времена portable-приложений под windows.
Странная претензия. Это убирает дыру в безопасности вообще-то.
> С целью усиления защиты модуль os/execПравильный вариант: "переведён в разряд deprecated и будет удалён в следующем релизе".
Официально заявляю Go больше не любимый язык. Carbon единственно верный и лучший язык на все времена.
не слышал ни про один, ни про другой
> не слышал ни про один, ни про другойЗавидую
> Официально заявляю Go больше не любимый язык. Carbon единственно верный и лучший язык на все времена.А как же Rust? Помотросил и бросил?
если человек пишет на го, а потом перебегает на карбор.. о каких раст или c++, или c вы говорите? вы адекватны?
Язык, на котором сразу бери и пиши, без заморочек.
Угу, Go был моим вторым языком, когда выбирал, куда бы свалить с C++. Всегда вспоминаю тепло, очень человеческий язык, даже ошибки дизайна в нём человеческие, понятные :). Первый язык, на который пробовал перейти, Java, в ужасе отринул после нескольких месяцев. Потом был года три Rust, тоже с немалым удовольствием, а теперь изучаю Haskell.
А на работе чем занимаешься?
Пока на Расте пилю околоблокчейновые сервисы (не сам блокчейн, к счастью). Но надоело уже. Хотел уволиться в мае (работать летом - преступление, я стараюсь устраивать себе каникулы месяца на 3 каждый год), но уговорили остаться до запуска в мейннете. Но следующее лето - моё! добью Хаскель, осенью устроюсь куда-нибудь.
при чём тут nim? статья про go. это гугловый вендорлок, почитай в интернете про него
Там не только заморочек нету. Там ещё констант нормальных нету, нет возможности нормально зафорчить процесс, аналогов enum class, за дженерики нужно платить производительностью...Зато можно писать такое var int int = 42 // И эти люди мне запрещают ставить скобочки там, где я хочу
или такое var a, b, c, pi, d = 1, 2, 3.14159, 4, 5
можно в канал отправить nil и покеда!или
type Conteiner struct {
Items map[string]int32
}
func (c *Container) Insert(key string, value int32) {
// c *Container - это тутошний this|self - нахрена ?
c.Items[key] = value
}func main() {
var c Container
c.Insert("number", 42) // покеда!А эти волшебные безтиповые создания переменных - чистый восторг!
response, err := http.Get("http://example.com/")
Что вернул Get ? bool, код, текст ответа, структуру... ? RTFM!
var s1 string = "test1"
var s2 string = "test2"
s1 += s2[0] // к строке нельзя прибавлять то, из чего она состоит. Ведь это так небезопасноvar f32 float32 = 3.14159
var f64 float64 = 31.4159
fmt.Println(f64 + f32) // нельзя ! Водка подорожает!
// а эти волшебные сигнатуры функций, лучше которых только луковый смузи !
func parseLine(line string) (string, bool, string, string, string, bool) {//
for _, value := range(values) {
x := 42 // Ой! здесь это не дешёвая операция на стеке. Здесь это генератор мусора
Я не понимаю как на этом писать так, чтобы трудозатраты были меньше, чем на плюсах.
Дико жалею, что потратил на Go кучу времени. Не повторяйте моих ошибок!
Очень вас понимаю. Все эти замечания как раз из-за того что авторы языка облегчили жизнь себе путём разработки очень простого и тупого компилятора, поэтому нужны "this", float32 нельзя суммировать с float64 и т.п. Разработчик должен заботится об этом.
Лично я не понимаю чем это язык может нравиться?
> поэтому нужны "this"Там нет классов, там структуры. RTFM.
Чуваки набрались опыта в TypeScript и думают что могут теперь всем рассказывать как надо делать.
Иди напиши свой язык "как надо". Благо сейчас есть LLVM и любой школьник это может сделать.
Вы прослушали скулёж сишника столкнувшегося со строгой типизацией. Сишник предпочитает прятать под ковёр автоматические преобразования типов в рантайме, и делать вид, что их нет, и такты процессора на это не тратятся, и что значащие биты не теряются, и вообще он типа кодить умеет, раз преобразований нет.Иди на жс пиши бездарь, тот может string к bool'у преобразовать незаметно.
Я искренне опечален тем фактом, что Вы сосредоточились на нанесении мне эмоционального ущерба вместо того, чтобы пояснить сокровенный смысл столь явного и удручающе назойливого преобразования типов.
Кроме того, судя по эмоциональному накалу вашего сообщения, Вы человек сильно переживающий за этот диковинный язык. Рискну предположить, что Вами накоплен значительный опыт в словесных баталиях в его защиту на просторах интернетов. Не могли бы Вы, с высоты Вашего опыта, прокомментировать и другие, отмеченные мной недостатки, которые я нахожу вопиющими. Заранее благодарен.P.S. Обращения на письме принято выделять запятыми
В том что это тебе не PHP и не JS, это язык со СТРОГОЙ типизацией.
Питон, например - тоже язык со СТРОГОЙ типизацией. Однако в автоматические преобразования типов умеет. Казалось бы, что сложного в приведении f32 к f64 в двадцать первом веке? А поди ж ты, проблема, оказывается.
Я искренне обрадован тем фактом, что мне удалось нанести тебе эмоциональный ущерб, причём настолько, что ты пропустил те объяснения, которые искал.Там всё написано. Соберись тряпка, отвлекись от своих эмоций, и прочитай внимательно.
> Рискну предположить, что Вами накоплен значительный опыт в словесных баталиях в его защиту на просторах интернета
Ты недооцениваешь меня. Я просто накопил опыта интернет баталий. Лет двадцать, то есть больше чем возраст Go.
> Не могли бы Вы, с высоты Вашего опыта, прокомментировать и другие, отмеченные мной недостатки, которые я нахожу вопиющими.
Нет. Весь мой опыт говорит мне, что человек, не владеющий своими эмоциями, не стоит потраченного на него времени. Его можно потроллить, но объяснять ему что-то бесполезная трата времени, потому что как бы он не мнил себя мыслящим рационально, его мышление всё равно рано или поздно будет повержено его эмоциями.
Простите. Я тоже слишком поддался эмоциям поспешил и забыл откомментить главное.> Обращения на письме принято выделять запятыми
Мне наплевать что и кем там принято.
> Там ещё констант нормальных нету,Нет есть:
const FOO = "bar"> за дженерики нужно платить производительностью
Скажи где за дженерики не платят производительностью.
> c.Insert("number", 42) // покеда!
Поставь int вместо int32, и будет тебе счастье. Иначе приводи к типу с помощью int32(42)
> // c *Container - это тутошний this|self - нахрена ?
Затем что это структуры, а не классы. RTFM.
> Что вернул Get ? bool, код, текст ответа, структуру... ? RTFM!
Высосано из пальца. Очевидно что структуру содержащую в себе все данные относящиеся к response.
По вызову http.Get это очевидно.> // к строке нельзя прибавлять то, из чего она состоит.
Ты основы програмирования вообще знаешь? Из чего состоят строки?
> // нельзя ! Водка подорожает!
Нет. float64 априори может быть больше float32. Если допустить операцию о которой ты говоришь, то код будет не очевидным, а это чревато багам (никогда с бухгалтерами не искали копейки? А тут могут быть миллионы). Поэтому либо приводи к нужному типу, либо делай проверки и прочие округления.
> // а эти волшебные сигнатуры функций, лучше которых только луковый смузи !
> func parseLine(line string) (string, bool, string, string, string, bool) {Для этого им нужно прописывать названия. За одно объявляешь переменную.
func parseLine(line string) (foo string, bar bool, some string, some2 string, some3 string, some4 bool)ну и вообще это не айс, пложить столько переменных на выходе. У тебя явно не очень хороший код, мягко говоря.
> for _, value := range(values) {
> x := 42 // Ой! здесь это не дешёвая операция на стеке. Здесь это генератор мусораСинтаксическая ошибка. Чел явно не знает Go (или очень мало опыта) и пытается его критиковать.
> Дико жалею, что потратил на Go кучу времени.
Целый день? Заметно.
Чел, если сделать как ты хочешь, получится жутко багованный, тормозной в компиляции и в рантайме, и в целом не удобный язык.
Go не на пустом месте появился. Его корни идут ещё с 70-х годов и он впитал в себя лушчие решения от своих предшественников.
Справедливо!
Я в целом с вами согласен, но:>> c.Insert("number", 42) // покеда!
> Поставь int вместо int32, и будет тебе счастье. Иначе приводи к типу с помощью int32(42)Счастья всё-таки не будет, т.к. проблема не в 42, которое нетипизированная константа и преобразуется компилятором к нужному типу, а в неинициализированном значении c.Items, которое вызовет assignment to entry in nil map.
Заметно, что автор пытался использовать "Go как C++" ничего практически по нему не читая (ну ведь вроде похожи, а чо такого?). От чего поимел психическую травму и во всём назначил виноватым язык.
Кстати вот это:
> А эти волшебные безтиповые создания переменных - чистый восторг!
Особо доставило. Лично мне это видится одной из удобнейших фич. Тут и шансов промахнуться с типом данных нет (как было бы, в случае неявного приведения типов), и если меняешь тип возвращаемого значения функции, то не надо искать все её вхождения в коде чтобы заменить в 125 местах какой-нибудь int32 на int64. А чтобы знать что вернёт функция, оно вообще-то лучше прочитать документацию, а не попробовать угадать значения по списку определённых для значений возвратов переменных. Но впрочем, тут заметно, что автору поста читать документацию не свойственно.
Роман, этот достопочтенный джентльмен даже не понял суть этой ловушки. А Вы, раскрыв ей, лишили его возможности вырасти как специалисту. Я в печали>> то не надо искать все её вхождения в коде чтобы заменить в 125 местах какой-нибудь int32 на int64.
В том то и печаль, что надо. Иначе вы не знаете на что их кастовать
>> оно вообще-то лучше прочитать документацию,
Ещё лучше, когда код самодокументирующийся
>> Но впрочем, тут заметно, что автору поста читать документацию не свойственно.
Emotional damage! Я опять всю ночь проплачу!
> В том то и печаль, что надо. Иначе вы не знаете на что их кастоватьЭээ... А зачем их кастовать, когда они автоматически правильных типов делаются?
> Ещё лучше, когда код самодокументирующийся
Конечно. Но лично мне самодокументируемость кода нравится больше в виде внятных названий переменных/функций/стилистики и конечно, комментариев. А не на уровне железобетонного вколачивания типов.
По поводу остальных ваших возмущений - ну вот просто согласитесь, что для вас "хорошо == привычно", а то что оказалось непривычно - видится не хорошо. Так никто же не заставляет, надеюсь, использовать то что непривычно/не нравится. Но зачем поливать коричневым то, в чём вам почему-то не хочется/не можется разбираться - мне лично не ясно.
> А зачем их кастовать, когда они автоматически правильных типов делаютсяЭто сишник, они не умеют писать без кастов. Нестрогость типизации и автоматические приведения типов повреждают мягкие ткани головного мозга.
Прошу меня сердечно простить и понять, я думал это очевидные примеры, но вы их даже не поняли :-(Поясняю: фраза нет нормальных констант означает, что вы не можете инициализировать константу, например, результатом выполнения функции. Константу в Go можно инициализировать только другой константой. Это а) практически бесполезно б) при отладке заставляет держать в голове возможность того, что то, что вы хотели, чтобы было константой, поменяется. Это увеличивает трудозатраты (и выглядит убого для 21 века)
>> Скажи где за дженерики не платят производительностью.
в C++, например
>> c.Insert("number", 42) // покеда!
Этот восхитительный пример вы не поняли от слова "вовсе". Там будет паника. Я не буду объяснять почему, просто оставлю вам полный пример. Который вы сможете разобрать на досуге и повысить свой уровень владения языком. Который, к слову, я нахожу весьма скромным.
//-------
package main
type Container struct {
Items map[string]int32
}func (c *Container) Insert(key string, value int32) {
c.Items[key] = value
}func main() {
var c Container
c.Insert("number", 42)
}
//-------
> for _, value := range(values) {
> x := 42 // Ой! здесь это не дешёвая операция на стеке. Здесь это генератор мусора
>> Синтаксическая ошибка. Чел явно не знает Go (или очень мало опыта) и пытается его критиковать.Нет здесь никакой ошибки. Вот полный пример.
values := []int{1, 2, 3, 4}
for _, value := range(values) {
x := value * 2
fmt.Println(x)
}Суть моих претензий была в том, что вместо простого и дешёвого создание локальной переменной на стеке в Go это сложный процесс в недрах системы управления памятью. Это делает невозможной изоляцию переменной без потери производительности. Что увеличивает трудозатраты. Это было моей апелляцией к утверждению "в Go пишем без заморочек"
> Что вернул Get ? bool, код, текст ответа, структуру... ? RTFM!
>> Высосано из пальца. Очевидно что структуру содержащую в себе все данные относящиеся к response.
>> По вызову http.Get это очевидно.Нет, это не очевидно. Вы пишите ReadOnly код, который существенно увеличивает когнитивную нагрузку на программиста. Возможно я привёл не совсем удачный пример с http.Get потому, как пакет популярный. Если у вас действительно есть желание понять меня, то представьте, что у вас есть 2 функции: 1 возвращает [censored], в вторая возвращает [censored] и вам понадобилось ДОРАБОТАТЬ код, чтобы сложить их результаты
v1, err := f1()
v2, err := f2()sumOfV := v1 + v2 // В GO без каста не работает, а на что кастовать из кода не видно
В GO придётся или в исходники лезть, или в документацию, или в многочисленных ошибках компиляции намёки искать
Безтиповое создание переменных это зло само по себе, а в GO оно усугубляется возведённой в абсурд необходимостью кастовать всё и вся.
> // c *Container - это тутошний this|self - нахрена ?Затем что это структуры, а не классы. RTFM.
Явная передача this что в методы классов, что в методы структур это пример плохого дизайна. Тут RTFM не поможет. Они передаются всегда, поэтому это работа компилятора. Всякий раз, когда вы делаете явно бесполезные вещи, которые можно не делать, вы делаете шаг к выгоранию
>> Поэтому либо приводи к нужному типу, либо делай проверки и прочие округления.
Любезнейший, в C++ есть static_cast, dynamic_cast, reinterpret_cast, const_cast, с style cast ... поэтому есть и смысл указывать компилятору как именно преобразовывать типы. Сколько типов кастов есть в GO ?
>> Поэтому либо приводи к нужному типу, либо делай проверки и прочие округления.
Проверки и тут при чём ? Можно сложить две однотипных переменных и получить переполнение
>> Нет. float64 априори может быть больше float32 (никогда с бухгалтерами не искали копейки?
Если вы float'ами считаете деньги, Я ПРОШУ ВАС СЕЙ ЖЕ ЧАС ПОКИНУТЬ ПРОФЕССИЮ!
>> Ты основы програмирования вообще знаешь? Из чего состоят строки?
Наверное, если бы я, как и вы не знал бы основ программирования, мне бы было не так грустно при работа с Go :-(
Мне кажется, на вас надо натравить сишника, который будет предлагать выбросить плюсы в помойку, ибо стреляет исключениями откуда попало в самый неожиданный момент, и вообще непонятно что делает, а ещё синтаксис совсем инопланетянский, и "многочисленные ошибки компиляции" порой выглядят настолько ужасно, что хочется удавиться.PS Если что, я без претензий, я это к тому, как вы выглядите :)
>> Мне кажется, на вас надо натравить сишника, который будет предлагать выбросить плюсы в помойку,Обычно в таких случаях я только учусь.
>> синтаксис совсем инопланетянский,
Синтаксис плюсов мне нравится. Я допускаю, что кому-то он не нравится, но это уже вкусовщина. Мы наврятли убедим друг друга, а перейти к драке у нас, по понятным причинам, нет возможности, поэтому предлагаю оставить этот аргумент.
>> "многочисленные ошибки компиляции" порой выглядят настолько ужасно, что хочется удавиться.
Справедливое замечание. Раньше так и было, но сейчас в C++ появились концепты и сообщения об ошибках становятся читаемыми даже в самых сложных шаблонах.
Я не пытаюсь, как вы изволили заметить, "Использовать Go в стиле C++", я пытаюсь использовать Go так, чтобы трудозатраты были меньше, чем на плюсах. Но у меня не получается. Вот прямо сейчас мне не хватает using namespace и я пишу перед каждой функцией из пакета, название пакета... По утру мне не хватало статических переменных, чтобы инициализировать map при первом вызове функции и я завёл (стыдоба какая) глобальную переменную...
Роман, я не планировал доводить вас до слёз, но в плюсах, чтобы спрятать членов структуры или класса достаточно слова private ! Представляете! Там нету всего этого непотребства с переименованием полей и вынесением структуры в отдельный модуль только чтобы спрятать поля!
> Я допускаю, что кому-то он не нравится, но это уже вкусовщина.Вот об этом и речь. Только вы почему-то допускаете, что у кого-то другого может быть вкусовщина, но не у вас.
> но сейчас в C++ появились концепты ...
Даже если поверить на слово, то хочется отметить - не прошло и полвека :)
> Я не пытаюсь, как вы изволили заметить, "Использовать Go в стиле C++", я пытаюсь использовать Go так, чтобы трудозатраты были меньше, чем на плюсах ...
Да нет, судя по тому, что вы дальше описали, вы именно это и пытаетесь делать, но не можете осознать. Это просто другой язык, с другими концепциями и другим подходом в ряде моментов, которые вы считаете что правильно делать исключительно тем способом, которым вам привычно.
> чтобы спрятать членов структуры или класса достаточно слова private
А почему вы считаете, что это однозначный плюс? Вопрос вооще говоря риторический. Это такая же вкусовщина, как и всё остальное от чего у вас развился нещадный бугурт.
Мой посыл не в том, что плюсы плохие, или Go прекрасный-лучше-не-придумать. И на том и на другом можно писать, как медленно и плохо, так и хорошо и быстро.
Мой посыл в том, что нравится вам инструмент, умеете импользоваться - пользуйтесь им и не пользуйтесь другим, тем что не нравится. К чему это нещадное нытьё? Вас кто заставляет на Go писать? Работадатель? Увольтесь нафиг, найдите другого, ну в самом деле. От нытья на опеннете ваша жизнь точно лучше не станет.
>> А почему вы считаете, что это однозначный плюс?Потому, что это короче, удобней, нагляднее, производительней (вы за меньшее время можете написать больше и лучше)... и не ведёт к выгоранию из-за осознания бесполезности действий
> Это просто другой язык, с другими концепциями и другим подходом в ряде моментов,
Не могу с вами согласиться. Бывают другие концепции и подходы, но принцип развития "от хорошего к лучшему" универсален. И если он не соблюдается, то это однозначно критерий регресса: Если у вас есть нож, а вам предлагают просто заточенный камень, то это нельзя объяснить ни концепцией, ни подходом - это однозначно плохой инструмент.
Оценить качество инструмента проще всего, попробовав его, задавая вопросы, ну, или поспорив по поводу реализации. Обычно в споре рождается истина и только в споре с фанатами Go рождаются фанатские слёзы.
Я не ною и не троллю вас. Ибо изучение языка - это слишком затратный способ троллить. Не находите ? Я задал вопросы по поводу очевидных, поверхностных артефактов языка. В итоге один фанат Go подорвался на мине, заложенной авторами Go, второй загрустил, третий сказал хоть что-то полезное. Ну, такой себе результат.
Похоже верна старая байка о том, что у пацанов была неплохая, в общем то, платформа для выполнения асинхронного кода, а потом Гугл им сделал предложение от которого они не смогли отказаться ибо ипотека, кредиты.. И теперь это тупо scum проект на деньги Гугла к которому синей изолентой прикручивают хоть какие-нибудь фишки.
Наверное я выяснил, что хотел. Не буду вас больше расстраивать
Знаете, похоже единственный человек, с которым вы можете общаться и слышать хоть немного что именно вам говорят - это вы. Что же, удачи с таким плодотворным подходом :)
Ну, ок. Вот вам тогда тоже feedback: Вы часто заменяете рациональные аргументы эмоциональными. Я их слышу, но не реагирую на них. После этого вы добавляете ворох предположений.Я задаю конкретные вопросы по дизайну языка: Зачем вы пишите на порядок больше при худшем результате ? Почему в языке нет конкретных вещей, которые уже давно изобретены и облегчают жизнь ? Что бы делаете вместо этого ? Как сохранить производительность ? Зачем сделали плохо, когда уже есть хорошо. В ответ я получаю: "Ты сишник, ты не понимаешь !" И кучу предположений о том, что меня работодатель заставляет. Написали бы уже просто "Ой, ВсЁ!"
¯\_(ツ)_/¯
> Ну, ок. Вот вам тогда тоже feedback...Постарайтесь сосредоточиться на одной мысли: это вы пришли в тред про этот язык, и стали доказывать всем что ваша точка зрения - единственно верная, а не наоборот. И подумайте, что тут может быть не так.
Вам тут никто ничего не обязан отвечать и доказывать. И ваше право считать, что никто ничего не понимает, один вы в белом пальто стоите красивый. На этом у меня действительно всё :)
По моему, вы проецируете на меня свой способ мышления - в моих вопросах нет эмоциональной составляющей. Ну, или по крайней мере, она там не подразумевается.Я задаю вопросы про Go на форуме (где люди общаются) в теме по Go, где собрались специалисты по Go... Что не так ?
Если я вдруг доказал, что моя точка зрения верная (а двух истин не бывает), ну извините - так совпало.
> не хватает using namespaceimport (
. "fmt"
)
Большое человеческое спасибо!
>> не хватает using namespace
> import (
> . "fmt"
> )Будет очень смешно, когда он попробует например, использовать html/template и text/template одновременно :)
То есть эта шляпа и тут нормально не работает ? Что ж вы меня так в печаль вгоняете то ?
чем дальше, тем стремнее этот си с сахаром сетевых операций.
Народ подскажите, Go уже на раст переписали или нет?
зачем нужен го, когда есть раст?
зачем нужен раст, когда есть с++23?
зачем нужен c++ когда есть с ?
Зачем C, когда можно собрать муравьёв и обучить их как нужно себя вести?
прими Иисуса Христа в своё сердце и тебе не нужны будут муравьи
Странный вопрос. Вообще-то традиционно компиляторы языков программирования пишутся на нём самом.
только через миллион версий, когда язык уже взрослый. и только в случае быстрых языков, иначе компилятор будет безбожно тормозить, как в случае с го
Чушь какая-то.
как и твоё лицо
Враньё. Ты просто никогда не писал собственного языка. Как только у тебя появился полурабочий компиль твоего нового замечательного языка, просто руки чешутся написать компилятор на нём, а не на том убожестве с которого ты бутстрапишься.Плюс как правило к этому моменту ты начинаешь замечать фатальные недостатки написанного кода, и можешь переписать его лучше.
Плюс ещё из самых общих соображений чем раньше ты перейдёшь на свой язык в разработке компилятора, тем меньше переписывать надо будет.
Вот если язык приближаясь к своей первой бетаверсии ещё не переписан на самом себе, то это очень подозрительно. Либо ему его специализация не позволяет писать парсеры, либо задуман тормозом, либо его пишут недостаточно фанаты своего дела.
Дык ведь гугель его фактически признал мертворожденным с анонсом карбота, не?
Карбон это усовершенствованная замена Раста
Карбон - это замена Плюсам, а не Расту
У Гугла какой-то лимит на количество языков, которые он может поддерживать? Как дети, ей-богу.
Спасибо, скачал)