Опенсорс проект на Rust

Хочу написать на Rust свои: язык программирования, базу данных, сервер, возможно и другие модули.

Язык программирования будет интерпретируемым. Фишка языка в том, что в нём не будет зарезервированных слов, а будет только синтаксис из спецсимволов, все переменные и объекты это слова которые можно писать на кириллице\латинице. При инициализации можно подключать разные модули в зависимости от потребности, так же можно будет написать свои модули для языка на Rust и подключать их при необходимости.

План действий. Сначала создадим библиотеки для работы с диском, строками, сетью и др. при необходимости. Далее ядро самого языка. Затем тестирование и доработка. Как самое основное будет готово сделаем релиз, сайт проекта с документацией.

Кому интересно поучаствовать в разработке?

Git: https://github.com/arbnet/adiutor

0

Сообщение от D1973 ОС, наверное, не меньше... Ждем-с

Свой язык, свой компилятор, ОС, Офис, антивирус, БИОС, нескучные обои, своё железо из не будем говорить чего...

0

Сообщение от pgb Во-вторых у меня не просто база данных будет, а модуль к языку программирования, язык будет получать\передавать данные в базу и обратно, и работать с этими данными без прокладки Sql

Ну т.е. вы изобретете свой ОРМ. От которых все нормальные люди только плюются и отказываются, а вы только делать решили.

Сообщение от pgb Тут дело не в уникальности, а в том что это будет просто модуль к языку через который быстро можно получать данные и передавать без прокладки в виде sql, ведь все манипуляции(выборку и прочее) с данными можно делать и в самом языке.

А зачем, если можно манипулировать данными на SQL? Ведь если ваш язык будет ограничен - то значит рано или поздно вы столкнетесь с проблемами, когда не сможете реализовать некую специфичную возможность БД на нём. Придётся костылями прикручивать SQL и получать мешанину языков. Собственно, это проблема с которой сталкиваются разработчики любой ОРМ. А если ваш язык не ограничен - то вы получается изобретете SQL... Что так, что эдак смысла никакого.
Чего только люди не придумают, чтобы не писать на SQL.

0

Сообщение от pgb Ну да, это самое важное.., а то что бы помочь в реализации на это у вас ума не хватает к сожалению..

Помогать надо с реализацией тех проектов в которых есть потенциал. Ваши гарантировано ни когда не взлетят.

Присоединяюсь к большинству выше написаваших:
- Гит вы так до сих пор и не поняли зачем он нужен.
- Про тесты вы точно так же ни чего не поняли. Между тем как раз при написании языка их важность сильно выше. Собственно даже ваша фраза:

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

говорит о том, что вы вообще ни чего не поняли из того что вам пытались донести... Даже не понимаете, что и для чего тестируется....

Добавлено через 1 минуту

1

Сообщение от Катафалк Ну т.е. вы изобретете свой ОРМ. От которых все нормальные люди только плюются и отказываются, а вы только делать решили.

Ещё раз говорю, это будет просто модуль для записи и чтения данных с простым указанием где и какие данные надо записать\получить, всё. Остальные манипуляции будут выполнятся в самом языке. Вы хоть знаете что такое ORM? Прежде чем писать тут бред и делать выводы что я изобретаю тут ORM. Кстати ORM у меня есть в моём фреймворке и это никаким образом не относится к программированию на более низком уровне для работы с большими объёмами данных.

Если вы плюётесь от ORM то это не значит, что вы нормальный... наоборот ORM упрощает работу.

Сообщение от Катафалк А зачем, если можно манипулировать данными на SQL? Ведь если ваш язык будет ограничен - то значит рано или поздно вы столкнетесь с проблемами, когда не сможете реализовать некую специфичную возможность БД на нём. Придётся костылями прикручивать SQL и получать мешанину языков. Собственно, это проблема с которой сталкиваются разработчики любой ОРМ. А если ваш язык не ограничен - то вы получается изобретете SQL... Что так, что эдак смысла никакого. Чего только люди не придумают, чтобы не писать на SQL.

Опять тупые вопросы.. А затем что для манипулирования данными не нужна прокладка в виде Sql к тому же очень ограниченная и медлительная, всё лучше делать сразу в языке, никаких преимуществ использования Sql нет, кроме как написания запросов понятным для человека языком и существования базы как независимой среды.

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

0

Сообщение от Катафалк А зачем, если можно манипулировать данными на SQL?

Отвечу за ТС... Все укладывается же в его концепцию - на замену всему свой велосипед. SQL так же знает посредственно (и это было видно на его "фреймворке") - "значит это ненужная хрень, и вместо нее будет свой велик, который будет проще и быстрее")

Добавлено через 3 минуты

Сообщение от pgb прокладка в виде Sql к тому же очень ограниченная и медлительная

Еще один перл от супер грамотного и опытного.... Вот прям таки сам SQL тормозит?

1

Сообщение от pgb Фишка языка в том, что в нём не будет зарезервированных слов, а будет только синтаксис из спецсимволов, все переменные и объекты это слова которые можно писать на кириллице\латинице.

Ну, кстати, минимум один такой достаточно распространенный язык существует - Пролог. Латиница используется только в названиях предикатов, скажем так, "стандартной библиотеки", без которых можно обойтись (а можно и переопределить), а также некоторых операторах (что тоже переопределяемо при желании).

Кстати, своя реализация базы данных в нем тоже есть.

0

Сообщение от pgb Опять тупые вопросы.. А затем что для манипулирования данными не нужна прокладка в виде Sql к тому же очень ограниченная и медлительная

Лолшто? SQL, нативный язык БД, ограниченный и медлительный? Очень будет интересно конечно посмотреть тогда на ваш не медлительный.

Сообщение от pgb никаких преимуществ использования Sql нет

Преимущество работы с SQL очевидно - это работа непосредственно с БД, без прослоек типа вашего языка с подключаемым модулем, ОРМ, или как бы вы ещё это не назвали.

Сообщение от pgb взаимодействие базы с языком будет через модуль базы с обычным функционалом.

Это утверждение не говорит ни о чем, ибо практически в любом языке общего назначения, который не SQL, работа с БД производится через подключаемый модуль. Вопрос тут в другом - чем этот ваш модуль будет лучше других модулей, которых уже существует сотни для различных языков. Ваш пример тоже ни о чём не говорит, ибо это стандартный синтаксис для простых запросов, доступный во многих ОРМ.

0

Сообщение от Катафалк Лолшто? SQL, нативный язык БД, ограниченный и медлительный? Очень будет интересно конечно посмотреть тогда на ваш не медлительный.

Особую изюминку этому заявлению о "медлительности SQL" придает то, что это утверждает человек задающий такие вопросы. Я, правда, не знаком с Rust (возможно там есть какие то специальные возможности), но подозреваю, что решение практически аналогично другим ЯП. При этом, ИМХО, человек, который имеет квалификацию оценивать неоправданную "медлительность SQL" такой вопрос и в таком варианте вряд ли задаст.

0

Сообщение от voral Особую изюминку этому заявлению о "медлительности SQL" придает то, что это утверждает человек задающий такие вопросы.

А, это он видимо свою БД писать начал

0

Сообщение от voral Отвечу за ТС...

Вы за себя ответить то не можете, а за меня вам тем-более никогда не ответить.. Кроме того я выше уже ответил.

Сообщение от voral Еще один перл от супер грамотного и опытного.... Вот прям таки сам SQL тормозит?

Перлы как раз от вас постоянно исходят.. Вы хоть соображаете что говорите\спрашиваете? Во-первых Sql это просто язык запросов, он тормозить просто не умеет как вы.. А во-вторых если бы немного подзадумались, то до вас может и дошло, то что в базах данных масса проблем при обработке нескольких запросов одновременно, приходится либо идти в угоду скорости, либо в угоду качества. Да чего я вам тут объясняю вы же никогда своих баз не разрабатывали и даже не интересовались как это делают другие.. А стараетесь тут показаться умными..

Сообщение от Pphantom Ну, кстати, минимум один такой достаточно распространенный язык существует - Пролог

Серьёзно? Вы с какого дуба рухнули.. Вы бы ещё тут привели в пример глиняные таблички..

Сообщение от Катафалк SQL, нативный язык БД, ограниченный и медлительный?

Опять 25.. Sql не может быть быстрый или медленный, речь вообще не о нём, а о самой БД что там производится парсинг этого Sql затем получение данных, а потом ещё и выборка с разными функциями и потом снова преобразование в строку, после чего в модуле языка работы с базой эта срока снова парсится и преобразуется в массив и тд. Вот о чём речь и это всё можно исключить получением только данных и обработкой их в самом языке без прокладки интерпретатора Sql.

Сообщение от Катафалк Преимущество работы с SQL очевидно

Для таких как вы кто не понимает как всё работает, это очевидно.. Учите мат часть...

Сообщение от Катафалк Это утверждение не говорит ни о чем, ибо практически в любом языке общего назначения, который не SQL, работа с БД производится через подключаемый модуль. Вопрос тут в другом - чем этот ваш модуль будет лучше других модулей, которых уже существует сотни для различных языков. Ваш пример тоже ни о чём не говорит, ибо это стандартный синтаксис для простых запросов, доступный во многих ОРМ.

А теперь если подумать?
Я исключаю прокладку в виде Sql, исключаю оболочку в ORM, плюс удобство разработки на новом языке, что ускорит работу и качество. То есть работа будет вестить практически на низком уровне без лишних телодвижений с Sql, ORM и тп. передачей запросов, их обработкой, потом преобразования результата и тд.

Сообщение от voral Особую изюминку этому заявлению о "медлительности SQL" придает то, что это утверждает человек задающий такие вопросы. Я, правда, не знаком с Rust (возможно там есть какие то специальные возможности), но подозреваю, что решение практически аналогично другим ЯП. При этом, ИМХО, человек, который имеет квалификацию оценивать неоправданную "медлительность SQL" такой вопрос и в таком варианте вряд ли задаст.

Не знаешь, а делаешь выводы.. Попробуй вот написать что-то типа класса(в Rust классов как таковых нет), работы с разными файлами и типами данных, позиционировать на нужном числе изменять, удалять, добавлять, вставлять в середину. Может тогда мой вопрос не будет для тебя примитивным. На языках высокого уровня это делается намного проще, а в Rust надо будет хорошенько подумать как это вообще возможно реализовать.

Сообщение от Катафалк А, это он видимо свою БД писать начал

Это видимо вы никогда свою БД не писали. А я писал уже, так что для меня написать БД на другом более современном языке не составит особой сложности. Хотелось бы найти единомышленников или хотя-бы тех кому интересно изучить новый язык и попробовать что-то пописать совместно.

ЗЫ. А тут одни шакалы собрались, только подтявкивать и можете.. такое чувство что сбегаетесь в каждую новую тему чтобы пометить её своими испражнениями..

0

Сообщение от pgb Опять 25.. Sql не может быть быстрый или медленный, речь вообще не о нём, а о самой БД что там производится парсинг этого Sql затем получение данных, а потом ещё и выборка с разными функциями и потом снова преобразование в строку, после чего в модуле языка работы с базой эта срока снова парсится и преобразуется в массив и тд. Вот о чём речь и это всё можно исключить получением только данных и обработкой их в самом языке без прокладки интерпретатора Sql.

И сколько всё это действительно занимает времени на исполнение, в сравнении с непосредственно работой с данным сначала в БД а потом в клиентском коде, вы замеряли?
Я уж молчу, что stored procedures давно уже изобретены, если действительно есть необходимость избавиться.

0

Сообщение от pgb Вы хоть соображаете что говорите\спрашиваете? Во-первых Sql это просто язык запросов, он тормозить просто не умеет как вы..

Смотрю вам на пользу идет форум. Кое что (правда медленными темпами) начинаете познавать и теперь уже не будете нести чушь как в том сообщении . Да вы правильно теперь считаете, что SQL не может сам по себе тормозить.

Сообщение от pgb о что в базах данных масса проблем при обработке нескольких запросов одновременно, приходится либо идти в угоду скорости, либо в угоду качества

Нет там ни каких проблем, которых не будет в каких либо других решениях. Вообще. Либо давайте разбирать конкретику. Даже если вам знания позволят что то назвать, то на 100% это будет и в другом решении тоже... И проблема ваша тут в том, что вы опять свалили все в одну кучу. Т.к. либо вы еще не до конца разобрались, что такое SQL либо не понимаете, что такое база данных и где граница между ними.

Сообщение от pgb Да чего я вам тут объясняю вы же никогда своих баз не разрабатывали и даже не интересовались как это делают другие

А вы разрабатывали? И при этом когда я вам озвучил типовую задачу "мне нужно вывести 5 последних новостей" потребовлось вам ее разжевать и даже написать поясняющий SQL запрос...(т.е. вы тупо даже не знали о сортировке) ну да ну да... Но вернемся к нашим баранам: назовите хоть одну конкретную проблему возникающую при обработке нескольких запросов.

Сообщение от pgb Вот о чём речь и это всё можно исключить получением только данных и обработкой их в самом языке без прокладки интерпретатора Sql.

Я так понимаю для вас база данных это что типа пары табличке на десяток записей. Какой СУБД вы разбирали код? Покажите конкретное место в сырцах и давайте разберем его.

Сообщение от pgb Попробуй вот написать что-то типа класса(в Rust классов как таковых нет), работы с разными файлами и типами данных, позиционировать на нужном числе изменять, удалять, добавлять, вставлять в середину

При чем тут вообще классы? Эта задача ни как вообще не зависит от применения или не применения ООП.

Сообщение от pgb На языках высокого уровня это делается намного проще, а в Rust надо будет хорошенько подумать как это вообще возможно реализовать.

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

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

Сообщение от pgb А я писал уже,

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

1

Сообщение от pgb А затем что для манипулирования данными не нужна прокладка в виде Sql

Но прокладка у тебя будет. Только называться она будет по другому. Если у тебя база будет не файловая (встроенная), а серверная, то сериализованный запрос так или иначе будет. Как ты его не назови. Хотя что толку это объяснять. Видно, что ты этого не понимаешь...

1

Сообщение от pgb Не знаешь, а делаешь выводы.. Попробуй вот написать что-то типа класса(в Rust классов как таковых нет), работы с разными файлами и типами данных, позиционировать на нужном числе изменять, удалять, добавлять, вставлять в середину. Может тогда мой вопрос не будет для тебя примитивным. На языках высокого уровня это делается намного проще, а в Rust надо будет хорошенько подумать как это вообще возможно реализовать.

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

Единственное, примечание, если этот вопрос был реально для реализации СУБД... То напомню, что БД это не только когда в таблице хранится десяток небольших записей. Некоторые таблицы бывает содержат террабайты информации. Надеюсь вы знаете что с этим делать.

0

Сообщение от pgb а о самой БД что там производится парсинг этого Sql затем получение данных, а потом ещё и выборка с разными функциями и потом снова преобразование в строку, после чего в модуле языка работы с базой эта срока снова парсится и преобразуется в массив и тд.

Сразу видно компетентного пользователя баз данных... SQL парсится, но первый раз. Потом план запроса из кеша берётся. Никаких преобразований в строку выборки не происходит. Только у тебя в голове. Выборка возвращается как есть.

0

Чудики.. успокойтесь уже и без вас "супер программистов" всё сделаю

ЗЫ. А вы только отговорки мастаки строчить и свои тупые гипотезы излагать которые ничего не имеют общего с действительностью. Я практик в отличии от вас "теоретиков"..
ЗЗЫ. Есть те кто ищут причину как вы чтобы не делать, а есть те кто видят перспективы и добиваются своего это такие как я.

0

Сообщение от pgb Я практик в отличии от вас "теоретиков"..

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

Сообщение от pgb ЗЗЫ. Есть те кто ищут причину как вы чтобы не делать, а есть те кто видят перспективы и добиваются своего это такие как я.

Что ты добился конкретного, кроме того, что на нескольких форумах тебя считают треплом не отвечающим за свои слова?


Пока только "бла... бла.... бла..."

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

0

pgb, кажется, что вы любую тему можете сразу начинать (и заканчивать) заявлением "вы все вокруг п...сы и только я д'Артаньян". Результат в любом случае окажется тем же, что и сейчас, но зато без затрат времени тех, кто по неопытности пытается вам что-то объяснить.

1

Сообщение от voral Если бы ты был практик, то ты показал листинг из существующей СУБД в подтверждение своих слов про тормознутость. Если бы ты был практик, то у тебя бы хоть что то было, что можно было показать.

У меня есть масса реализаций на разных языках и баз данных и своего языка, интерпретации и др. Некоторые вещи не доделанные, некоторые заброшены из-за проблем сторонних библиотек и тд. я знаю многие проблемы связанные с теми или иными решениями и много чего ещё... Ты видел мой сырой фреймворк так что не надо тут трепать что я ничего не показываю..

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

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

Сообщение от Pphantom pgb, кажется, что вы любую тему можете сразу начинать (и заканчивать) заявлением "вы все вокруг п...сы и только я д'Артаньян". Результат в любом случае окажется тем же, что и сейчас, но зато без затрат времени тех, кто по неопытности пытается вам что-то объяснить.

Что вы тут объяснили? Что мне не нужно делать то что я делаю? Если вы не можете помочь, то ваши объяснения в том что мне не надо делать свой язык с БД и сервером тут не канают. Это вам лучше не лезть в мои темы и не срать тут своей тупостью..

0

Сообщение от pgb У меня есть масса реализаций на разных языках и баз данных и своего языка, интерпретации и др. Некоторые вещи не доделанные, некоторые заброшены из-за проблем сторонних библиотек и тд. я знаю многие проблемы связанные с теми или иными решениями и много чего ещё...

Что очень закономерно... Т.е у вас есть куча начатых и заброшенных вещей + сырой "фреймворк".....

Осталось осознать, что у вас не хватает знаний доделать даже относительно простые вещи, а вы хотите написать язык да еще и СУБД. При этом по прежнему не желаете углублять свои знания в областях необходимых для решения такого класса задач.

Добавлено через 3 минуты

Сообщение от pgb я знаю многие проблемы связанные с теми или иными решениями и много чего ещё

В подобных спорах "знаю многие" строго соответсвует "не знаю ни одной". Ни разу ни по одному поводу вы не смогли выдать ни чего конкретного.... Хотя вру... При обсуждении визивика напсианого на javascript (точнее даже обертки для него написанной на vue). Вы выдали, что он плохой потому что в нем много файлов. (совершенно не понимая, чем отличаются файлы исходников JavaScript и окончательный скрипт подключаемый на проде)

0