gammaker
> Нет, там ещё есть очень удобные интерфейсы и рефлекшен и всё это грамотно
> используется в стандартной библиотеке.
Угу. Помню, как решил выполнить одно из упражнений - по имплементации, значится, интерфейса Stringer. Так и не асилил. Какой бы String не прописывал - вызывался всё равно дефолтный.
Ну ладно, неосилятор и неосилятор. Однако программа скомпилировалась, запустилась, и при этом ни одного плохого слова мне не сказали! То есть, неочевидный косяк в нотации, заставляющий программу делать не то, что задумано, тут можно сделать с лёгкостью необыкновенной. "А ну-ка его в хрен", - решил я и больше не смотрел в сторону этого подозрительного гуглоизделия.
Немного погодя стали известны леденящие истории о творящихся там ужасах (вроде отсутствия генериков и копипаста/кодогенерации им на замену). Это лишь укрепило мнение о правильности выбора.
use std::io::stdin; use std::io::BufRead; use std::io::BufReader; macro_rules! log { ($foo:expr)=>{ fn $foo( ){println!( "123");} }; } fn main( ) { log!( foo); foo( ); }
error: expected identifier, found `foo` --> prog.rs:7:16 | 7 | fn $foo(){println!( "123");} | ^^^^ error: aborting due to previous error
хм. как тут сгенерироват имя функции? как превратить аргумент макроса в строку?
Delfigamer
>https://ideone.com/f9qhMF
>($foo:ident)
спасибо
use std::io::stdin; use std::io::BufRead; use std::io::BufReader; macro_rules! log { ($foo:ident)=>{ fn $foo( ){println!( stringify!( $foo));} }; } fn main( ) { log!( foo); log!( bar); foo( ); bar( ); }
Sbtrn. Devil
> Помню, как решил выполнить одно из упражнений - по имплементации, значится,
> интерфейса Stringer. Так и не асилил. Какой бы String не прописывал - вызывался
> всё равно дефолтный.
Не знаю, у меня никаких проблем с этим не было. Просто определил метод String у своей структуры и fmt.Print* сразу стал печатать мой тип, используя этот метод. Не знаю, или у тебя была какая-то старая забагованная версия, в чём я сомневаюсь, или ты или вправду не осилил - может тебе не очень и нужно было и ты не был готов сильно глубоко вникать в то, как оно всё работает в Go, ведь принцип работы интерфейсов в Go кардинально отличается от интерфейсов в других языках.
Пока мой опыт работы с Go такой, что там всё сразу работает как надо и без танцев с бубном, что после других языков кажется каким-то невероятным волшебством.
Sbtrn. Devil
> вроде отсутствия генериков и копипаста/кодогенерации им на замену
Так по сути интерфейсы в Go и есть что-то аналогичное генерикам по функционалу. Если нужно сделать что-то сильно критичное к производительности, то кодогенерация конечно будет быстрее. Но в Go она хорошо развита, там есть встроенные средства для парсинга кода, в отличие от C++, который замучаешься парсить с его хедерами и препроцессором.
я пытался в раст, но ниасилил. Мне просто сразу нужно было с си-строками работать для opengl, что-то пришлось все костылить, подстветки для opengl функций не было почему-то и вообще у меня бомбануло и я решил подождать годик-два, пока язык инструментарием не обрастет посильнее. Ибо после Qt где справка на F1 из среды вызывалась с поиском выделенного объекта, то у раста все печальнее.
Плохому танцору ноги мешают
Не надо обсуждать инструменты, надо ставить перед собой задачи и решать их
Что хуже/лучше - чистая субъективщина, используйте то, что нравится (ну а если на работе весь код уже на чем-то завязан - то у вас банально нет выбора)
gammaker
But Go is also awful in so many ways, its such an obvious step backwards in its design and the community is so dogmatic about Go and the Go authors.
On large code bases you almost invariably end up working around the deficiencies with the empty interface, code gen tools that add non standard syntax, and lots, and lots of copying code and code patterns over and over again. Any common pattern you see emerge, that you'd like to create a generic structure for, is probably impossible to encode without type variables. Go also notoriously pushes many errors that would have been caught at compile team to runtime because of its weak type system. With Sum types, it's difficult to make improper states illegal, and default values lead to subtle bugs because they essentially behave as predictable garbage.
Go honestly keeps me from having faith in software engineering as a craft. It's the acceptable of the status quo, or worse, moving backwards in order to fit the needs of the lowest common denominator.
Saitei
Тяга к халяве вечна: а давайте дешевых студентов посадим на Go и пусть напишут нам быдло-микро-сервисы задешево.
Странно что люди ведутся, ведь пойдут 90% из них подметать улицы когда эти сервисы напишут.
gamedevfor
> Странно что люди ведутся, ведь пойдут 90% из них подметать улицы когда эти сервисы напишут.
А ты предлагаешь затягивать выполнение работы, потому что боишься оказаться ненужным после того, как она будет завершена?
gamedevfor
Zefick
лично я считаю что нужно делом заниматься, а не нафапывать на языки и устраивать холивары
да, для общего развития полезно периодически ковыряться в различных языках. Но конечный результат какой? Приложение. Потребителю плевать на чем и насколько изящно приложение написано
критерии отбора "лучшего языка" у каждого свои, причем они меняются с течением времени. Не надо смотреть на других, надо просто брать и пробовать, а потом думать своей головой и решать что лучше (и в каких случаях)
*Lain*
У нас в проекте особо абстракции и не нужны, и вряд ли там вообще будет больше 150-200 КБ кода. Зато нужна кросскомпиляция под ARM/Linux, которая в Go просто работает из коробки даже из винды.
А вот клиент будет выполняться в браузере и основную часть кода будет содержать он. Но в браузере с языками особо выбора нет, поэтому там наверное будет TypeScript.
Единственное, что мне пока не понравилось в Go - это производительность записи бинарных файлов. Если я хочу записать массив интов на 100 МБ в файл, нужно использовать binary.Write, который внутри себя выделит ещё один массив байт на 100 МБ, циклом разложит туда инты, и только затем запишет всё это в файл. Это тормозно, потребляет лишнюю память и нагружает сборщик мусора. По идее через unsafe можно скастить один слайс в другой, но у меня что-то сломалось, когда я попробовал так сделать. Возможно, я unsafe'ом каким-то образом сломал модель памяти, работающую в Go. Надо дебажить.
gammaker
> Если я хочу записать массив интов на 100 МБ в файл, нужно использовать
> binary.Write, который внутри себя выделит ещё один массив байт на 100 МБ,
> циклом разложит туда инты, и только затем запишет всё это в файл.
O_o. Почему там так сделано?!
gammaker
> А вот клиент будет выполняться в браузере и основную часть кода будет содержать
> он. Но в браузере с языками особо выбора нет, поэтому там наверное будет
> TypeScript.
можно собирать С++ и Rust для браузера используя emscripten/WebAssembly
Adler
> можно собирать С++ и Rust для браузера используя emscripten/WebAssembly
Лучше уж TypeScript.
Тема в архиве.