Сильно понравилось автоматическое выведение типа, не в момент присваивания как в большинстве языков

Не всегда могет сам. Иногда ошибочно выводит

да

когда?

за все время я помог ему всего один раз

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

Например

у меня есть функция

fn query(&self, session: &Session, tpl: &str, data: &HashMap<&str, &str>) -> http::Reply { let now = Utc::now(); let ts = now.with_nanosecond(0).unwrap_or(now); let msg_id = Uuid::new_v4().to_string(); let now = format!("{:?}", ts); let mut ctx:HashMap<&str, &str> = HashMap::new(); ctx.insert("MESSAGE_ID", msg_id.as_ref()); ctx.insert("TIMESTAMP", now.as_ref()); if session.token.len() > 0 { ctx.insert("TOKEN", session.token.as_ref()); } for (key, val) in data { ctx.insert(key, val); } let tmp = tpl::eval(tpl, &ctx); http::post(&self.http_client, &self.uri, &tmp) // ... }

ее вызывают другие - которые передают свой словарь

let mut data = HashMap::new(); data.insert("foo", self.foo.as_ref()); let tpl = include_str!("../../tpl/foo.xml"); let res = self.query(&tmp, tpl, &data);

когда их много код просто не компилится

let mut ctx:HashMap<&str, &str> = HashMap::new();

🤔

пока не дать подсказку

если меняю на let mut ctx = HashMap::new();

не компилится

находит несоотвествие типов - он походу не может корректно привести .as_ref()

"когда их много" это многосмысленно

ну пока вызовов 2 он работает

добавляю 3ый - не хочет

причем порядок добавления не важен

Ну впринципе я на него не в обиде, просто ошибку пишет какуюто что сразу не догадатся в чем причина =)

интересно

ctx.insert("TOKEN", session.token.as_ref()); | ^^^^^^ the trait std::convert::AsRef<&str> is not implemented for std::string::String ... let tmp = tpl::eval(tpl, &ctx); | ^^^^ expected str, found &str

по крайней мере таким нубасам как я =)

Хотя странно

pub fn eval(tpl: &str, data: &HashMap<&str, &str>) -> String {

tpl::eval определен явно

Кстати еще вопрос был

fn foo(x: &mut XType) { ... } fn main { let &mut x = XType::new(); foo(x); }

let mut assistant = link::LinkAssistant::new(db_uri); | ^^^^^^^^^^^^^ | = note: #[warn(unused_mut)] on by default

он не всегда паралелит

А можно пример?

Ибо мне кажется, что с параллелизацией итераторов всё однозначно как раз

Note though that calling join is very different from just spawning two threads in terms of performance. This is because join does not guarantee that the two closures will run in parallel. If all of your CPUs are already busy with other work, Rayon will instead opt to run them sequentially. The call to join is designed to have very low overhead in that case, so that you can safely call it even with very small workloads (as in the example above).

This is because join does not guarantee that the two closures will run in parallel. If all of your CPUs are already busy with other work, Rayon will instead opt to run them sequentially.

Это предложение

А, ну так это правильно

Если ты их распараллелишь, то у тебя производительность просядет из-за необходимости чаще контекст менять

Я ничего не требую, просто отметил что не всегда паралельно

Да, что хорошо

Если в phobos не так, то печально

в D примерно так же

там taskPool

если правильно путаю он может разбить чать тредов одному циклу, часть другому

у D основная проблема это управление памятью

и еще память течет

даже простой helloworld

мне показалось даже в Go получше сборщик мусора

Как победить варнинг?

Кстати еще вопрос был

fn foo(x: &mut XType) { ... } fn main { let &mut x = XType::new(); foo(x); }

let mut assistant = link::LinkAssistant::new(db_uri); | ^^^^^^^^^^^^^ | = note: #[warn(unused_mut)] on by default

let mut assistant = link::LinkAssistant::new(db_uri); | ^^^^^^^^^^^^^ | = note: #[warn(unused_mut)] on by default

Убрать mut?

let mut session = task.link.session_begin(&mut assistant); | ^^^^^^^^^ cannot borrow mutably

Он не ющается в текущем контексте

выше набрасал примерчик - передается в функцию - юзается там

выше набрасал примерчик - передается в функцию - юзается там

Там просто тоже неправильно

&mut надо писать в вызове foo

foo(&mut x)

сори

пропустил

Зачем в Go амперсанд и звёздочка (& и *)? https://habrahabr.ru/post/339192/

Бедные гошники

Запутались

лол

ну на самом деле вопрос корректный

можно было б обойтись и без указателей в языке )

упрощать так упрощать

но надо было отдать дань сишечке

Имя C было выбрано, как следующая буква алфавита после B.

Версионируемость языков по алфавиту

Неплохо неплохо

"В таком же виде указатели вместе со звёздочкой и амперсандом попали и в С++ — ещё один язык мейнстримовый язык, на котором до Go писалась большая часть сетевого и серверного софта."..до го

Ага

вау го заменил с++

http://local.joelonsoftware.com/wiki/%D0%9E%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0%BE%D0%B1%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BD%D0%B0_Java

из комментов ссылка

цитирую Все те юные гении, которые в старших классах школы писали на Бейсике пинг-понг для Apple II, поступают в колледжи, выбирают CompSci 101, курс по структурам данных, и когда сталкиваются с работой с указателями, их мозги просто взрываются, и они решают перевестись на политологию, потому что теперь правовая школа кажется им лучшим выбором. Я много раз видел графики отсеивания студентов с курсов CS, и обычно процент выбывших составляет от 40% до 70%. В университетах склонны считать это разбазариванием; я думаю, что это просто необходимая естественная отбраковка людей, которые просто не смогут быть счастливы или успешны в карьере программиста.

мда..

Счастливые ученики Java-школ никогда не столкнутся с ужасными segfault (прим. пер.: Segmentation Fault — типичная ошибка при обращении по некорректному адресу) при попытках реализовать основанные на указателях хеш-таблицы. Они никогда не будут делать безумных, сумасшедших попыток упаковать что-то в биты. Они никогда не будут загружать свои головы мыслями о том, как в полностью функциональных программах значение переменной никогда не изменяется, и все-таки оно постоянно изменяется! Парадокс!