Nim 0.17.0

Нужно сделать ещё больше никому не нужных языков, так победимЪ!

Пожалуй надо будет присмотреться к решениям языка. Сравню с rust-ом.

никому не нужных языков

Почему никому не нужных ? Мне например нужен :)

Ты уже написал на нём что-то кроме Hello world?

Или просто радуешься возможности разбавить свою жалкую никчемную серую жизнь и побыть причастным хоть к какой-то деятельности — в данном случае к ретрансляции влажных фантазий очередных стартаперов («наш йезык самый крутой и скоро весь софт перепишут на нём!»), как фонаты Маска?

А что написал ты о аноним чтоб судить других?

Много чего, но тебе не покажу! 😜

потому что автор не умеет в llvm

Я привел zig просто как пример языка с интересной фишкой. Использовать его наверное не получится, он еще более не готов чем nim. Там всего один разработчик и делает он его просто ради интереса. В то время как раст уже ready for production.

В то время как раст уже ready for production.

О как! А production то ... is it ready for Rust? Oh, sh*** :-)

надо бы проверить — в последний раз я на него смотрел почти год назад и много чего не работало

Больше языков с GC богу языков с GC

Что плохого в копипастах с опеннета?

Затрудняюсь ответить, скорее всего разные. Есть общие черты между Nim и vala, оба языка генерируют код на других языках.

А когла vala успели похоронить? Вроде меньше месяца назад релиз выходил.

Ошибся, Хорошо, еще не похоронили, просто Vala не взлетел.

https://www.bassi.io/articles/2017/02/13/on-vala/

https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Vala-Bassi

Ответ выше написал.

Вот две интересные ссылки https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/

https://nim-lang.org/blog/2017/05/25/faster-command-line-tools-in-nim.html

Карман Ватаныч, залогиньтесь.

И расскажите пожалуйста, почему вы, такой записной потреот, живете в Гонконге,а не в богоспасаемой?

Что в Crystal впечатляющего?

Он же компилируемый руби. Этим всё сказано.

Похоронить.

Он же компилируемый руби. Этим всё сказано.

Емнип гемы из руби просто так к нему не прикрутить. Что там ещё от руби осталось? Синтаксический сахар?

Больше языков с GC богу языков с GC

Ты так пишешь, будто бывают вменяемые языки без GC.

То что ты о них не знаешь, не значит что они не существуют.

Смотря что считать вменяемостью. Если к примеру вспомнить что в расте важен порядок объявления переменных...

Что этот язык позволяет сделать, чего не позволяет C++?

Приведи пример.

Деструкторы вызываются в порядке противоположном объявлению. То есть нельзя положить в вектор ссылку на то что создано после вектора.

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

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

GC в сабже вообще-то отключается. Примерно как в D, т.е. чисто теоретически можно писать без, чисто практически слишком многое в std завязанно на GC.

zig

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

Я уже давал ссылку http://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-...

Мне понравилось как реализованы generics, и switch по типам, помоему красиво получилось.

Хорошо, а что ты предлагаешь, заставить компилятор угадывать drop order? Добавляешь какую-нибудь отладочную переменную, и у тебя вдруг файлы начинают закрываться в обратном порядке, вот здорово получится.

Хорошо, а что ты предлагаешь

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

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

В смысле std::fs::File? Если файлы закрываются неявно, не вижу проблем в том что порядок может отличаться.

В данном случае не вижу ничего плохого если некоторое время в vec будет мусор.

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

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

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

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

А если это будет не Vec, а какой нибудь пользовательский контейнер?

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

невозможно сказать будет он пользоваться этим указателем в деструкторе или не будет.

Как я понимаю текущие правила не позволяют создавать висячий указатель ни на мгновение. В случае с тем вторым случаем висячий указатель будет существовать между уничтожением msg и уничтожением vec. Что плохого в его существовании если им никто не будет пользоваться? Утиная безопасность же.

Ничего. Я поэтому и иронизировал.

Что плохого в его существовании если им никто не будет пользоваться?

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

Если вектор находится в той же области видимости то проблем не будет. если вектор находится над добавлением объекта

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

Смотри, вот так выглядит деструктор вектора сейчас:

unsafe impl<#[may_dangle] T> Drop for Vec<T> {
    fn drop(&mut self) {
        unsafe {
            // use drop for [T]
            ptr::drop_in_place(&mut self[..]);
        }
        // RawVec handles deallocation
    }
}

Добавляем всего одну строчку:

unsafe impl<#[may_dangle] T> Drop for Vec<T> {
    fn drop(&mut self) {
        println!("{}", self[0]);
        unsafe {
            // use drop for [T]
            ptr::drop_in_place(&mut self[..]);
        }
        // RawVec handles deallocation
    }
}

И вдруг код в main, становится некорректным.

Есть общие черты между Nim и vala, оба языка генерируют код на других языках.

Таких языков как, собак нерезанных.

Nim - это недопитон, а Crystal - недоруби.

А есть что-то, что на нём написано и что можно использовать в продакшне?

Язык в целом хороший, НО:

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

2) мутная система макросов, я так и не понял, где routes в jester определен

Язык в стадии альфы. Кто на нем будет что-либо писать?

Забавно что у Zig по-прежнему есть null и undefined. Любителям стрелять себе в ноги это наверное понравится, но смысл от этих архаизмов в современном ЯП?

Деструкторы вызываются в порядке противоположном объявлению.

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

Я уже давал ссылку

Уже нашёл, откомментировал раньше чем написал. (:

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

Например? Ну и «здравый смысл» понятие растяжимое (в таких случаях).

А production то ... is it ready for Rust

«Продакшен» тоже разный бывает.

Что интересно, undefined (mem::uninitialized) широко используется в стандартной библиотеке раста (например при переводе чисел в строку для println), а так же в популярных крейтах, таких как serde и regex.

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

Вот пример, я бы очень хотел чтобы такой код компилировался:

if let Some(v) = map.get_mut(key) {
    *v += 1;
} else {
    map.insert(String::from(key), 1);
}

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

let flag;
if let Some(v) = map.get_mut(key) {
    *v += 1;
    flag = false;
} else {
    flag = true;
}
if flag {
    map.insert(String::from(key), 1);
}

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