LINUX.ORG.RU

Ответ на: комментарий от shpinog

А ты что думаешь, что в Debian смогут сделать nix пакетным менеджером по-умолчанию? Это уже тогда не Дебиан будет...

Einstok_Fair ★★☆
() автор топика
Ответ на: комментарий от Einstok_Fair

Естественно не так хорош и есть.

Но Debian он не вытеснит уже хотя бы потому, что ему для начала придётся раз в тыщу вырасти.

t184256 ★★★★★
()
6 декабря 2019 г.
Ответ на: комментарий от mersinvald

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

Бугуртос тебе ниже правильную ссылку дал ( http://www.ada-auth.org/standards/12rm/html/RM-C-6.html#p15 ) - в аде тоже есть примитивное ограничение гонок. Правда, оно таки слишком примитивное, и уже две ячейки атомарно средствами языка ты не сможешь изменить ни в аде, ни в расте.

По поводу memory safety я бы сказал, что что-то в аде лучше, что-то в расте лучше, но так или иначе, в реальном приложении неизбежно тебе приходится прибегать к небезопасным операциям. И прибегать тем чаще, чем сильнее ограничил тебя язык.

byko3y ★★★★
()

Чем Раст лучше Ада?

Тем, что он чуть меньше сношает мозг. Наверняка, Аду делали люди, которые соображали в программировании, но в какие-то моменты времени в дело вмешивались коммитеты, из-за чего в аде есть проблемы с целостностью архитектуры и чрезмерным нагромождением фич. Чем руководствовали коммитеты я могу понять: язык должен дать безупречную надежность и неплохую читаемость, а трудности написания уже никого не волнуют. Но они переборщили. Точно так же, как Гвидо переборщил с читаемостью, они принесли в жертву безопасности очень много, и в итоге писание прог на аде стало пыткой, из-за чего вы можете найти так мало людей, которые пишут любительские проекты на аде — слишком уж сильно он сношает мозг писателя. У тебя проект чуть больше hello world, и привет - вот вам вывод двух переменных на консоль:

with Ada.Text_IO;

procedure Operator_Power is
   A : constant Float   := 5.0 ** 2;  -- A is now 25.0
   B : constant Integer := 5 ** 2;    -- B is also 25

   package T_IO renames Ada.Text_IO;
   package F_IO is new  Ada.Text_IO.Float_IO (Float);
   package I_IO is new  Ada.Text_IO.Integer_IO (Integer);

begin
   T_IO.Put ("A = ");
   F_IO.Put (
      Item => A,
      Fore => 3,
      Aft  => 1,
      Exp  => 0);
   T_IO.New_Line;
   T_IO.Put ("B = ");
   I_IO.Put (
      Item  => B,
      Width => 3,
      Base  => 10);
   T_IO.New_Line;
end Operator_Power;
Норм? Уже потираете ручки, предвкушая, какой классный софт напишите на этом языке?

По этой причине так мало людей, которые знают Аду, а те, кто потратили время, чтобы научиться на ней писать, ведут себя как мать ребенка: не могут признаться «да, я родила дебила, бывает; в следующий раз получится получше» - нет, она будет говорить «мой сынишка особенный, он альтернативно одаренный, дети разные бывают, я бы не променяла на другого; вот у других дети бегают и шалят, а мой сидит спокойно и пускает слюни». Примерно та же история с людьми, которые осилили монады в хаскеле — цитирую слова одного довольно известного персонажа:
https://avva.livejournal.com/1516071.html

Монады объективно тяжело понять. Их тяжело понять не только потому, что это «новый» тип мышления - функциональное программирование - но и вообще, просто, с объективной интеллектуальной точки зрения их тяжело понять. Они требуют намного больше абстрактного и типично-математического мышления, чем сложные возможности в любых других известных мне языках. А меж тем в Хаскеле даже строку на вывод не послать без монад (ну, можно, конечно, это делать, не понимая, как это работает, но это ж неинтересно)...
Попросту говоря, не является ли энтузиазм по поводу Хаскеля и монад в определённой мере интеллектуальной мастурбацией, когда те, кто «проникся», радуются тому, как это умно и глубоко, и какие они крутые, что хорошо это понимают?

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 2)
Ответ на: комментарий от slovazap

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

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

red75prim ★★★
()
Последнее исправление: red75prim (всего исправлений: 2)
Ответ на: комментарий от t184256

Я и не тащу, nixos запрещает. Но в этом вся моя мысль - несколько ПМ => возможность ставить гадость в обход единственно верного ПМ => потенциальная помойка.

А потом возникает ситуация, когда в команде разработки один сидит на nixos, второй на arch, третий на маке (каждый работаем там где ему удобно и где у него максимальная производительность), собирать и прогонять тесты надо на отдельном стенде, выполнять кроссплатформенную сборку. И, конечно, у всех должны быть библиотеки одинаковых версий. И…. Ваши действия, какой единственно расововерный ПМ предложите?

ma1uta ★★★
()
Ответ на: комментарий от ma1uta

И, конечно, у всех должны быть библиотеки одинаковых версий. И…. Ваши действия, какой единственно расововерный ПМ предложите?

Почему? Нормальные разработчики библиотек обычно не ломают обратную совместимость. Даже если есть какие-то регресии это решается тем что пишется об этом в багзиллу разработчикам/мейнтейнерам…

Тот же boost нормально работает в разных дистрибутивах не смотря на то что версии с 1.67 до 1.71 в разных современных дистрибутивах линукса…

fsb4000 ★★★★★
()
Ответ на: комментарий от t184256

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

packaged

Princesska ★★★★
()
Ответ на: комментарий от fsb4000

разработчики библиотек обычно не ломают обратную совместимость.

Тот же boost нормально работает в разных дистрибутивах не смотря на то что версии с 1.67 до 1.71 в разных современных дистрибутивах линукса…

Вашими словами… Из того, что вы не сталкивались с подобными проблемами не следует, что их нет.

https://www.boost.org/users/history/version_1_71_0.html:

Breaking change: MD5 name-based uuid generation was corrected to be identical on all endian systems. Define BOOST_UUID_COMPAT_PRE_1_71_MD5 to keep the result in a format compatible with 1.66 through 1.70. This does not affect the default name-based uuid generation which is based on SHA1. (PR#109)

https://www.boost.org/users/history/version_1_70_0.html:

Breaking changes: Boost.Test minimal.hpp is now showing a deprecation warning,

https://www.boost.org/users/history/version_1_69_0.html:

Breaking change: Use explicit operator bool when available (PR#5)

https://www.boost.org/users/history/version_1_68_0.html:

Breaking change: sha1 detail namespace header redirection for backwards compatibility was removed (PR#69).

https://www.boost.org/users/history/version_1_67_0.html:

Breaking change: Changed the result of the (op)_and_test operations added in Boost 1.66 to the opposite - the functions now return true if the operation result is non-zero. This is consistent with other test methods in Boost.Atomic and the C++ standard library. Users can define BOOST_ATOMIC_DETAIL_HIGHLIGHT_OP_AND_TEST when compiling their code to emit warnings on every use of the changed functions. This way users can locate the code that needs to be updated. (#11)

Breaking Change: When converting a multiprecision integer to a narrower type, if the value is too large (or negative) to fit in the smaller type, then the result is either the maximum (or minimum) value of the target type. This was always the intended behaviour, but was somewhat haphazardly enforced before. If you really do want just the low order N bits of a value, then you will need to mask these out prior to the case, for example: static_cast(~static_cast(0) & my_value). Note that technically (to avoid undefined behaviour) you should do the same thing with built in integer types too. See #13109.

Breaking change: Removed with_context (#239)

Breaking change: <boost/utility.hpp> header no longer includes boost::next and boost::prior as they have been moved to the iterator module. Instead include <boost/next_prior.hpp>. Other uses of <boost/utility.hpp> are discouraged, it’s better to use the header for the specific functionality instead.

И так далее. Да, фигня, да, ломают обратную совместимость в минорных версиях (не мажорных). Факт в том, что ломают. И может получиться ситуация, что у одного разработчика в его операционной системе библитеку запакетили одну версию, а у другого разработчика в другой операционной системе запакетили другую версию. И один разработчик использует фичу, которая является breaking changes в версии другого разработчика. А на билд-сервере используется библиотека с третьей версией.

ma1uta ★★★
()

это слишком открытый вопрос, больше конкретики

anonymous
()

тред не читал.

ничем не лучше. Вот совсем ничем. Можно в плюс поставить cargo, но это слабоватый плюс, для того чтоб совсем «лучше». Расту 7 лет, а он уже сложнее ады в приемах и правилах и уродливее плюсов по синтаксису.

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

anonymous
()
ехал wrap через unwrap
видит wrap в unwrap'e wrap 
сунул в wrap свой wrap в unwrap
wrap.unwrap().unwrap().unwrap()
anonymous
()

В аду черти и котлы. А в расте что?

te111011010
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от byko3y

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

anonymous
()
Ответ на: комментарий от anonymous

Кстати, скинул бы кто примеры того самого «ужаса» про который все говоря. Для непосвященных.

anonymous
()
Ответ на: комментарий от anonymous
fn a_call<T>(lhs: &T, rhs: &T) -> bool {
    lhs as *const T == rhs as *const T
}
fn b_call<T: SomeTrait>(lhs: Rc<RefCell<T>>, rhs: Rc<RefCell<T>>) -> bool {
    is_same(&*lhs.borrow(), &*rhs.borrow())
}

Угадай, для чего этот код.

anonymous
()
Ответ на: комментарий от anonymous

ээх. подсказку оставил (a_call это is_same). ну да и хер с им. Это выглядит как говно в любом случае

anonymous
()
Ответ на: комментарий от anonymous

подсказку оставил (a_call это is_same).

Я все равно не понял, лол. Сравнение типов переменных?

anonymous
()

Ада больше для военных. Мирным гражданам достаточно Паскаля.

saahriktu ★★★★★
()

"Язык Пентагона — враг мира. Язык «Ады» — голос термоядерного ада… В языке «Ады» слышится проклятие роду людскому. "

Ничем не лучше

Dark_SavanT ★★★★★
()
Ответ на: комментарий от anonymous

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

Это разница только для новопосвященных. У крестов тоже нечитаемый синтаксис в этом плане, но люди привыкают читать клинопись.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Угадай, для чего этот код.

Плохо знаком с синтаксисом раста и стандартной либой. Это какие-то функции сравнения двух контейнеров и значений в этих двух контейнерах.

Основная беда раста, на мой взгляд - это что разрабы зассали делать полный вывод типов, то есть, на уровне аргументов функций и за ее пределами. Вообще, типы раста, вроде этого «Rc<RefCell<T>>», как бы намекают нам, что разраб должен видеть их только раз в жизни. Как я понимаю, разрабы руководствовались тем, что современные макаки по определению типов в функции судят о назначении этой функции. Хотя я не уверен, что это было серьезным фактором. Я вообще не могу понять, почему в расте не сделали полноценный type inference. Хочешь писать явные типы? Пиши, но меня не заставляй. Согласитесь, ведь выглядит же намного лучше:

fn a_call<T>(lhs: &T, rhs: &T) {
    lhs as *const T == rhs as *const T
}
fn b_call(lhs, rhs) {
    is_same(&*lhs.borrow(), &*rhs.borrow())
}

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

Потому что это ненаучная фантастика.

Einstok_Fair ★★☆
() автор топика
Ответ на: комментарий от byko3y

Я вообще не могу понять, почему в расте не сделали полноценный type inference.

Все эти примитивы управления памятью не выведешь автоматически. Короче, нужен GC как у людей, но растишка у нас типа системная. Хотя сишники от нее шарахаются как от чёрта почему-то.

anonymous
()
Ответ на: комментарий от anonymous

Все эти примитивы управления памятью не выведешь автоматически

Какие еще «все»? Ты выводишь тип по его инициализации/использованию, потом все методы работы с типом автоматически применяются в соответствии с этим типом.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Раст это такая попытка скрестить ежа с ужом. Тут тебе и навороченная система типов, и функциональщина, но и низкоуровняя возня в полный рост. Это как умножить С++ на хаскель, ясно же, что получится страшилище неописуемое. Но кому-то нравится, только вот годы идут, а язык все такой же «молодой, подающий надежды» с околонулевым количеством вакансий. Так в девках и проходит всю жизнь.

anonymous
()
Ответ на: комментарий от byko3y

У крестов тоже нечитаемый синтаксис в этом плане, но люди привыкают читать клинопись.

У крестов не так все запущено, хотя согласен, это тоже язык рептилоидной группы.

anonymous
()
Ответ на: комментарий от Einstok_Fair

Уверен, что Debian будет им вскоре вытеснен.

Прошёл год, Nix сохраняет рыночную долю 0.000001%.

anonymous
()
Ответ на: комментарий от byko3y

Ты выводишь тип по его инициализации/использованию

Ладно, а как ты будешь ссылки, мутабельность, лайфтаймы выводить? Впрочем, лайфтаймы и так выводятся где это возможно. Еще не забывай, что полный вывод замедляет компиляцию. Не очень прикольно будет 10 минут ждать, чтобы увидеть ошибку компиляции.

anonymous
()
Ответ на: комментарий от anonymous

Я все равно не понял, лол. Сравнение типов переменных?

Какой-то старый код, делающий то же, что и Rc::ptr_eq(&a, &b). Так понятно?

red75prim ★★★
()
Ответ на: комментарий от anonymous

Я про Rust ничего не знаю и даже, кажется, примеры кода раньше не смотрел. Однако, очевидно, что a_call — принимает указатели на два значения типа T и проверяет их на эквивалентность, а b_call делает то же самое, с явным указанием владения. Если б я ещё знал как этот borrow работает, смог бы ответить точнее. В любом случае в чём заключаются ваши претензии мне не понятно.

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

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

Так лайфтаймы же по хиндли-милнеру, внезапно, и выводятся. Но не типы.

Еще не забывай, что полный вывод замедляет компиляцию.

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

byko3y ★★★★
()
Ответ на: комментарий от Princesska

И что это? Оно не гуглится.

EDIT: а, ты не понял. Не «один единственно юзабельный в 2019 ПМ, благословение наше с небес», а «один-единственный ПМ, отвечающий за весь бардак на твоём хосте».

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

И внятно объясняет это соображениями нетехнического характера.

Кто объясняет? Какие могут быть аргументы для того, чтобы превратить раст во второй C++?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

некропостов тред

Бугуртос тебе ниже правильную ссылку дал ( http://www.ada-auth.org/standards/12rm/html/RM-C-6.html#p15 ) - в аде тоже есть примитивное ограничение гонок. Правда, оно таки слишком примитивное, и уже две ячейки атомарно средствами языка ты не сможешь изменить ни в аде, ни в расте.

memory model в одном месте

ещё добавлю: 9.4 Protected Units and Protected Objects, 9.5.1 Protected Subprograms and Protected Actions 9.11 Example of Tasking and Synchronization ,13.11 Storage Management, ручное управление памятью 13.11.2 Unchecked Storage Deallocation,реализация пулов [13.11.6 Storage Subpool Example](http://www.ada-auth.org/standards/12rm/html/RM-13-11-6.html]

4.8 Allocators

7.6.1 Completion and Finalization

то есть, нет в одном месте, всё это важно.

надо понимать, что единицей выполнения являются задачи, задачи принадлежат пакетам, задачи выполняются асинхронно и возможно, недетерменированно (select). 9.4 Protected Units and Protected Objects про synchronized (из Java) в основном типы и данные, но также и методы. при этом получается либо мутекс или семафор либо задачи по рандеву взаимодействующие для разделяемых ресурсов.

то есть на уровне memory model 10.2 Program Execution выполнение начинается с нескольких асинхронных задач, в порядке, задаваемом pragma Preelaborate 10.2.1 Elaboration Control через которую можно задать например, циклические зависимости между пакетами.

задачи привязаны к пакетам, разделяемые типы данных (protected type) привязаны к задачам. задачи взаимодействуют асинхронно D.11 Asynchronous Task Control либо синхронно D.10.1 Synchronous Barriers через разделяемые данные и пакеты (начинают выполняться если задача описана в пакете, продолжают выполняться/блокироваться через select 9.7 Select Statements и т.п.)

то есть: первичны задачи, вокруг типов распределённые по отдельным пакетам.

anonymous
()

ИМХНО не хочу попасть в Ада.

Владимир

anonymous
()
Ответ на: комментарий от byko3y

Понятно. Растбук не читал, сразу сраться полез.

t184256 ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Я имел в виду «пример русскоязычного технического ресурса».

t184256 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.