Programming
System Programming
Compilers
Comments 60
+12
Ещё один лёгкий, удобный язык призванный заменить другие языки
image
+3
Пусть эксперементируют, вам же от этого не холодно не жарко.)
+4
Больше языков богу языков.
Новые языки помогают людям строить Вавилонскую башню программирования.
0
На прошлой моей работе мы использовали Go (CI/CD систему) для автоматизации разработки. Потом вышел язык программирования Go и пришлось во всей документации переписывать Go на Go.cd что бы не возникало недопонимания.

Самое смешное, что над Go была самописная надстройка с названием… Odin! Мне интересно, как бывшие коллеги будут плеваться, если язык наберет популярность.
+2

Не очень понимаю, какое недопонимание может возникнуть в контексте между ЯП и CI / CD.

+2
По описанию все-таки не вижу каких-либо серьезных преимуществ по сравнению с Go, особенно учитывая что
У Odin нет отдельной killer feature, так как при его разработке основной целью было создание быстрого, простого и очевидного языка, который мог бы заменить С.
+1

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

+3

Если сишечке и нужна замена, то явно не из-за недостатка сахара в синтаксисе, а из-за сложности разработки крупных приложений с требованиями к надежности. Rust пытается решить эту задачу с помощью borrow checker'а (успешно или нет — это отдельный вопрос). Какую проблему пытается решить Odin — пока непонятно.

0
А зачем делать крупные приложения на нескольких ЯП? Сколько ЯП должно быть в крупном приложении? Является ли использование нескольких ЯП отличительным признаком крупного приложения?
0

Чтобы не страдать от интеропа, не раздувать стек, иметь взаимозаменяемую команду...

0
Сейчас же все так любят микросервисы, а какая разница на чём они написаны — на вход JSON, на выход JSON
0
А чем Go не системен?

Довольно скользкий вопрос, что системно, а что нет в наше время. Мой любимый пример — Picobit Scheme. Реализация языка Scheme (это Lisp такой), которая позволяет в 20 килобайт утрамбовать полноценный многопоточный http-сервер и запускать его на 64 килобайтах памяти, мигая при этом лампочками и двигая моторчиком.

Границы в языках уже совсем размыты, поэтому не стоит, мне кажется, напряжённо их искать. Нужно просто смотреть на то, что можно на языке делать, а что нельзя.

На Go можно программировать микроконтроллеры.
+3
Сборка мусора, горутины, отсутствие контроля выделяется ли память на стеке или в куче, и тому подобное. В системных языках программисту дают кучу инструментов, которые позволяют чётко описать, как именно (на низком уровне) задача должна быть выполнена. Исходя из задачи, программист может выбрать наиболее эффективный метод. Go не даёт чёткого контроля. Например, у него момент, когда какой-то участок памяти будет освобождён, недетерменирован, и в этом Go близок к какому-нибудь C#.

C#, кстати, никто тоже не мешает компилировать сразу в нативный код, включая в исполняемый файл его жирный рантайм. Microsoft для некоторых платформ предлагает такой вариант. Но это не делает C# системным языком. А ведь C# позволяет явно выделять память на стеке (stackalloc), поддерживаются структуры, и даже есть поддержка указателей в unsafe блоках кода.

На Go можно программировать микроконтроллеры.

Вы точно говорите про микроконтроллеры с их типичными ограничениями типа 2 килобайта RAM? Современные SoC на порядки мощнее этого, но обычно их не называют микроконтроллерами. Насколько я понимаю, Go не может работать без рантайма (кому-то же нужно собирать мусор и управлять его горутинами), и только этот рантайм вряд ли заведётся на типичном микроконтроллере. C, как системный язык, может обходиться без своей C Runtime Library — вы можете писать код, который будет 100% под вашим контролем. Rust, насколько я знаю, также позволяет отключать рантайм. Это конечно же накладывает кучу ограничений, но для некоторых задач это необходимость.

К слову, на C# тоже можно писать под «микроконтроллеры». .NET Micro Framework заводится на SoC с 64КБ RAM и 256КБ флеш-памяти. Это то что вам нужно что-бы что-то совсем примитивное запустить. Хотите поморгать светодиодом? И вот вам сразу нужно уже так много ресурсов. А на старом добром C можно писать целые игрушки для Dendy, у которой всего 2КБ RAM и 32КБ ROM (да, целая Dendy сравнима с современными микроконтроллерами по доступным ресурсам).
0
Вот список железа, на котором работает tiny Go tinygo.org/microcontrollers Я не про все знаю, но на некоторых микроконтроллерах памяти точно не больше 16KiB. Ну и общефилософски, а какая, собственно, разница, кто и где выделяет память? При ручном управлении есть свои техники работы с ней, при автоматическом свои, которые позволяют не запускать GC. В Go хороший escape-анализ для переменных, который может определить, понадобиться ли в runtime сборщик или нет, и (моя гипотеза) может его не включать в образ, если в нём нет необходимости.
0
Разница в скорости (на стеке память выделяется на порядок быстрее чем в куче), и в некоторых проектах может быть критически важно, когда именно освободится та или иная память, особенно если её всего несколько килобайт.

Напомню, что речь изначально шла о том, является ли Go системным языком программирования, а не о том, что он плохой или хороший язык сам по себе. Его создавали для разработки микро-сервисов, и для этого он подходит хорошо. Но он слишком высокоуровневый (скрывает много деталей от программиста) и недетерменированный, чтобы называть его системным языком.
0
>>Оператора перегрузки

Вы имели в виду перегрузку операторов?
0
Да, спасибо. Проверил в документации:
The design goals of Odin were explicitness and simplicity. Operator overloading is very easily abused and can be used to do many magical things. A procedure is clearer and more explicit. Array programming is available in Odin; this removes some of the need for operator overloading when creating mathematical libraries.
0
А при призношении названия этого нового языка ударение в нём делать — на первый слог?
+3
Нет, скорее всего язык не будет принят сообществом и не выйдет из беты. Тогда Билл Джинджер учтёт ошибки и запилит язык программирования Dva
0

А если операторы перевести на русский, получится Odin-C...

0
И опять не компилятор, а интерпретатор через llvm. И чем это лучше того же оберона или паскаля?
+1
До сих пор не могу понять зачем индустрия хоронит Паскаль чтобы потом переизобретать его заново.
0

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

+1
Хочу спросить: а каков смысл существования этого языка, если есть Rust и Go? Каждый из языков отлично исполняет свои задачи. На Rust вообще можно ОС запилить, что с ним не так?
0
Могу поспорить, после C/C++: Rust просто няшный язык.
Да, там можно по желанию заниматься садо-мазо в стиле С, но он даже для новичков вполне дружествен.
+1
А какое садо-мазо есть в Си? IMHO, Си — один из самых удобных языков, созданных к настоящему времени.

P.S. Подумалось, что к теме садо-мазо ближе Rust. Он программисту говорит: «эй, программист, так делать низя!» — и бьёт за это по рукам :) Это, конечно, не означает, что Rust — плохой язык
0
Это нам удобный, а подавляющее большинство «новых» кодеров даже не в курсе таких вещей как руками выделить память и освободить. В таком случае Rust и Go решают часть проблем.
И теперь можно вернутся к теме — так зачем какой-то новый язык, если существующие покрывают все потребности?

P.S.: Rust не бьет по рукам, там есть возможность перейти на полный unmanaged, если у кодера хватит духа =) Суть в том, что оба языка дают работать в safe зоне, и при том не терять производительность. Да, я Rust только начал изучать — и прозрел, это тот язык, который после С мне нравится.
+2
А какое садо-мазо есть в Си?

  1. undefined behaviour
  2. слабая типизация
  3. отсутствие умных указателей и безопасных строк, и инструментов для полноценной реализации этого на уровне языка.
    Да, при должном внимании, опыте и сосредоточенности все вышеописанное не помешает вам писать качественный и надёжный код.
    Но человеческий фактор это такая штука, что избежать его, к сожалению, полностью невозможно в принципе, и рано или поздно он все равно проявится в любом проекте.
0
Благодарю за толкование «садо-мазо» в С. Я не умею в воду и теорию и Вы всё правильно описали. Как старику по С — нет проблем, но новым кодерам это доставляет боль.
+1
Нафиг он нужен? По моему существующих языков достаточно, что бы решить любую задачу.
0
Надо форкнуть и назвать Dva

А то мало таких языков как-то
+1
Автор языка молодец, довел проект хотя-бы до беты. Хотя возможно на LLVM это не так уж и сложно. А мне свой язык все никак даже толком не начать, хотя идей и материалов достаточно, пока лишь иногда структурирую документацию. В свое время начал перерабатывать компилятор D, именно потому что там все свое, включая кодогенерацию.
+1
Затем, зачем создавались и другие языки. Вы же не на ассемблере программируете, правда ведь? Да, уже существует куча языков, но ни один из них не идеален. Кто знает, может быть, кто-то при разработке собственного языка реализует какую-то гениальную идею, до которой ранее никто не додумывался…
0
Все верно, и от этого другие языки будут тоже менятся.)
Да, в принципе, это и происходит.
+2

Рынок языков насытился. В начале девяностых можно было в одиночку написать что-то типа PHP / Python / Ruby и оно сразу набирало критическую массу пользователей, потому что за неимением альтернатив это было лучше, чем ничего. Сейчас же языков много и чтобы с ними серьезно конкурировать, недостаточно просто придумать красивый синтаксис и реализовать компилятор: нужно еще иметь поддержку среды разработки, библиотеки, документацию, примеры, да и вообще демонстрировать какую-то гарантию того, что проект не заглохнет через пару месяцев. А такое могут себе позволить только крупные компании или научные заведения с приличными бюджетами.

+1
Люди обычно создают новые языки программирования не для того, чтобы на них заработать, а потому что им это интересно. Кому-то нравится строить программы из готовых блоков, а кому-то хочется заниматься более фундаментальными вещами.

Да и многие из существующих языков выросли из персональных проектов. Тот же Rust, который поддерживается Mozilla, изначально был персональным проектом одного из сотрудников. Если у вашего языка есть какая-то уникальная фишка — его вполне могут заметить и профинансировать, или хотя бы позаимствовать вашу идею для новой версии уже существующего языка, что тоже достижение.
0
Люди обычно создают новые языки программирования не для того, чтобы на них заработать, а потому что им это интересно.
Самовыражение довольно быстро затухает без признания со стороны. Вопреки ожиданиям многих разработчиков языков, признание само по себе не приходит и даже с революционностью его разработки кореллирует мало.

Языки сами по себе — всегда убыточная область. Зарабатывают в основном на смежных с ними вещах — тренингах, инструментарии, библиотеках, или экосистеме в целом.

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

Инструментарий разработки языков упростился существенно даже с тех пор, когда создание трансляторов было упражнением для студентов младших курсов в хорших вузах. В наши дни совсем не так тяжело запилить с нуля свой идеальный язык программирования и сделать на нём игру (популярный вариант). Много такого рода проектов в интернете. Так что, если автор адекват и не хочет сделать сразу убийцу Haskell или Си++, то почему бы и нет? Для мелких приложений вполне себе вариант, да ещё и с ненулевой вероятностью словить хайп вокруг проекта. Поэтому нас ждёт, мне кажется, наоборот, эпоха яростного языкотворчества, которая закончится тем, что всем наскучат игры с синтаксисом, и народ найдёт счастье в чём-нибудь Lisp-подобном.

+1

Сделать мини-язык под собственные нужды или написать курсовую в вузе — это легко. А вот реализовать язык, люди со стороны будут готовы использовать в продакшене — это небо и земля по сравнению с предыдущими примерами. Разработка инструментария немного упростилась, но требования к промышленному языку увеличились гораздо сильнее.

0
Большинство популярных языков изначально создавались, как языки под собственные нужды. Хоть Си взять, хоть Rust, хоть Basic, хоть Scheme, хоть Python. Даже Java. Единственные живые исключения, пожалуй, Fortran и Си++
0

Ваш пример подтверждает мои слова :) C, Basic, Scheme, Python, Java — все появились более 20 лет назад, когда ситуация была иная. Rust — недавно, но при поддержке Mozilla.


Сколько вы знаете популярных языков, которые появились в последние 10 лет и не были спонсированы корпорацией?

0
Сложно понять, что считать популярным. Но Clojure, наверняка, попадает в эту категорию. Да и потом, кто знает, что и почему взлетит в следующие 10 лет? Корпорации не вечны, а вкусы меняются.
0

Clojure сложно назвать "новым языком" — это же по сути JVM-реализация LISP, которому уже за полтинник.


Спекулировать насчет меняющихся вкусов можно долго, но статистика говорит об обратном: шанс "взлететь" без поддержки сравним с шансом выиграть в лотерею. Впрочем, ни покупателей билетов, ни разработчиков языков это не останавливает :)

0

Так, собственно, как ничего не останавливаеь разработчиков прочих велосипедов. Раз уж Lisp упомянули, то вся наша текущая экосистема была уже разработана в 80-ых, выкинута на помойку по непонятным причинам, а потом переизобретена заново. Такова уж особенность индустрии

0

P.S. Clojure, всё же, совсем не Lisp по своей семантике. От Lisp он гораздо дальше, чем вот этот самый Odin от Go.

+2
Ну мне всегда были интересны именно языки программирования. Соответственно мозг работает в этом направлении. За 15+ лет программирования, борьбы с кривизной реального кода и несовершенством компиляторов и прочих инструментов разработки накопилось множество идей, которые я старательно записывал:) Сейчас это уже репозиторий на 15 мегабайт текстовых заметок.
Only those users with full accounts are able to leave comments. , please.