Войти
ФлеймФорумПрограммирование

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

Страницы: 1 2 3 Следующая »
#15
0:32, 11 ноя. 2018

gammaker
> Нет, там ещё есть очень удобные интерфейсы и рефлекшен и всё это грамотно
> используется в стандартной библиотеке.
Угу. Помню, как решил выполнить одно из упражнений - по имплементации, значится, интерфейса Stringer. Так и не асилил. Какой бы String не прописывал - вызывался всё равно дефолтный.
Ну ладно, неосилятор и неосилятор. Однако программа скомпилировалась, запустилась, и при этом ни одного плохого слова мне не сказали! То есть, неочевидный косяк в нотации, заставляющий программу делать не то, что задумано, тут можно сделать с лёгкостью необыкновенной. "А ну-ка его в хрен", - решил я и больше не смотрел в сторону этого подозрительного гуглоизделия.
Немного погодя стали известны леденящие истории о творящихся там ужасах (вроде отсутствия генериков и копипаста/кодогенерации им на замену). Это лишь укрепило мнение о правильности выбора.


#16
2:03, 11 ноя. 2018
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
https://ideone.com/DqccaE

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

#17
3:29, 11 ноя. 2018

Adler
https://ideone.com/f9qhMF

#18
3:34, 11 ноя. 2018

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();
}
foo
bar
https://ideone.com/nZtU8k

круто :)
#19
12:45, 11 ноя. 2018

Sbtrn. Devil
> Помню, как решил выполнить одно из упражнений - по имплементации, значится,
> интерфейса Stringer. Так и не асилил. Какой бы String не прописывал - вызывался
> всё равно дефолтный.
Не знаю, у меня никаких проблем с этим не было. Просто определил метод String у своей структуры и fmt.Print* сразу стал печатать мой тип, используя этот метод. Не знаю, или у тебя была какая-то старая забагованная версия, в чём я сомневаюсь, или ты или вправду не осилил - может тебе не очень и нужно было и ты не был готов сильно глубоко вникать в то, как оно всё работает в Go, ведь принцип работы интерфейсов в Go кардинально отличается от интерфейсов в других языках.
Пока мой опыт работы с Go такой, что там всё сразу работает как надо и без танцев с бубном, что после других языков кажется каким-то невероятным волшебством.

Sbtrn. Devil
> вроде отсутствия генериков и копипаста/кодогенерации им на замену
Так по сути интерфейсы в Go и есть что-то аналогичное генерикам по функционалу. Если нужно сделать что-то сильно критичное к производительности, то кодогенерация конечно будет быстрее. Но в Go она хорошо развита, там есть встроенные средства для парсинга кода, в отличие от C++, который замучаешься парсить с его хедерами и препроцессором.

#20
16:13, 11 ноя. 2018

я пытался в раст, но ниасилил. Мне просто сразу нужно было с си-строками работать для opengl, что-то пришлось все костылить, подстветки для opengl функций не было почему-то и вообще у меня бомбануло и я решил подождать годик-два, пока язык инструментарием не обрастет посильнее. Ибо после Qt где справка на F1 из среды вызывалась с поиском выделенного объекта, то у раста все печальнее.

#21
13:08, 13 ноя. 2018

Плохому танцору ноги мешают

Не надо обсуждать инструменты, надо ставить перед собой задачи и решать их

Что хуже/лучше - чистая субъективщина, используйте то, что нравится (ну а если на работе весь код уже на чем-то завязан - то у вас банально нет выбора)

#22
23:23, 13 ноя. 2018

gammaker

Go is a great language when you're working with incompetent people. It's so limiting in the abstractions you can build with it, that it is very difficult to write code that is not immediately obvious in its purpose. Go is easy to teach, easy to review, and it's so syntactically deficient and the tooling is good enough that it's hard to bikeshed. This ultimately improves the experience of writing code at work, and its static type system makes it easier to reason about large code bases for the folks who are used to using Ruby and Python at scale.

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.

#23
2:05, 14 ноя. 2018

Saitei
Тяга к халяве вечна: а давайте дешевых студентов посадим на Go и пусть напишут нам быдло-микро-сервисы задешево.
Странно что люди ведутся, ведь пойдут 90% из них подметать улицы когда эти сервисы напишут.

#24
8:21, 14 ноя. 2018

gamedevfor
> Странно что люди ведутся, ведь пойдут 90% из них подметать улицы когда эти сервисы напишут.
  А ты предлагаешь затягивать выполнение работы, потому что боишься оказаться ненужным после того, как она будет завершена?

#25
8:36, 14 ноя. 2018

gamedevfor
Zefick
лично я считаю что нужно делом заниматься, а не нафапывать на языки и устраивать холивары

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

критерии отбора "лучшего языка" у каждого свои, причем они меняются с течением времени. Не надо смотреть на других, надо просто брать и пробовать, а потом думать своей головой и решать что лучше (и в каких случаях)

#26
9:41, 14 ноя. 2018

*Lain*
У нас в проекте особо абстракции и не нужны, и вряд ли там вообще будет больше 150-200 КБ кода. Зато нужна кросскомпиляция под ARM/Linux, которая в Go просто работает из коробки даже из винды.
А вот клиент будет выполняться в браузере и основную часть кода будет содержать он. Но в браузере с языками особо выбора нет, поэтому там наверное будет TypeScript.

Единственное, что мне пока не понравилось в Go - это производительность записи бинарных файлов. Если я хочу записать массив интов на 100 МБ в файл, нужно использовать binary.Write, который внутри себя выделит ещё один массив байт на 100 МБ, циклом разложит туда инты, и только затем запишет всё это в файл. Это тормозно, потребляет лишнюю память и нагружает сборщик мусора. По идее через unsafe можно скастить один слайс в другой, но у меня что-то сломалось, когда я попробовал так сделать. Возможно, я unsafe'ом каким-то образом сломал модель памяти, работающую в Go. Надо дебажить.

#27
11:27, 14 ноя. 2018

gammaker
> Если я хочу записать массив интов на 100 МБ в файл, нужно использовать
> binary.Write, который внутри себя выделит ещё один массив байт на 100 МБ,
> циклом разложит туда инты, и только затем запишет всё это в файл.

O_o. Почему там так сделано?!

#28
12:47, 14 ноя. 2018

gammaker
> А вот клиент будет выполняться в браузере и основную часть кода будет содержать
> он. Но в браузере с языками особо выбора нет, поэтому там наверное будет
> TypeScript.
можно собирать С++ и Rust для браузера используя emscripten/WebAssembly

#29
13:19, 14 ноя. 2018

Adler
> можно собирать С++ и Rust для браузера используя emscripten/WebAssembly
  Лучше уж TypeScript.

Страницы: 1 2 3 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.