Pijul 0.11

Пихуль Пихуль и в продакшен!!!

Git - совсем другая вещь (и ее несколько лет писали десятки людей). А тот же Darcs писался почти в одно лицо.

Так а почему гит писали десятки людей, а даркс нет? Да потому что на сишке с перлом могут писать десятки разных людей многие годы, а на хацкелях всё пишется в одно рыло пока этому одному не надоест. Эти все борщеязыки не для совместной распределенной разработки, там либо сумрачный гений ваяет, либо коммерческая контора. Оба варианта тотальное дерьмо. Поэтому хацкели такие мегапопулярные, что не сразу вспомнишь какой опенсорс на них писали (если вообще какой-то есть).

Я не знаю о чём вы говорите.

Выкидывай стандалон и юзай msys2.

Так а почему гит писали десятки людей, а даркс нет?

Потому что Git - это система самого св. Линукса Торвальдса.

Да потому что на сишке с перлом могут писать десятки разных людей

Ага, ага. Ни одного проекта на Си и Perl не загнулось от недостатка рабочих рук!!!11

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

Ты просто не в теме.

Ну я дропбокс узал в качестве VCS. Исключительно с целью синхронизации кода между разными машинами с минимизацией телодвижений. Не зашло. Сейчас вот обкатываю svn. Заодно поучу его, а то на работе шеф не осилил git и вернул svn. Ухх дремучая же это штука, но код синхронизировать умеет неплохо.

Сейчас вот обкатываю svn. Заодно поучу его, а то на работе шеф не осилил git и вернул svn

Ты, конечно, слышал о git-svn?

Нда уж.

на винде git чужероден

Наоборот же! это винда в процессе разработки чужеродна.

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

Вы по себе не судите.
Оффисному планктону вроде меня не до извращений.
Бери больше, кидай дальше.

Но когда в тиме человек 15 и некоторые фичи откладывают и доделывают и откладывают и доделывают, то с мержем приходится ипаться день а то и больше.

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

Если пихуль это решит, с гита народ повалит стадами.

А это тогда что, как не подсчет ссылок?

https://doc.rust-lang.org/std/sync/struct.Arc.html

По сути это вручную выделение памяти, когда «надо», т.ч. не всё так радужно.

С git-а народ не повалит по многим причинам

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

- git работает в Github, который принадлежит фирме Microsoft. Потратив немало денег на Github,Microsoft будет его поддерживать. Конкуренты слабее. А впихуль пока не конкурент в отношении предоставления серверных услуг.

- Git поддерживается в популярных IDE.

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

Меня использование впихуля вообще не интересует. Но интересует, получится ли у его авторов подтвердить целесообразность использования Rust.

А зачем мешать шелл и сишку, если не секрет?

ты что, никогда не писал шелл-скрипты со всякими сишными прогами типа grep, find и sed?

Arc используется строго тогда когда это самый правильный вариант. Не понятно к чему коммент

Это ответ на мой вопрос?

Советую изучить азы Си, прежде чем такое писать.

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

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

Проблема не в том, что он консольный, а в том, что он сильно завязан на unix/linux.

Ну это за редким исключением синонимы.

Нет.

Да. Не буду говорить за power shell, т. к. в глаза её не видел, но как минимум до её появления, консоль windows наследовала главный недостаток консоли dos, который и не думали исправлять: она была однозадачной в том смысле, что в конвейере каждая новая программа запускалась только после завершения предыдущей. Именно поэтому скрипты во всех эмуляторах bash под windows, будь то cygwin или msys2, работали в разы, если не в десятки раз, медленнее, чем в linux. Если в powershell эта главная проблема windows-консоли решена, то ничто не мешает виндузятникам переписать скрипты на этой самой powershell, не трогая ядро, написанное на си.

Пока 99% людишек использует винду - это проблемы git.

Тут ещё вопрос, как и для чего они её используют. 99% людишек вообще не программируют. При написании корпоративного проприетарного софта используют другие системы контроля версий, в т. ч. и коммерческие, где проблемы с теми же коллизиями решаются крайне просто: пока файл заблокирован одним из разработчиков, никто не может его коммитить. Для разработки внутри одной фирмы, где все располагаются в одном офисе, а если и нет, то между офисами установлена телефонная и прочая связь, а разработчиков не так много, это обычно приемлемо, хотя иногда и возникают проблемы, когда разработчик уходит в отпуск, так и не закоммитив какие-то файлы и не сняв на них блокировки. Но в мире свободного ПО такой подход неприемлем, т. к. разработчики географически разобщены, зачастую поддерживают связь только по е-мэйлу и работают в свободное время бесплатно, а значит о чётких сроках говорить не приходится. Кто-то вообще может покинуть проект, никого об этом не уведомив (просто перестать коммитить и выходить на связь). Поэтому в мире свободного ПО нужны другие инструменты. Но большая часть свободного ПО создаётся как раз под unix.

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

Не «консоль», а интерпретатор команд.

Именно поэтому скрипты во всех эмуляторах bash под windows, будь то cygwin или msys2, работали в разы, если не в десятки раз, медленнее, чем в linux

Я не знаю, что такое «эмулятор bash», но порты bash в Windows NT и ее потомков были совершенно многозадачными. Так что если скрипты и были медленнее, то точно не из-за отсутствия многозадачности.

Совет не по адресу, я про раст, а не про си пишу, с си всё замечательно.

Именно поэтому скрипты во всех эмуляторах bash под windows, будь то cygwin или msys2, работали в разы, если не в десятки раз, медленнее, чем в linux

Я не знаю, что такое «эмулятор bash», но порты bash в Windows NT и ее потомков были совершенно многозадачными. Так что если скрипты и были медленнее, то точно не из-за отсутствия многозадачности.

Сейчас не буду спорить, т. к. читал об этом давно и не помню где, а гуглить лень. Но то, что bash-скрипты и в cygwin, и в msys2 работали примерно одинаково и во много раз медленнее, чем в linux, ещё в win7, это точно — лично проверял. И вряд ли проблема здесь в конкретном порте, т. к. тестировались оба.

Поэтому NoSQL на таком подъёме

nosql имеет достаточно узкое применение. нигде, где важна целостность данных вашему nosql места просто нет.

bash-скрипты и в cygwin, и в msys2 работали примерно одинаково и во много раз медленнее, чем в linux, ещё в win7, это точно — лично проверял

okay.jpg

Раст не марсианский, это обычный C синтаксис,

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

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

pub fn get_log<'a>(&'a self) -> &'a String 

pub fn get_log<'a>(&'a self) -> &'a String 

Это что за бред? У self никогда не указывается лайфтайм, это не валидный код. А валидный будет выглядеть как:

pub fn get_log(&self) -> &String

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

Линус Торвальдс сделал git для себя. Его он устраивает.

Линус Торвальдс не народ.

git работает в Github, который принадлежит фирме Microsoft. Потратив немало денег на Github,Microsoft будет его поддерживать.

Допилят для поддержки пихуля быстрее других, если хоть какая то популярность будет.

Git поддерживается в популярных IDE

Как и SVN и Меркуриал и многое другое.

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

Проблем не бывает у тех кто ничего не делает.
За последние почти 10 лет с гитом я проблем поимел немало.

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

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

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

Сейчас почти все на Git сидят, включая, в том числе Apple, Google (частично), Microsoft. Изредка на Mercurial и очень изредко Perforce или SVN.

Многие до сих пор на TFC мучаются.

Да, наверно. Но я думаю они будут работу полностью на Git переводить - тут вон и готовая экосистема куплена :)

Переводят и давно.
МС даже в TFC поддержку гита запилил и вполне неплохо.

Хипстер-скор новости: 5

Так это ж целое событие, что на русте что-то еще написали, кроме FF и невидимых (из-за их незначимости) поделий энтузиастов :)

Ты мне для начала расскажи, какие у тебя с Git'ом проблемы.

Никаких проблем. Все проблемы «легко» решаются примерно так:

https://twitter.com/cperciva/status/717864232356675585

pub fn get_log<'a>(&'a self) -> &'a String 

Это что за бред? У self никогда не указывается лайфтайм, это не валидный код. А валидный будет выглядеть как:

pub fn get_log(&self) -> &String

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

Просто у товарища устаревшие сведения о языке. Малознаком.

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

Оно-то да, но баш в винде медленный не поэтому.

Дело в замечательной функции fork(). В линухе это быстрая и почти не затрачивающая ресурсов функция. Пайпы, сопроцессы, фоновые задачи, subshell, tilde expansion и многое другое в баше сделаны через fork(). Почти каждая строчка типичного скрипта — это несколько форков. Но в винде fork() и exec() делаются через адские хаки с CreateProcess.

Добавь сюда дурацкую модель работы с файловой системой (сидишь под линухом, диск не слышно, а в винде тот же диск трещит не переставая; потому виндоюзеры так любят SSD).

Вот отсюда и тормоза в винде.

Отчего же? Нет, то был вполне валидный и эквивалентный код.

Тыц!

Валидный код должен компилироваться.

Ты там немного запутался в лайф-таймах) Я переписал:

struct S<'a> {
    field: &'a String,
}

impl<'a> S<'a> {
    fn get_log<'b>(&'b self) -> &'b String {
        self.field
    }
}

fn main() {}

Thrussh — реализация клиента и сервера SSH на языке Rust.

А что, сишную библиотеку к Rust привязать невозможно, или просто захотелось велосипед изобрести?

Но правильнее вот так:

struct S<'a> {
    field: &'a String,
}

impl<'a> S<'a> {
    fn get_log(&'a self) -> &'a String {
        self.field
    }
}

fn main() {}

Ты там немного запутался в лайф-таймах

Да, уже заметил.

Вопрос: а зачем нужен лайфтайм a в твоем примере?

Но правильнее вот так:

Да. Только это НЕ тот код, из-за которого возник спор.

> Так а почему гит писали десятки людей, а даркс нет?

Потому что Git - это система самого св. Линукса Торвальдса.

Нет. Потому что гитхаб.

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

Плюс подписки, багтрекер, комментарии к пул-реквестам и коммитам, активная реклама... Это настоящая соц.сеть для программистов. Ничего подобного раньше не было. Гитхаб был первым. И быстро занял пустой рынок. Вот и всё.

Если бы тогда в 2008м создатели гитхаба выбрали меркуриал и создали hghub.com, то сейчас меркуриал был бы самой популярной VCS. Но они выбрали гит. И, раскрутившись, сделали и гит популярным.

Эта программа с труднопроизносимым и незапоминающимся названием интересна не как замена git,а как пример активности любителей Rust.

Вот именно, что эта программа интересна как замена всяким неюзабельным гитам.

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

Правильный вариант - конечно же второй.

Так сделай S обычной структурой без явных лайф-таймов. И все получится.

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

Правильный вариант - конечно же второй.

Я удивлен, почему Раст не требует указать, что 'b: 'a, если я в очередной раз не путаюсь в этом синтаксисе.

Так сделай S обычной структурой без явных лайф-таймов. И все получится.

Я что-то пропустил, и уже можно не указывать лайфтаймы, если структура хранит в полях ссылочные типы данных?

Так, всё-таки, синтаксис pub fn get_log<'a>(&'a self) -> &'a String можно заставить скомпилироваться?

Я же о том, чтобы в структуре хранить либо строку, либо Rc на нее. Тогда можно будет определить S без явного лайфтайма. И пример с функцией станет более простым и ясным.

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