Rust vs C++17 (2 стр)

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

хм. как тут сгенерироват имя функции? как превратить аргумент макроса в строку?

Adler
https://ideone.com/f9qhMF

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

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.