Конкуренты есть у всех. К тому же у массовости есть и обратная сторона: средний уровень сообщества падает от массового притока новичков в программировании. Что, по факту, имеет ряд негативных последствий для профессиональных программистов, начиная от необходимости учить/руководить чуть ли не чаще, чем программировать, и заканчивая замедлением темпов индексации зарплат.
Формулировка то расплывчатая. Но налоговая не расстроится, если вы будете 13%, а не 6% ей отчислять… Так что не волнуйтесь, в суд она на вас из-за этого подавать не будет )))
Вообще если это один заказ на продолжительное время, то физ.лицо тоже может вполне официально работать по договору подряда… Просто это невыгодно, потому что придётся 13% платить, а не 6%. Да ещё и в фонды из этих 13% никаких отчислений не будет.
А разве на PayPal сейчас не принудительная автоматическая конвертация в рубли? Реально лучше налог спокойно заплатить чем примерно такой же процент при конвертации потерять. Тем более, что 1 из 6% идёт напрямую в ПФР.
Язык — это тоже инструмент и ещё там смайлик был.
А вообще да, о количестве игр под мобилки я как-то не подумал, вот что значит наиграться в компьютерные игры ещё до появления смартфонов )))
В комментах выше считали кол-во репозиториев на Github, у Rust — чуть больше 5 тыс.
У Swift — порядка 38 тыс. У Objective-C — около 150 тыс. Так что Rust если и выбивается из списка, то пока не сильно. А Swift заслуженно записан во второй эшелон.
Понимаете, если программировать только на C#, то это всё может выглядеть круто. Но по факту это просто заимствование идей из других языков. C#, начиная с 3-й версии, начал путь в функциональщину. Это классно, но совсем не ново.
Ну, добавили сначала простенький вывод типов (var) и лямбды, потом открыли возможность тип привязывать к данным, а не к переменным, а переменные ребиндить (dynamic) и возможность асинхронно код вызывать (async/await), ах да, ещё интерполяцию строк )))
Я не говорю что в этом есть что-то плохое, наоборот, мне нравится C# и направление, в котором он развивается тоже. Просто, если по-честному, ничего такого грандиозного в этом развитии нет со времён появления LINQ. Язык стабилен и просто обрастает мелкими приятными плюшками. Всё здорово.
После шестой версии, например, C# 5 воспринимается многословным и неудобным.
Ахах, это Вы просто F# не пробовали, вот где лаконичность.
И какие тогда по вашему изменения тянут на изменение мажорной версии?
Настолько глобальные, что нарушают обратную совместимость.
Точнее сказать продавали комплектом. Бесплатно скачать компилятор и стандартную библиотеку(VCL) возможности не было, насколько я помню. Для того же C++ такая возможность была.
Я Scheme тоже отношу к LISP-семейству, как и все остальные диалекты.
Я немного знаком с CL и мне кажется очень похоже в плане макросов с Elixir. Да, в CL для гигиеничности нужно использовать gensym, а в Elixir для нарушения гигиеничности var!.. Т.е. в этом плане поведение по умолчанию отличается, но в остальном… те же quote(`), unquote(,), unquote_splicing(@,), те же манипуляции с AST при необходимости.
Со Scheme я не настолько знаком, чтобы всерьёз о нём рассуждать, но Racket, на мой взгляд, выглядит очень круто.
Что касается границ гибкости макросов Elixir, они пролегают по территории довольно редкой для практического применения, например, Вы не можете расширять синтаксис языка произвольным образом, т.к. разрешенный набор небуквенных символов ограничен. Если хотите принципиально кастомный синтаксис, то придётся оборачивать весь код, который будет его использовать, в один вызов макроса, внутри которого можно будет преобразовывать AST как угодно. Но это, в принципе, не велика проблема, т.к. для таких преобразований есть очень удобные средства типа Macro.prewalk/3.
А вот единственным принципиальным ограничением, в которое я однажды упёрся, было то, что в общем случае невозможно внутрь quote подставить кусочек сырого AST (кому интересно, могу в личку скинуть подробное описание этого случая). Это вытекает из двойственного представления кода, тогда как в LISP кроме AST другой записи кода нет. Но это реально очень экзотические случаи.
P.S. Вообще тема интересная, надо Rust и Racket поглубже копнуть )
С тем, что ErlangVM — не язык, и приписывать преимущества виртуальной машины тридцатилетнего возраста эликсиру — довольно странно.
Разумеется, преимущества BEAM — это не заслуга Elixir, но ведь он позволяет ими пользоваться. А таких языков не так уж и много, я осведомлён только об Erlang, Elixir и LFE. Вот и получается, что отличительными особенностями этих 3 языков являются преимущества BEAM :-)
Это из той же серии, что отличительные черты Kotlin — это преимущества JVM и возможность использовать Java-библиотеки. У Rust и Crystal — возможность легко подключать сишные либы. А у Elm — встраиваться в существующие JS-проекты.
И это понятно, никому сейчас не нужен язык-бука, который тупо проигнорит текущее состояние отрасли и будет делать абсолютно всё с нуля. Сложность заключается в выборе наиболее крутых достижений прошлого, их гармоничном комбинировании и дальнейшем развитии. Elixir в этом плане сделал ставку на возможности BEAM, интероперабельность с Erlang, макросы LISP и синтаксис Ruby. На мой взгляд, первые 2 пункта выполнены на отлично. Остальные 2 взяты за ориентир, но видимо не являлись самоцелью. Поэтому синтаксис только отдалённо похож на Ruby, а макросы местами не дотягивают до гибкости LISP, но при этом являются наиболее мощными из всех известных мне языков не из LISP-семейства.
А можете про макросы Nim подробнее рассказать? При беглом взгляде на документацию выглядит действительно извращенно (но не в хорошем смысле) по сравнению с макросами аля LISP. Просто обернуть код в макрос без вереницы newCall, newIdentNode, etc. никак нельзя?
Именно по этой причине перспективными являются kotlin, go и swift — так как за ними стоит «большой» заказчик, который обеспечивает языку задачи и ресурсы для их выполнения.
По-моему только Swift может похвастаться заботливым отношением от большой компании. Google не особо запаривается поддержкой своих языков. Ну а JetBrains наверняка будет приятно, что Вы их в один ряд с Google и Apple поставили.
Я не могу сказать про все языки, но Crystal и Elixir появились именно потому, что в этом есть потребность у крупных проектов на Ruby. После чего и создатели Ruby активнее зашевелились в сторону производительности. Но, как мы знаем, обещанного 3 года ждут, а нагрузку надо держать уже сегодня и в этом Elixir отлично помогает. А кому-то возможно и Crystal уже помогает.
С отличиями всегда есть вопрос: относительно чего? По сравнению с Erlang основная отличительная особенность Elixir — это макросы, даже синтаксис и сокращение boilerplate-кода — это всё следствия. А если говорить об отличиях среди всей массы языков программирования, то они на 90% cовпадут с отличительными особенностями Erlang и это естественно.
Я просто не очень понимаю, с чем конкретно Вы не согласны в этом куске?
Для истории выпишу данные с Github по всем языкам из статьи:
Elm — 433 / 194
Rust — 5146 / 1935
Kotlin — 960 / 1541
Crystal — 150 / 52
Elixir — 2668 / 861
Конкуренты есть у всех. К тому же у массовости есть и обратная сторона: средний уровень сообщества падает от массового притока новичков в программировании. Что, по факту, имеет ряд негативных последствий для профессиональных программистов, начиная от необходимости учить/руководить чуть ли не чаще, чем программировать, и заканчивая замедлением темпов индексации зарплат.
Во некоторых языках разработчики позаботились о нормальной поддержке делегирования, и оно делается одной строкой, без какого-либо бойлерплейта.
Формулировка то расплывчатая. Но налоговая не расстроится, если вы будете 13%, а не 6% ей отчислять… Так что не волнуйтесь, в суд она на вас из-за этого подавать не будет )))
Вообще если это один заказ на продолжительное время, то физ.лицо тоже может вполне официально работать по договору подряда… Просто это невыгодно, потому что придётся 13% платить, а не 6%. Да ещё и в фонды из этих 13% никаких отчислений не будет.
А разве на PayPal сейчас не принудительная автоматическая конвертация в рубли? Реально лучше налог спокойно заплатить чем примерно такой же процент при конвертации потерять. Тем более, что 1 из 6% идёт напрямую в ПФР.
С чего бы это? У меня уже 3-й такой.
А вообще да, о количестве игр под мобилки я как-то не подумал, вот что значит наиграться в компьютерные игры ещё до появления смартфонов )))
У Swift — порядка 38 тыс. У Objective-C — около 150 тыс. Так что Rust если и выбивается из списка, то пока не сильно. А Swift заслуженно записан во второй эшелон.
Ну, добавили сначала простенький вывод типов (var) и лямбды, потом открыли возможность тип привязывать к данным, а не к переменным, а переменные ребиндить (dynamic) и возможность асинхронно код вызывать (async/await), ах да, ещё интерполяцию строк )))
Я не говорю что в этом есть что-то плохое, наоборот, мне нравится C# и направление, в котором он развивается тоже. Просто, если по-честному, ничего такого грандиозного в этом развитии нет со времён появления LINQ. Язык стабилен и просто обрастает мелкими приятными плюшками. Всё здорово.
Ахах, это Вы просто F# не пробовали, вот где лаконичность.
Настолько глобальные, что нарушают обратную совместимость.
Я немного знаком с CL и мне кажется очень похоже в плане макросов с Elixir. Да, в CL для гигиеничности нужно использовать gensym, а в Elixir для нарушения гигиеничности var!.. Т.е. в этом плане поведение по умолчанию отличается, но в остальном… те же quote(`), unquote(,), unquote_splicing(@,), те же манипуляции с AST при необходимости.
Со Scheme я не настолько знаком, чтобы всерьёз о нём рассуждать, но Racket, на мой взгляд, выглядит очень круто.
Что касается границ гибкости макросов Elixir, они пролегают по территории довольно редкой для практического применения, например, Вы не можете расширять синтаксис языка произвольным образом, т.к. разрешенный набор небуквенных символов ограничен. Если хотите принципиально кастомный синтаксис, то придётся оборачивать весь код, который будет его использовать, в один вызов макроса, внутри которого можно будет преобразовывать AST как угодно. Но это, в принципе, не велика проблема, т.к. для таких преобразований есть очень удобные средства типа
Macro.prewalk/3.А вот единственным принципиальным ограничением, в которое я однажды упёрся, было то, что в общем случае невозможно внутрь quote подставить кусочек сырого AST (кому интересно, могу в личку скинуть подробное описание этого случая). Это вытекает из двойственного представления кода, тогда как в LISP кроме AST другой записи кода нет. Но это реально очень экзотические случаи.
P.S. Вообще тема интересная, надо Rust и Racket поглубже копнуть )
Разумеется, преимущества BEAM — это не заслуга Elixir, но ведь он позволяет ими пользоваться. А таких языков не так уж и много, я осведомлён только об Erlang, Elixir и LFE. Вот и получается, что отличительными особенностями этих 3 языков являются преимущества BEAM :-)
Это из той же серии, что отличительные черты Kotlin — это преимущества JVM и возможность использовать Java-библиотеки. У Rust и Crystal — возможность легко подключать сишные либы. А у Elm — встраиваться в существующие JS-проекты.
И это понятно, никому сейчас не нужен язык-бука, который тупо проигнорит текущее состояние отрасли и будет делать абсолютно всё с нуля. Сложность заключается в выборе наиболее крутых достижений прошлого, их гармоничном комбинировании и дальнейшем развитии. Elixir в этом плане сделал ставку на возможности BEAM, интероперабельность с Erlang, макросы LISP и синтаксис Ruby. На мой взгляд, первые 2 пункта выполнены на отлично. Остальные 2 взяты за ориентир, но видимо не являлись самоцелью. Поэтому синтаксис только отдалённо похож на Ruby, а макросы местами не дотягивают до гибкости LISP, но при этом являются наиболее мощными из всех известных мне языков не из LISP-семейства.
А можете про макросы Nim подробнее рассказать? При беглом взгляде на документацию выглядит действительно извращенно (но не в хорошем смысле) по сравнению с макросами аля LISP. Просто обернуть код в макрос без вереницы
newCall,newIdentNode, etc. никак нельзя?Я просто не очень понимаю, с чем конкретно Вы не согласны в этом куске?
Elm — 433 / 194
Rust — 5146 / 1935
Kotlin — 960 / 1541
Crystal — 150 / 52
Elixir — 2668 / 861
Через годик посмотрим динамику.