Comments 154
Много голосов о применении Rust на практике, а вакансий всё нет и нет))
UPD:
А я хочу такие.
Так никто не спрашивал про работу, вопрос был про применение на практике. Вот и крафтил народ свои хомяки на актиксе.
Так бывает, когда программистов, которые хотят использовать язык, больше, чем вакансий от компаний, которые его уже применяют. Получается, что вакансии есть, но они быстро закрываются. И когда смотришь список открытых вакансий, кажется, что их совсем мало.
Что касается Rust, он ещё часто идёт как вспомогательный язык в вакансии, типа
"Написание high-load сервисов на Go и Python с реализацией CPU-bound задач на Rust."
"Работать в основном с Go с небольшим количеством Java / Kotlin (Spring), Elixir и Rust в архитектуре микросервисов"
Т.е. компании уже пишут на Go, но пробуют Rust в качестве альтернативы.
Прям вот таких, чтобы нужен Rust-программист, действительно, пока маловато.
Если в проекте есть го, то не совсем понятно, что там растом делать. Разве что если какие-то дикие проблемы с gc, но с этим вроде уже научились справляться.
Появились задачи для нативного кода, они были решены на Rust.
Вакансия не сформировалась ни на секунду (и не факт, что появится: код небольшой, стабильный, и если аналогичные проблемы не появятся в будущем и не изменятся требования, маловероятно, что придётся с ним что-то делать).
Работа с «сырой» памятью там настолько затруднена, и поверх наброшено столько мозголомных абстракций, что допустить ошибку при прописывании ffi-биндингов очень просто, а вот её отлов потом может занять буквально недели, и всё равно не будет полной уверенности, что на всех платформах программа будет стабильно работать.
Вот классический пример:
extern crate libc;
extern {
fn c_func(x: *mut *mut libc::c_void);
}
fn main() {
let x = 0 as *mut u8;
c_func(&mut (x as *mut libc::c_void));
println!("new pointer is {}", x);
}(&mut x) as *mut _ as *mut *mut libc::c_voidИ это ещё ничего. Куда веселее, когда вам нужно собрать программу под 32 и 64 бита, и вот вдруг оказывается, что сишный компилятор и Rust не сошлись во мнениях, как при разной битности должны выглядеть выравнивания внутри структур/union'ов либо разрядности отдельных элементов. И тоже где-то кем-то портятся данные, и ведь хрен поймёшь, почему так. Доходит до того, что приходится в отладчике смотреть ассемблерный код, разбираясь, как интерпретируются структуры внутри функций.
Если кто-то хочет без особых усилий пощупать все эти «замечательные» особенности Rust'а, могу предложить отладить вот эту программку. Это — маленькое приложение-пример, демонстрирующее использование из-под Rust'а сишного GUI-фреймворка Nuklear с GDI+ бэкендом. Бинарник при правильной сборке получается менее 300 Кб. Так вот, если вы попытаетесь собрать это не под 64-битную винду, а под 32 бита, полученный exe свалится с сегфолтом. Задача: разобраться, почему 64 бита компилируется нормально, а 32 дают нерабочий бинарник.
#[repr(C)]
#[derive(Copy, Clone)]
pub union nk_handle {
pub ptr: *mut ::std::os::raw::c_void,
pub id: ::std::os::raw::c_int,
_bindgen_union_align: u64,
}
На этот раз подсказывать не буду — не стану портить «удовольствие». И да, понадобится отладчик — придётся лазить в asm-код.
Подводя итог, Rust — это последнее, что я хотел бы использовать, если придётся писать и отлаживать биндинги к C/C++ коду. Вот просто ужас-ужас такое потом саппортить.
Для справки: bindgen генерит и тесты. Конечно, очень бы не помешала поддержка генерации биндингов сразу для нескольких целей.
D:\git\nuklear-rust\nuklear-sys>cargo test --target=i586-pc-windows-msvc
Compiling nuklear-sys v4.0.4 (D:\git\nuklear-rust\nuklear-sys)
Finished dev [unoptimized + debuginfo] target(s) in 2.02s
Running target\i586-pc-windows-msvc\debug\deps\nuklear_sys-1bc3559804f4b9c2.exe
running 106 tests
test bindgen_test_layout_nk_baked_font ... FAILED
test bindgen_test_layout_nk_allocator ... FAILED
test bindgen_test_layout_nk_buffer ... FAILED
[...]
test result: FAILED. 54 passed; 52 failed; 0 ignored; 0 measured; 0 filtered out
под 32 бита, полученный exe свалится с сегфолтом
Это не проблема языка, а лично моя, поскольку я не проверял бинды под 32-битность. Баг есть, времени на его ковыряние — нет.
Также bindgen сам по себе рассадник сегфолтов, произведенное им надо править руками в случае любого сложного заголовка.
Да, и очень интересно узнать, как дела с кроссплатформенными биндами в си у других языков. Без сарказма — я просто не интересуюсь.
Но в этих случаях ничего автоматически и без бубна не делается, если платформ больше одной?
зы: я имел в виду, что не интересуюсь биндами к си в других языках, потому спрашиваю без сарказма.
С юниксом вроде все просто и понятно, а вот с виндой у Rust тяжелые отношения. Потому и автогенеренные бинды внезапны чуть менее чем полностью.
Если выравнивание (alignment) так же будет прописано константами, то тоже может сегфолтиться для структур/объединений с разным выравниванием на разных платформах.
А что там у Rust untagged unions? Я чет совсем потерял контакт с их статусом.
я имел в виду, что не интересуюсь биндами к си в других языках, потому спрашиваю без сарказма.«Не интересуюсь» = «мне это не интересно», а зачем спрашивать, если ответ не интересен — непонятно. Видимо, имелось в виду «не узнавал/не интересовался».
В C# есть атрибут DllImport — можно делать биндинги к любой нативной dll. Есть некоторые проблемы с маршалингом — базовые типы (int, float, string) работают более-менее, более сложное нужно разруливать руками. В целом терпимо :)
За другие языки не скажу.
Есть ещё надежда на WebAssembly, под который он идеально подходит. Ну и, в принципе, можно было бы как альтернативу Go его продвигать.
А под webassembly не проще ли на typescript писать? Или есть онисничения?
Для typescript пока экспериментальные варианты только есть. А Rust, в принципе, изначально под WebAssembly делался. А как по факту будет, поживём — увидим :-)
Посмотрел, народ вроде применяет уже ts вполне себе https://github.com/GuildOfWeavers/genSTARK
Как го альтернативу вряд ли. Как c++ да. Но вот на одном проекте столкнулся с довольно обоснованным возражением и этому от руководства: думали сделать сервис на rust, но поняли, что кто умеет rust, тот и c++ умеет. Только c++ грабли известные, бизнес процессы отработанные, разработчиков искать легче. Выгода от rust оказалась неоднозначной для руководства.
А раст разве уже production-ready?
Например, потому что последний релиз компилятора ломает тысячи библиотек кода
Ну и потому что это синтаксический ад, как выше привели пример
Да. А с чего бы нет? Знаю компании, которые используют его в продакшене и вроде как довольны.
Я бы с интересом почитал про опыт на расте в проде. Пока все, что я слышал про реально сложные задачи на расте, негативно. Конкаренси там, работа с сетью, с io
Думаю что проблемы с сетью в основном из-за малого количества готовых библиотек (из активно развивающихся я могу сейчас назвать только actix). Плюс подходы к разработке еще не вполне устоялись, люди тащат код из других языков и пытаются писать в привычном стиле.
Но concurrency — это большая проблема в любом языке, и я не вижу причин, почему Раст тут может быть "хуже".
Про проблемы с io я в целом не слышал. Что конкретно имеется в виду?
Кстати возможно будет интересно сравнение производительности Rust и десятка других языков в реальной задаче: https://github.com/ixy-languages/ixy-languages
Не знаю, я с го сравниваю, а в го с конкарренси все ок. После го вообще многие языки кажутся ущербными в плане конкаренси и некоторых вещей, хотя это, конечно, не так.
Да, в Го действительно легко писать параллельный код на горутинах. Не буду набрасывать, но Го хорош в одних задачах, Раст — в других. И эти задачи пересекаются только если люди плохо понимают отличия этих языков.
Но concurrency — это большая проблема в любом языке, и я не вижу причин, почему Раст тут может быть "хуже".
Ну, так-то у Rust упрощение работы с ней подаётся как одна из киллер-фич...
Да, с моей точки зрения с concurrency в Rust все в полном порядке — и уж точно не хуже, чем в остальных языках. Я лишь говорил о том, что если у кого-то возникают сложности с написанием такого кода — это не означает наличия проблемы в языке, просто это действительно сложно, и нужны правильные инструменты и правильные подходы к разработке.
Когда проходил туда собеседование — впечатление от него были в целом положительные.
На тот момент (около года назад) была небольшая проблема только с наличием библиотек, но в остальном всё, по их словам, устраивало и даже приносило удовольствие.
Действительно. Нашел несколько известных названий в списке продакшен-пользователей. Но не ясно, что там на беке — вся логика, или один замшелый сервис по генерации айди.
Вообще, насколько я понял за время работы с этим языком — не имеет смысла переносить на него небольшие сервисы или утилиты — время разработки не окупится плюшками, получаемыми от использования Rust.
А вот там, где время отладки и доработки потенциально может быть большим (в сравнении с полным жизненным циклом) — там он очень даже может быть полезен, т.к. сам принцип написания программ на этом языке смещает время с отладки и вылавливания битых поинтеров на архитектуру и построение продуманных интерфейсов (иначе, утрированно говоря, не скомпилится).
Но это уже ИМХО
Сотрудники Купибилет мне лично говорили, что полностью переписывают свой бекенд с Ruby на Rust.
Ну переписать то это полдела. Нужно, чтобы оно потом работало
К чему этот комментарий? ЕМНИП, переписываются отдельные модули, которые сразу же интегрируются в систему.
К тому что стоимость разработки и стоимость поддержки — разные вещи.
И для разных языков соотношение отличается.
Есть языки, где написать что-то можно за день, а поддержка потом ногу сломит, потому что в языке куча магии и неявных конструкций, преобразований и додумываний, которые значительно ускоряют разработку, но потом сиди и думай, "это автор так хотел, или компилятор/интерпретатор так додумал".
Есть же и наоборот — языки, черезчур многословные и прямолинейные, где при разработке приходится очень много времени тратить на всякого рода бойлерплейтный код, но зато поддерживать одно удовольствие.
Ответил, к чему комментарий?
К тому, что, по Вашему мнению, Ruby — из вторых, а Rust — из первых?
Понятия не имею, ни на одном из них не писал. Но судя по тому, что говорит сообщество одного и второго — да, как-то так.
Я полностью согласен с тем, что важно учитывать стоимость поддержки. Без конкретных цифр обсуждать это смысла нет, а цифр у меня нет, поэтому я предпочту согласится с тем, что поддерживать код на Расте выходит дороже, чем на некоторых других языках.
Это не потому что "в языке куча магии и неявных конструкций, преобразований и додумываний, которые значительно ускоряют разработку, но потом сиди и думай, "это автор так хотел, или компилятор/интерпретатор так додумал".". Это потому что Раст-разработчиков сегодня очень мало и стоят они дорого.
Не знаю про какой язык вы писали фразу выше, но если про Раст — на всякий случай скажу, что вы очень сильно заблуждаетесь. Раст как раз таки относится ко второй категории — той, где разработка долгая из-за непривычных подходов и бьющего по рукам компилятора, где для простейших паттернов из современной разработки нужно написать много строчек бойлерплейта, где использование макросов — залог выживания, потому что перегрузки функций нет, где синтаксического сахара немного (мы же сейчас частично про Руби говорим, да?), где девиз языка "явное лучше неявного" и тебе приходится тратить время, чтобы явно выразить свои намерения компилятору.
Ну а в результате ты получаешь простой, хорошо поддерживаемый код, с гарантией безопасности памяти и производительностью на уровне С/С++. И при этом тебе не обязательно тратить годы на изучение тонкостей языка.
Хорошо, если так. Я в свое время не осилил раст и поэтому ушел в го с красивым конкарренси и сборщиком мусора. Про раст ничего плохого сказать не могу, но про продуктивные проекты на нем слышал негативные отзывы, откуда и интерес к тем, кто больше в теме.
Я перешел на Раст как раз из-за большей его подуктивности: могу писать широкий диапазон программ на нем, у него отличная модульная и компонентная системы — легко переиспользовать свой и чужой код, а мощная система типов сильно облегчает поддержку, делает рефакторинг безболезненным (благодаря ей и эволюционное прототипирование в Расте хорошо работает).
В Rust я могу справляться со значительно большей кодовой базой и большим числом проектов, чем в других языках (Java, JavaScript, Python, PHP, C++).
Для меня решающим плюсом Раста стала автоматизация рутины (!), которую он дает. Да, рутинный код все еще приходится писать, когда ты пытаешься выразить логику в отношениях типов, но однажды написав — можно смело выкинуть из головы, ибо проверять ее будет компилятор, а тебе не за чем. Тогда как в других языках тебе приходится постоянно проигрывать в голове рутинную логику, так как их системы типов не способны ее зафиксировать.
Что касается хорошо поддерживаемого кода, то попытка интегрировать С-библиотеки в Раст бывает весьма болезненна, неперспективна и небезопасна, что ставит его в изначальную поул-позицию наравне с обычными языками (ну типа Паскаля, где тоже с С-интерфейсингом проблемы).
Раст для 100% надежности требует 100% инфраструктуры на Расте, без компромиссов. А такая появится нескоро.
С Руби сравнивать нельзя — разные во всем — от области применения, до требований к квалификации. Ну и конечно сравнивать компилятор с динамической интерпретацией это…
Язык макросов в Расте отличается от обычного Растовского синтаксиса, и я бы поостерегся их использовать.
Чем отличается? Как цикл while от цикла for? Это такая же часть языка. Да, у макросов много проблем, но без них было бы хуже.
Что касается хорошо поддерживаемого кода, то попытка интегрировать С-библиотеки в Раст бывает весьма болезненна, неперспективна и небезопасна, что ставит его в изначальную поул-позицию наравне с обычными языками (ну типа Паскаля, где тоже с С-интерфейсингом проблемы).
Я ни слова не писал о проблемах взаимодействия с С. Да, возможно это для кого-то сюрприз, но это сложно делать в абсолютно любом языке, но это не говорит о том что абсолютно все языки кроме С — плохие. Я не понаслышке знаю о проблемах взаимодействия с С из Раста, поверьте. Проблемы ли это Раста? Не думаю. Мешает ли это писать поддерживаемый код? Точно нет. В чем ваш аргумент?
Раст для 100% надежности требует 100% инфраструктуры на Расте, без компромиссов. А такая появится нескоро.
Спорно, но соглашусь. А что вы выберете — 90% надежности или 0%? Не вижу причин не внедрять дополнительную надежность с помощью инструментов, которые это позволяют.
С Руби сравнивать нельзя — разные во всем — от области применения, до требований к квалификации. Ну и конечно сравнивать компилятор с динамической интерпретацией это…
Да я особо не сравнивал, мне просто в контексте упоминания синтаксического сахара вспомнился Ruby (как раз недавно много времени потратил на попытки разобраться в документации одной софтины на нем).
Я когда искал работу на Rust рассматривал сразу 3 вакансии, причем все — удаленная работа и в русскоязычном сегменте (работу в офисе не рассматривал, хотя там были еще вакансии). Я соглашусь с тем, что пока нет регулярного, стабильного спроса на Rust-разработчиков. Но если у вас есть пара месяцев на поиск работы и вы достаточно опытны (джунам найти работу на Rust тяжелее), то выбор у вас будет.
Жаль, что вакансий на Elixir практически нет, но хоть больше, чем на F#, на котором их нет совсем. Последнее время хочется соскочить с иглы C#, на один из этих двух языков. Elixir пока забросил, а на F# даже пишу небольшие пет-проекты, но вот открываю HH и МойКруг и грустно становится.
Согласен. F# — тоже весьма приятный язык. А по поводу вакансий, для Elixir есть: https://elixirjob.ru/
Возможно, для F# тоже есть подобный агрегатор вакансий?
И dart-a нет, не зачёт. ತ_ʖತ
Кстати, про Dart я вспоминал, перечитывая комментарии к прошлой статье. Тогда Vilyx сокрушался по тому же поводу.
Стоит отметить, что за 3 года он продвинулся на ощутимые +11% по графику Redmonk. Но он 3 года назад уже был устоявшимся языком, поэтому и не попал в исходную статью, а как следствие и в эту.
Жаль, что язык не попал в статьи, ему тут самое место.
Я согласен, что Dart идёт примерно в той же области, что и тройка лидеров из статьи. Будет классно, если Вы примерно в том же стиле, как в статье, чуть подробнее распишете, что произошло с Dart за 3 года. Я думаю, многим будет это интересно. А посколько вы его используете на практике, то и информация будет более полной, чем от стороннего наблюдателя.
P.S. На мой взгляд, помимо Dart ещё Julia незаслуженно обделена вниманием оказалась. У неё и версия 1.0 год назад вышла и рост популярности она показала почти такой же как Elixir.
Так что если Oracle продолжит закапывать Java,
Ни разу не против Kotlin (и только за), но ткните меня лицом, где Oracle закапывает именно Java.
Я имел в виду, что закручивая гайки по патентам, связанным с Java, Oracle делает из JVM платформу, с которой крупные компании не захотят больше связываться. Само собой, миллионы компаний уже связались, поэтому у Oracle пока что есть широкое пространство для манипуляций текущей ситуацией.
моё мнение — вы заблуждаетесь. В споре Google vs Oracle используется слово «Java», только вывод вы делаете неправильный из этого. Чуваки из Google получили нахаляву программистов для программ для своей ОС, решив использовать API от Java SE. Oracle задала вопрос: «Какого фига? Давайте лицензируйтесь!» Это не имеет никакого отношения к использованию Java всеми остальными компаниями как ЯП с компилятором и рантаймом.
Это не имеет никакого отношения к использованию Java всеми остальными компаниями как ЯП с компилятором и рантаймом.Это имеет прямое отношение ко всем остальным компаниям. Из веба Java, довольно-таки бесцеремонно, выпилили и уж явно никто и никуда её больше продвигать не будет. Хотя, конечно, выпилить её из тех мест, где она укоренилась непросто… но, в принципе, Native Kotlin даёт шанс.
Oracle задала вопрос: «Какого фига? Давайте лицензируйтесь!»Лучшего способа загнать язык программирования куда-то в малозаметных нишу придумать просто нельзя. Если у тебя есть куча бесплатных альтернатив — то какой смысл выбирать что-то, за что нужно платить?
То есть да, вы абсолютно правы: Oracle не хочет убить Java, они всего лишь хотят заработать денег… но де-факто — они могут это сделать только за счёт популярности Java.
Впрочем популярность Java (за счёт периода «до Oracle») такова, что Oracle потребуется изрядно постараться, чтобы её убить…
Java из web — это UI в браузере?
> и уж явно никто и никуда её больше продвигать не будет.
> Впрочем популярность Java (за счёт периода «до Oracle») такова, что Oracle потребуется изрядно постараться, чтобы её убить…
ну вы и зануда =)
на серверах она живёт и новые проекты на ней писались и в 2010, 2015, и пишутся без проблем сейчас в 2018, 2019: lamoda.ru, cian.ru, domclick.ru, sberbank.ru, revolut.com, игровые сервера… да много где. Вот вы играете в мобильные игры на своём смартфоне, а сервак этих игр без проблем бежит под JVM. Никаких проблем использовать Java нет, Камооон это же просто ЯП и крутой рантайм со сборщиком мусора и JIT =)
Кто хочет использует Python/PHP/Go или что-то другое, нет проблем.
Какое? Вы же не аргументируете свои слова ничем.
Я привёл объяснение, что ваш довод — это неправильное понимание вопроса. Плохо ли поступает Oracle, что судится за API — отдельная тема. На Java это никак не влияет, серьёзно.
Я не думаю, что каждая первая компаний будет читать юридическое разбирательство в десятке томов, чтобы сформировать правильное понимание вопроса. Вы же тоже материалы дела, наверняка, не читали… А опираясь на пересказы пересказов, сложно быть уверенным в правильности своего понимания вопроса.
Шумиха есть? Есть. Google заставят платить? Заставят. Oracle хочет монетизировать JVM за счёт её пользователей? Хочет.
Этого уже многим будет достаточно, чтобы при старте нового проекта выбрать условно C# вместо Java.
Вы на полном серьёзе считаете, что ведя разработку с использованием Java, никто: ни ТехДиректор, ни ТимЛид, ни программисты не будут в курсе про то, что я вам рассказал? Это ведь не секрет.
> Вы же тоже материалы дела, наверняка, не читали…
пары хороших статей на Хабре и англоязычных блогеров, найденных в сети, достаточно, чтобы свести информацию из разных источников для понимания, а потом пойти на сайт Oracle, чтобы узнать причину дискуссии
www.oracle.com/downloads/licenses/standard-license.html
в хороших статьях указываются цитаты, например как здесь habr.com/ru/post/424579
> Этого уже многим будет достаточно, чтобы при старте нового проекта выбрать условно C# вместо Java.
Пожалуйста используйте то, что вам нравится. Главное не вводите людей в заблуждение или добавляйте «как мне известно» или «по моему мнению» к тому, что пишите. Ваши же слова очень категоричны
— «Так что если Oracle продолжит закапывать Java, есть вероятность, что Android Team со временем откажется и от JVM»
что вызывают только одну эмоцию: рука-лицо.
но ткните меня лицом, где Oracle закапывает именно Javaнапример навязывая платную техподдержку
Поэтому я поддержу вопрос: «где Oracle закапывает именно Java?»
И где же они её навязывают? На jdk.java.net можно свободно качнуть любую сборку, "без регистрации и смс". Ни слова о ТП или что-то там купить. Да, есть отсылка к платным сборкам, но кмк, оракл имеет право на это, владея сайтом
Clojure
Судя по графику, Clojure за 3 года потерял около 5% популярности. Язык всё ещё высоко, но тенденция не слишком обнадёживающая. Примерно такая же ситуация с D, он сполз на 4%.
А Вы используете Clojure в работе? Поделитесь опытом и впечатлениями от изменений за предыдущие 2-3 года.
Я пишу на ней за деньги последние 4 года. После удобств Clojure вернуться в императивный язык уже невозможно. Популярность это очень условная вещь. Если стало меньше вопросов на SO, это на значит, что язык загибается.
Clojure больше по оси Github растерял, но так то да, это всё относительно. Но косвенно говорит о том, что язык уже занял свою нишу.
Впрочем, всё равно интересна ретроспектива от человека, который использует Clojure на практике. Поделитесь наиболее значимыми событиями в мире Clojure на пути c 1.8.0 до 1.10.1?
Очень неправильно сравнивать популярность языков по количеству проектов на GitHub.
RedMonk сравнивает не по кол-ву репозиториев. Это я дополнительно этот критерий привёл, чтобы сравнительную динамику языков посмотреть. Ну и если вы не согласны с методологией RedMonk, то получается, что вы не согласны и с тем, что JavaScript, Java, Python, PHP, C++ и C# сейчас в мейнстриме, но при этом приводите практически идентичный список.
миллион проектов от учеников курсов
На которых преподают JS, Java, Python и чуть реже Ruby и C#.
там почти нет проектов серьезных компаний
Назовите хоть одну серьёзную компанию, которая в 2019 году не имеет OpenSource-активности.
Как был JS, Java, Phyton, C++/C# — так и остались.
Что значит "как был"? 15 лет назад никакого Python и C# в мейнстриме не было, а 20 лет назад там не было ни JS, ни Java. Всё течёт, всё изменяется. Естественно, языки из Top-10 набрали уже критическую массу популярности и даже если с завтрашнего дня перестанут начинать новые проекты на каком-то из них, пройдёт много лет пока он выпадет из 10-ки. Запаздывание рейтингов в этом плане огромно. Вон у Objective-C заняло 3 года, чтобы с 10-го места опуститься на 12-е. Поэтому интерес представляет именно движение за пределами Top-10, но в правой верхней четверти графика.
Мне всегда странно когда говорят, что новый язык увеличил скорость разработки в разы.
Может я чем то не тем занимаюсь. но 60..80% в разработке ПО времени это не кодирование как таковое.
А кодирование… пусть Java до 8 уступала Kotlin. Пусть текста кода поменьше получается.
Но сказать что в разы ускоряет кодирование — то же как то перебор.
В сущности какая разница на чем. Нормальные IDE — ускоряют.
Если на новом языке удаётся при прочих равных писать код с меньшим количеством багов и/или более простой отладкой — он вполне может сократить эти самые 60..80%.
Вообще, у Apple была идея сделать как раз таки язык не привязанный к платформе. Но может в силу инертности мышления разработчиков, а может в силу нестабильности ABI вплоть до 5-й версии, Swift пока не выстрелил как язык для веб-разработки, хотя у него всё для этого есть.
Да и Kotlin тоже никак к Android не привязан. Ну т.е. корреляция с мобильной разработкой безусловно есть у обоих языков, но ни один из них мобильной разработкой не ограничен.
И что у него есть чтобы потеснить мейнстрим в этом секторе? Почему я должен перейти на Swift?
Например, если вам нужен быстрый микросервис, но вам не нравится Go. Почему бы не рассмотреть Swift, как вариант?
А так вообще никто никому не должен. Да и вы даже не написали на чём сейчас программируете.
Если мне нужен быстрый микросервис, то просто берем быстрое железо. ;)
Да и вы даже не написали на чём сейчас программируете.
JS,PHP, иногда Tcl.
Почему бы не рассмотреть Swift, как вариант?
Потому что есть сомнения, что быстрее хотя бы даже NodeJS. Или .Net Core. Или Java/Scala/Kotlin. При этом у любого из них экосистема не хуже Swift.
Obj-C же совершенно не привязан к платформе Apple, но его популярность вне платформ Apple совершенно иная — в разы(или порядки) отличается. Вполне возможно, со Swift ситуация будет аналогичная и после стабилизации ABI.
Если она завтра по какой-то причине станет ненужной, то и язык ждет незавидная судьба.
Почему? Swift работает и под GNU/Linux, и под Android, и даже под Windows.
Да и Mac OS X и iOS никуда исчезать не собираются, а значит Apple ещё будет выпускать новые версии и без того уже вполне стабильного языка. Код открыт под Apache License 2.0.
Т.е. по всем фронтам Swift в очень шоколадно-безопасных условиях находится. Даже если когда-нибудь настанет эплокапец, любая заинтересованная компания сможет взять Swift под своё крыло.
Почему? Swift работает и под GNU/Linux, и под Android, и даже под Windows.Swift-то работает… а все фреймворки — нет. То же, что и с Objective C.
Т.е. по всем фронтам Swift в очень шоколадно-безопасных условиях находится. Даже если когда-нибудь настанет эплокапец, любая заинтересованная компания сможет взять Swift под своё крыло.Но… зачем?
Swift-то работает… а все фреймворки — нет.
Я не пробовал, честно говоря, но заявлено, что фреймворки на линуксе работают:
https://github.com/vapor/apt
https://www.kitura.io/docs/getting-started/installation-linux.html
Да и что в них такого платформоспецифичного может быть?
Да и что в них такого платформоспецифичного может быть?Весь Cocoa?
Когда у вас есть обширные проприетарные библиотеки на платформе, то автоматически теряется смысл выпускать что-то кроссплатформенное.
Это «запирает» язык на вашей платформе. Ровно та же история с C#, кстати: много вы проектов, не привязанных к Windows, на C# знаете? Разве что Unity 3D… А ведь там, теоретически, в кроссплатформенность куча усилий вбухана…
В этом плане все похоже на C#, Kotlin, Go, где есть компания которая двигает язык, и если с ней что-то случится, то будущее языка становится туманно, потому что некому будет вбухивать деньги, развивать его дальше. В то же время не мало языков за которыми никогда и не стояло богатых компаний, типа Rust и Haskell, и которые никогда не станут мэинстримом, просто живут в своей нише со своими преданными фанатами. В этом плане у Swift (или C# и тд) больше шансов на видное место под солнцем, его уже знают больше людей.
Я имел в виду, что платформоспецифичного в веб-фреймворках… Зачем в них Cocoa?
Проблема курицы и яйца: имеющегося Swift-кода без использования Cocoa — исчезающе малое количество, а без имеющихся библиотек и фреймворков — что за преимущество у Swift'а перед каким-нибудь D или Rust'ом?
Мы просто о разных вещах говорим… Я про потенциальную возможность писать на Swift какие-то новые проекты, а вы про перенос существующих.
что за преимущество у Swift'а перед каким-нибудь D или Rust'ом?
Программистов, которые им владеют, гораздо больше. А для бизнеса это чуть ли не основной критерий. Ну и он менее хардкорный, чем D и Rust, значит и темп разработки будет повыше.
Веб-отдельно, десктопные приложения — отдельно, ондроид/иФоне тоже отдельно.
Только языки то так не делятся… они, за редким исключением, все общего назначения.
Ну и великий Фортран взирает на всю эту возню с олипийским спокойствием.
В топе500 у него конкурентов нету.
А как же R и Julia? xD
При всей моей любви к Crystal, это, к сожалению, реально так. Основная фишка Crystal — это синтаксическая похожесть на Ruby. Зная Ruby, можно за день начать писать на Crystal. А карту производительности он уже может не успеть разыграть.
Есть Go, Rust, D, да тот же обсуждаемый выше Swift… Все они имеют примерно одинаковый с Crystal performance, но при этом стабильны. Есть Elixir, Kotlin, Scala, Clojure, Haskell, C#, F#, которые на одном ядре чуть помедленнее, зато легко и непринужденно масштабируются и тоже стабильны. А чем может ответить Crystal? Параллелизмом, который появился две недели назад? Да и где он появился то, в master-ветке? И релизом 1.0 в 202x году? Прикинь, 733 задачи на 4 человек, сколько времени займёт всё это разгрести и дойти до фазы стабилизации?
Как бы мне ни нравился Ruby-like синтаксис, не может это быть основным критерием при выборе языка. А какая ещё киллер-фича у Crystal, чтобы предпочесть его 10 вышеперечисленным языкам? Так то я надеюсь, что через следующие 2-3 года Crystal всё-таки сможет стабилизироваться и составить им компанию.
А какая ещё киллер-фича у Crystal, чтобы предпочесть его 10 вышеперечисленным языкам?Алгебраические типы при общей простоте языка. Из Go, Rust, D, Swift ими может похвастаться только Rust, но там нужно следить за управлением памятью, что по сути означает необходимость переучиваться по сравнению с условным Ruby или C#, что не сильно отличается от освоения скажем Haskell
Ну как-то маловато для киллер-фичи. Штука приятная, но этого мало, чтобы побудить к использованию нестабильной технологии. На мой взгляд, судьба Crystal напрямую зависит от того, когда они смогут 1.0 выпустить. Все философские разговоры на эту тему бессмысленны. Невозможно поддерживать интерес к языку 10 лет, не дав сообществу стабильную версию. А Crystal уже 7 лет исполнилось.
Ещё очень хочется дальнейшего роста Nim, отличная замена питону получается.
Elixir — очень приятный язык, было бы на нём больше вакансий…
Кол-во вакансий постепенно растёт. Я выше уже скидывал ссылку на https://elixirjob.ru/
А у Nim те же проблемы, что и у Crystal, мало core-разработчиков и постоянно растущее кол-во issues.
В итоге, конца и края нестабильной фазе не видно.
— «О какой ещё JVM на Android вы говорите? Ку-ку, *пта, проснитесь! Java Virtual Machine там и не было», — говорю ему я.
Вы хоть темой поинтересовались бы перед тем как написать. Oracle развивает и Java, и JVM как сам Sun даже не делал, а к Android/DalvikVM это не относится ну вообще никак.
Kotlin крут на Android тем, что поддерживает(ал) совместимость трансляции исходного кода в синтаксис Java SE 1.6, который когда-то выбрали в Google. Версии Java давно ушли вперёд, но Google не могут их поддерживать. Kotlin появился в нужное время и стал альтернативой, решившей проблему в желании писать меньше кода «на модном синтаксисе». IDEA давала большой бонус к использованию языка.
Писать меньше кода хотят и на серверах, поэтому Kotlin становится популярнее и там, запускаясь на JVM. Kotlin входит в экосистему Java и не может существовать без неё. Говорить о Kotlin Native, как о замене, сейчас просто бессмысленно.
Ok. Убрал это предложение. У каждого из нас своя специализация и я, действительно, ничего не писал под Android, поэтому был не в курсе, что от JVM они изначально отказались.
Не глупо здесь только одно, желание заработать на труде, вложенном в развитие API, развитие платформы Java силами Sun и уже самого Oracle.
При таком раскладе, Elm остаётся чисто экспериментальным языком с теперь уже сомнительным будущим. Хотя есть люди, которые по-прежнему смотрят на Elm c оптимизмом. С их доводами можно ознакомиться тут.Elm уже не падает во время исполнения в отличии от js или purescript, уже хорошо сжимается минификаторами, что purescript или js не светит по определению, уже имеет быстрый компилятор, уже имеет довольно понятные сообщения об ошибках. Чем purescript превосходит Elm?
Стоит отметить, что ещё в комментариях к исходной статье dimsmol, fshp и hellosandrik высказывались в пользу PureScript, как более жизнеспособной альтернативы Elm. И хотя он тоже до сих пор не достиг версии 1.0, динамика релизов выглядит более обнадёживающей.
Пять перспективных языков программирования со светлым будущим (3 года спустя)