All streams
Search
Write a publication
Pull to refresh
88
0
Александр Мещеряков @freecoder_xx

Rust разработчик

Send message
Все философские концепции пространства и времени делятся на субстанциальные и реляционные. Субстанциальная концепция пространства и времени рассматривает пространство и время как особые сущности, которые существуют сами по себе, независимо от наличия или отсутствия материальных объектов. Подобных взглядов придерживались Демокрит, Эпикур, Ньютон. Реляционная концепция пространства и времени считает пространство и время особыми отношениями между материальными объектами и процессами с их участием и вне их не существуют. Подобных взглядов придерживались Аристотель, Лейбниц, диалектические материалисты.

Извиняюсь за цитирование Википедии, но получается, что современная физика до сих пор исходит из субстанциальной концепции пространства? Мне видится, что ОТО сделала уверенный шаг в сторону реляционной.

Я думаю первостепенное значение играет количество и качество имеющихся библиотек в экосистеме, поэтому для Rust важно, чтобы он был популярен в Open Source. Когда количество библиотек перевалит за критическую черту, бизнесу станет выгодно его использовать. А если так, то становятся важны в первую очередь те качества, которые могут способствовать распространению Rust в среде свободного, а не коммерческого ПО.

fn extract_from_list(list: tlist, key: int8) -> &mut tlist

Такое в Rust не прокатит, так как тут list перемещен в функцию, а не передан по ссылке, а это значит, что компилятор потребует явно указать лайфтайм для ссылки в возвращаемом значении:


fn extract_from_list<'a>(list: tlist, key: int8) -> &'a mut tlist

Но чему будет равно время жизни 'a? Значение list явно будет жить меньше, чем 'a, так как оно пропадает при завершении работы функции. Поэтому в таком случае компилятор выдаст ошибку о невозможности вернуть ссылку на объект, которым владеет функция.

Это бесполезно, зря вы усердствуете. Начнем с того, что этот человек назвал джуном тимлида за тридцать — ну вы понимаете, насколько он проницательный )


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


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

Mozilla — необычная организация, это Феникс, она родилась из пепла Netscape. Надеюсь, что это повторится в случае развала теперь уже Mozilla Corp.

Я не минусовал, но все-таки отвечу: Firefox разрабатывают в том числе его пользователи — это нормально для СПО.
Вот тут более подробный ответ: https://habr.com/ru/post/499936/

А как там поживает Servo и шевелится ли? Кто-нибудь знает?

У меня одного с десктопным и мобильным FF все хорошо?

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

Ну вот список некоторых компаний, которые используют Rust в проде:
https://www.rust-lang.org/production/users

Нет специализации, impl Trait можно использовать только для функций, const generics до сих пор не стабилизированы — из-за этого небольшой адок при работе с массивами, по сравнению со срезами, auto Trait можно использовать только внутри std, даже некоторые фичи паттерн-матчинга еще не работают: хорошо, что недавно стабилизировали паттерны [..], но вот так до сих пор нельзя:


let tuple @ (a, b) = (1, 2);

error[E0658]: pattern bindings after an `@` are unstable
 --> src/main.rs:2:18
  |
2 |     let tuple @ (a, b) = (1, 2);
  |                  ^
  |
  = note: see issue #65490 <https://github.com/rust-lang/rust/issues/65490> for more information

Мне вот тоже видится, что применение Rust шире ниши низкоуровневых системных задач. Но я уже писал статью на этот счет: https://habr.com/ru/post/504622/

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

Но я не видел ни одной задачи, которую Rust решает лучше C. Удобство и быстрота разработки — возможно, но не скорость работы.

Вот тут есть некоторые задачи, которые Rust решает быстрее: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
Значит ли, что в принципе это возможно?

Сложность Rust имеет двойственную природу.


С одной стороны, в языке присутствуют мощные, и от этого довольно сложные для новичков концепции, которые, однако, упрощают разработку любой программы, которая чуть сложнее, чем hello world. Такая сложность является препятствием только при первом освоении языка, а в работе она собой компенсирует значительную сложность самой программы. Да, вы можете взять язык сильно проще, но потом будете дольше устранять проблемы в своем коде, особенно если его много и он многопоточный.


С другой стороны, многие красивые концепции Rust имеют особые случаи и исключения, которые не дают по-настоящему расслабиться. И вот эта сложность действительно является препятствием, но она во многом следствие молодости языка.

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

Если мы исключим всю материю во Вселенной, то окажется, что наша Вселенная это просто громадный кусок пространства.

А давно уже у нас пространство перестало быть атрибутом материи и обрело самостоятельное от нее существование?

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

Минус не очень хорошая штука — он влияет на рейтинг и на видимость комментария. Я обычно просто несогласие выражаю в комментарии, либо плюсую ответы тех, с кем согласен. Минусую только те, где явно есть провокации, деструктивные попытки съехать на личности, оскорбления и пр. То есть я воспринимаю минус как "убрать этот комментарий", а не как "выражаю несогласение с точкой зрения автора". К сожалению система оценок Хабра и ее влияние принуждают к этом.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity