Си - это портабельный ассемблер. Собственно такая задача и ставилась при создании языка. Облегчить написание частей Unix.
По поводу устарел или не устарел. Вот когда его заменят на другой язык при разработке Linux например, вот тогда и можно говорить о старении. А пока он безальтернативен.
Для чего вы вообще создаете пет-проект? Есть вариант - чтобы пройти собеседование.
В этом случае включайте туда все что будет интересовать работодателя.
Читал, что при использовании JOIN индексирование бесполезно.
Вот интересно где ты это читал. Я конечно знаю что мы живем в эпоху "плоской земли". Это когда любой заблуждающийся может найти целое сообщество таких-же заблудших душ. Ну да ладно.
Поскольку разработка под БД и SQL - это практика. То ты можешь подойти с практической стороны. Взять 2 таблицы (желательно поболее 1 гигабафт) и сделатьй JOIN их по PK и ссылочному ключу без индекса. И потом тоже самое с индексом. И не забудь предложение WHERE потому что оно тоже имеет значение.
Вообще индекс в наше время - это trade-off. Сделка по сути. Мы платим налог в виде какого-то % IOPS/CPU во время вставки OLTP транзакций и мы это ПРИНИМАЕМ и соглассны с этим.
Но мы взамен имеем очень короткое время поиска данных или JOIN.
Вообще проверь это все. И не верь никаким писателям.
И мне тоже не верь. Проверяй на своей базе время выборки для всего SELECT.
AHMED_RAPIRA, Rust - это сложный компиллятор. По крайней мере у него есть промежуточный слой LLVM кодогенерации. На этом слое скорее всего будет явно использован тип i8. А после сборки в целевую платформу (x86_64) скорее всего информация об 8 разрядном регистре может быть потеряна и может всплыть регистр AL/AX/EAX как регистр для алгебраических типов и для целых расчетов в принципе.
Попробуй
cargo rustc -- --emit=llvm-ir
и посмотри промежуточный код в текстовом виде.
И потом любым дизассемблером посмотри свой бинарник.
Почему С-разработчики не умеют пользоваться модульными тестами?
Вот ни разу не видел. Java/C# - умеют. Сишники - надеются либо на мануальное тестирование либо просто на ручной коде-ревью. Это не выпад в адрес языка С.
AHMED_RAPIRA, я не буду спорить. Я просто говорю свое предположение на основании наблюдения за ассемблерным кодом. Если у вас есть контр-пример - пожалуйста приведите.
Flesh Herbal, я с вашего позволения не хочу смотреть. Я просто примерно предположу что если у вас нет consistency - то можете просто использовать файловую систему. Это хороший старт. Нулевые накладные. Никакой лишний процесс не создается. PrimaryKey == имя файла. И все write only и работает хорошо. До тех пор пока вы не озвучите дополнительные требования по поиску и индексированию. А поскольку вы не озвучили то вам подходит даже файловая система.
Мне кажется что все современные переводчики - это сервисы. Поэтому вопрос про java - является как-бы ненужным уточнением. Есть rest-сервис - бери пользуйся хоть с Java хоть с Python.
А делать специальное приложение на java смысла нет. Язык сильно быстро эволюционирует. Появляются новые молодежные слова. И любой хардкод справочников слов устаревает очень быстро.
Непонятно какой смысл автор вкладывает в "локально". Ну поставь себе любую dbms на локальный хост - вот и будет локально. И PostgresSQL и MySQL можно поставить.
Если брать какие-то узко-специализированные типа БД на файлах или embed, то там SQL будет ограниченным. Не будете развивать приложение в смысле SQL.
А зачем это вам надо? Хотите быть неразвитым и отсталым?
По поводу устарел или не устарел. Вот когда его заменят на другой язык при разработке Linux например, вот тогда и можно говорить о старении. А пока он безальтернативен.