Nim 0.17.0

Жду когда уже наконец запилят non lexical borrow scopes.

Тут соглашусь, все ждут. Просто претензия выше про «порядок объявления» мне кажется странной и надуманной, а ведь тоже для некоторых это «противоречит здравому смыслу».

Ну и конктретно для мапы есть (нестабильные) костыли в виде get_or_insert.

Вместо этого приходится писать такой ужос:

*map.entry(key.to_owned()).or_insert(0) += 1;

В твоем коде лишний malloc лишний memcpy и лишний free.

В rust это unsafe.

А что это меняет? В чем разница между

let abc: [u8; 1024] = unsafe { std::mem::uninitialized() };

let abc: [u8; 1024] = undefined;

В обоих случаях есть ключевое слово по которому можно сделать grep, в обоих случаях переменная abc is poisoned и требует особого обращения в остальном коде.

В rust можно запретить unsafe.

recap:

undefined не нужен

undefined нужен

undefined это unsafe

и что

можно запретить unsafe

На что последует вопрос зачем запрещать нужную вещь? ну и, если очень хочется, что помешает запретить его в zig?

По-моему путь ввода хитрых правил компиляции в принципе не приведет к созданию того самого умного компилятора, который мы хотим получить. Надо с самого начала закладывать ИИ подход, при котором все умные соображения по поводу корректности кода высказывает ассистант на подобии pvs studio отдельно от области синтаксиса языка. Иначе мы просто потонем в примерах кода, который реально корректен, но не компилится и запаримся под них править язык. Мне например реально нравится, когда в котлине внутри if (o != null) уже не требуется проверять o на null. Но тем не менее если проверяется не локальная переменная, то фокус уже не проходит по причине того, что другой поток может поменять ее значение. Но если моя прога однопоточная, то нафига мне такая предосторожность? Как ее выключить? Приходится фигачить val o = a.o; if (o != null) и терпеть.

что помешает запретить его в zig?

Как запретят - тогда и будет разговор.

К примеру создать что-то типа финализатора. Он будет вывываться перед деструктором. И уже в него заталкивать всякие println. А деструкторы создавать силами компилятора.

В некоторых случаях требуется писать две строки вместо одной. Я даже не знаю будут ли это чинить.

Не только в расте так и это нормально. Раст тут просто не даёт в ногу выстрелить, на каком-нибудь С++ оно бы просто упало.

Всё зависит от того насколько разработчики языка стремятся уменшить количество работы требуемой от программистов.

Тут соглашусь, все ждут. Просто претензия выше про «порядок объявления» мне кажется странной и надуманной, а ведь тоже для некоторых это «противоречит здравому смыслу».

Всё зависит от философии. Для кого-то и постоянные требования плюсов быть осторожным нормальны. Имхо же это нечто из разряда обязательного объявлени функции и отедльной её реализации в плюсах. Можно конечно же и не объявлять отдельно, но тогда в функции что выше нельзя вызвать функцию что ниже.

К примеру создать что-то типа финализатора.

И это не как не решит проблему порядка вызовов. Обращение к обьекту который был финализирован но еще не был уничтожен все равно будет логической ошибкой.

уменшить количество работы требуемой от программистов.

Я не вижу тут никакой лишней работы, от того что ты переставишь две строчки местами количество кода не поменяется.

А если уж очень хочется такой порядок, то его можно задать вручную:

fn main() {
    let msg;
    let mut vec = vec![];
    msg = Some("wrong");
    vec.push(&msg);
}

Всё зависит от того насколько разработчики языка стремятся уменшить количество работы требуемой от программистов.

Дык, если не хочется о памяти думать - бери язык с GC и вперёд. Если же это, по каким-то причинам не подходит, то с «дополнительными усилиями» придётся мириться. И как по мне, лучше правила будут единообразными, а не так, что строчки надо тасовать местами в зависимости от того есть ли обращение к мусору или нет. В конце-концов, это вполне логично для языков с «ручным» управлением памятью.

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

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

много ли языков защитят от случайного разыменовывания null?

Kotlin, Swift

Раньше этот язык назывался nimrod. Нимрод-урод :-(

Я только читал об этом.

Kotlin

https://habrahabr.ru/post/322256/

public class jHelper {
  public static jHelper jF() { return null; }
  public void M() {}
}

fun F() {
  val a = jHelper.jF()
  a.M()  //Упс!
}

Swift

https://habrahabr.ru/post/312942/

Swift 3 больше не позволяет разработчикам устанавливать параметры функции, как переменные, поскольку разработчики Swift могут запутаться между var и inout. Таким образом, последняя версия Swift просто удаляет var из параметров функции.

Да, вроде как они справляются с null, но вот с остальным как-то не очень.

Пишем программу на джаве, линкуем ее с котлином, оно падает, следовательно котлин плохой :)

Так же можно сказать что и в расте есть сегфолты, потому что можно же слинковаться с сишной библиотекой которая попортит память.

Пишем программу на джаве, линкуем ее с котлином, оно падает, следовательно котлин плохой :)

Ну а где обещанная проверка на null?

Так же можно сказать что и в расте есть сегфолты, потому что можно же слинковаться с сишной библиотекой которая попортит память.

Где в примере выше java портит память?

Ну а где обещанная проверка на null? Где в примере выше java портит память?

В коде на java не стоит аннотация @Nullable, поэтому котлин ничего не знает об этом типе, будет там null или нет.

Раньше в котлине (еще до релиза) все типы о которых ничего не известно помечались как «могут быть null» однако на практике в подавляющем большинстве случаев null там не будет, и человек поставит восклицательный знак. Это во первых​ не удобно, а во вторых ведет к ошибкам, потому что когда весь код увешан знаками !!, глаз замыливается и легко поставить их туда где не нужно. Поэтому приняли что для всех непомеченных типов восклицательный знак ставится автоматически.

В коде на java не стоит аннотация @Nullable

Я с явой не очень знаком, там за это по рукам бьют?

поэтому котлин ничего не знает об этом типе

Когда ответственным за твой код становится постаронним, то становится очень не весело. Я уже сталкивался в c# с несколько похожим поведением. Можно на это убить несколько дней, если не принимать обет аскетизма и не делать абсолютно всё руками. Вот забавно: столь высокоуровневые языки, а за тебя никто то ли не десериализует(ошибки в рантайме? зачем?), то ли null возникнет там где не надо.

Раньше в котлине (еще до релиза) все типы о которых ничего не известно помечались как «могут быть null» однако на практике в подавляющем большинстве случаев null там не будет, и человек поставит восклицательный знак

А почему к примеру нельзя было взять и просмотреть байткод? Разве это не ответит на вопрос?

Можно пример компилируемого языка с gc способного находить к примеру проблемы с многопоточностью и вменяемым синтаксисом?

Примеры уже привели, но тебе не кажется, что много хочешь? Если хочется добавить какую-то «фундаментальную фичу», то чем-то жертвовать придётся.

Кстати, в плане синтаксиса у раста выиграть как раз не особо сложно: всё-таки лайфтаймы добавляют дополнительный шум.

но тебе не кажется, что много хочешь?

И где тут многое? Меня скорее поражает как некоторые до сих пор согласны принять обет аскетизма, исползуя к примеру c99(хотя некоторые емнип даже 89 берут).

Если хочется добавить какую-то «фундаментальную фичу», то чем-то жертвовать придётся.

Удивительно как мало разнаообразия. Ну есть несколько интерпретируемых с разным синтаксисом. Из-за своей природы они содержат одинаковые проблемы. Есть несколько компилируемых. Но разница между ними не столь велика.

И где тут многое?

Ну как где: если всё было бы так просто, то языков удовлетворяющим твоим требованиям было бы полно.

если всё было бы так просто, то языков удовлетворяющим твоим требованиям было бы полно.

Я достаточно часто слышал про то что совершенно не нужно писать качественный софт, лучше сделать быстрее. То кто-то боится что какие-то проверки затормозят софт, то кто-то хронически не укладывается в сроки. Есть ещё поделки энтузиастов, но они крайне редко извесны и достаточно готовы.

Кстати, в ГО же переменные автоиниуиалищируются значениями по умолчанию для типов. Но я не помню как это себя ведёт с указателями и объектами

Раз семь перечитал пока понял о чём речь. Го слишком примитивен. Одно отсутствие обобщений чего только стоит.

Кстати, в ГО же переменные автоиниуиалищируются значениями по умолчанию для типов

В D тоже.

Я достаточно часто слышал про то что совершенно не нужно писать качественный софт, лучше сделать быстрее.

Где-то это действительно так, но спрос на качество тоже есть. В любом случае, о продуктивности программиста думают даже в низкоуровневых языках типа раста или С++. Если был бы язык, который одновременно давал хорошие гарантии безопасности, предотвращал случайные ошибки и при этом обеспечивал хорошую продуктивность работы, то он был бы очень даже востребован, но чудес не случается.

В любом случае, о продуктивности программиста думают даже в низкоуровневых языках типа раста или С++.

Побыстрее понабирать кучу строк? Я уже не раз спрашивал про то, зачем c++ vector требует итератор на удаляемый объект, а не просто его номер.

Где-то это действительно так, но спрос на качество тоже есть.

За качество надо платить. А эффективные менеджеры есть повсюду.

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

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

Я уже не раз спрашивал про то, зачем c++ vector требует итератор на удаляемый объект, а не просто его номер

Спрашивал у кого? У анонимных экспертов на лоре? Да, я ничем не лучше их, но есть способы предложить улучшение комитету.

Моё мнение: с содержимым плюсовых контейнеров, зачастую, работа и так идёт через итераторы. Ситуации типа «удалить 10 элемент» возникают довольно редко, чаще приходится искать элемент или обходить вектор - в этом случае проблем нет. Ну и всегда можно написать begin() + index, хотя это чуть-чуть менее удобно, да.

В любом случае, я не понимаю, что это должно доказывать? Ты же не будешь отрицать, что эргономика слегка улучшилась в новых стандартах?

За качество надо платить. А эффективные менеджеры есть повсюду.

Ты сейчас говоришь лозунгами ничуть не хуже этих самых «эффективных менеджеров». Могу только повторить, что есть места, где за качество платить готовы.

Теперь почитай на лоре обсуждение очередного языка.

Читаю регулярно. Собственно, именно это мне на лоре и интересно. Ну да, критика бывает неадекватной, но «это нормально» и даже неплохо. В «реальной жизни» большинству будет просто пофиг (и это тоже нормально). В конце концов, новые языки имеют менее развитую инфраструктуру и это тоже важно.

Насчёт петпроектов - так у множества людей их нет. И в этом тоже нет ничего ужасного.

Ну и раст какую-никакую популярность набрал. Собственно, я на нём за деньги пишу.

но есть способы предложить улучшение комитету.

Комитет существует не первый день, но им либо никто этого не сказал, либо они не одобрили.

Спрашивал у кого? У анонимных экспертов на лоре?

В некоторых темах есть знающие люди, дающие внятные советы. В нескольких случаях мне помогли.

Ну и всегда можно написать begin() + index

Вот примерно так большинство и рассуждает. Это не проблема, ведь всегда можно сделать...

В конце концов, новые языки имеют менее развитую инфраструктуру и это тоже важно.

Только вод инфраструктура просто так не появится. Куда интереснее очередной конфиг vim'а сделать

В некоторых темах есть знающие люди, дающие внятные советы.

Безусловно. Но что-то мне подсказывает, что на вопрос «почему так сделано?» может быть сложно дать ответ даже членам комитета. Всё-таки народу там дофига, а предложений/обсуждений ещё больше. Что-то Страуструп расписывает в своих книгах, но сомневаюсь, что дело доходит до таких мелочей.

но им либо никто этого не сказал, либо они не одобрили.

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

Только вод инфраструктура просто так не появится.

Да, есть такая проблема. А что делать? Если все программы бросаться переписываться на каждый новый «перспективный» язык, то мы далеко не ушли бы.

Если все программы бросаться переписываться на каждый новый «перспективный» язык, то мы далеко не ушли бы.

И чем новый c++ в моей редакции будет отличаться от «нового перспективного» языка?

И чем новый c++ в моей редакции будет отличаться от «нового перспективного» языка?

Вопрос не понятен. Что такое «новый С++ в твоей редакции»?

Если говорить про новые стандарты языка, то разница в том, что совместимость имеется. Причём как на уровне кода, так и на уровне знаний. И далеко не каждый проект бросаются обновлять под новый стандарт. Хорошо если какой-нибудь clang-modernize прогонят.

Что такое «новый С++ в твоей редакции»?

С добавлением кода по моим вкусам.

И далеко не каждый проект бросаются обновлять под новый стандарт.

И скорее всего его мои нововведения никак не затронут. Как писали раньше так и будут.

Если честно, то не понимаю, что ты пытаешься донести.