LINUX.ORG.RU
ФорумTalks

Безопасный язык для системного программирования


0

3

Есть успешные? Все знаем, хорошо работает assembler и C, возможно C++.

Есть еще достаточно безопасные и быстрые языки, которые пригодны для написания драйверов, ОС. Или библиотек user space в качестве замены С, тоесть чтобы библиотека не отличалась внешне от обычных библиотек С.

Go похоже не смог заменить, нету серьезного софта, в том числе от гугла на нем. С D непонятно, одни хвалят, но по факту все равно никому он не нужен. Так что, остается С?

★★★★★

для написания драйверов, ОС

м-да. Ну попробуй напиши драйвер для линукса на хаскеле.

Bad_ptr ★★★★★
()

Не существует. Попытки создать пока проваливаются.

tailgunner ★★★★★
()

JS

Десктопный софт на нем пишут, мобильный пишут, прикладной пишут, даже ОСи пишут

derlafff ★★★★★
()
Последнее исправление: derlafff (всего исправлений: 1)

Ух, читая книгу про STL я бы не назвал бы C++ безопасным за каждый чих топором по шарам

frozenix ★★★
()
Ответ на: комментарий от pylin

наваяли на нём окружение, запускаемое «на железе». movitz называется. проект вроде помре. из вики:

Movitz is an implementation of the Common Lisp programming language for x86 computers. It runs with no underlying operating system and is intended as "a development platform for operating system kernels, embedded, and single-purpose applications".
Satan_Klaus ★★
()

1) что не устраивает в перечисленных языках?
2) что значит «безопасный»?

shty ★★★★★
()

Зачем искать замену C, если он практически идеален?

Solace ★★
()

вы забыли другие языки из состава gcc, а именно:

  • ada
  • objective-c
  • objective-c++
  • fortran
AGUtilities ★★★
()

чем плюсы плохи? Если не пытаться почесать правое ухо левой пяткой, то все норм

Vernat ★★
()

Тут два эпитета взаимоисключающиеся. «безопасный» и «системного»... ИМХО системное програмирование в том то и заключается что ты разрабатываешь ПО используя опасные технологии, собственно прямой доступ к памяти тому самый яркий пример.

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

Jetty ★★★★★
()
Ответ на: комментарий от Jetty

Тут два эпитета взаимоисключающиеся. «безопасный» и «системного»...

Что до безопасности, то она должна обеспечиваться не языком, а рантаймом и компилятором

Так она должна обеспечиваться компилятором или взаимоисключающие эпитеты? :)

tailgunner ★★★★★
()

Самый безопасный — это тот, который не существует.

/thread

beastie ★★★★★
()

Вам только красные линии черным цветом подавай.

melkor217 ★★★★★
()
Ответ на: комментарий от tailgunner

Так ведь и С в наши дни не в чести. Не так уж много на нём пишут (ядро не в счёт, это особый случай). Я, например. :) Уже привык этой «убогостью» обходиться, хотя иной раз пожалеешь о том, что нету списков, векторов или ещё чего-нибудь покруче. Но я к С уже «прирос». :)

DeVliegendeHollander ★★
()

Драйвера и ОС можно писать хоть на паскале.

DNA_Seq ★★☆☆☆
()

FPC... Еще можешь глянуть modula-2, компилятор GNU по адресу http://www.nongnu.org/gm2/about.html

Язык хороший, разработчики ламповые, в помощи не откажут и сами не откажутся.

chinarulezzz ★★
()
Ответ на: комментарий от tailgunner

«взаимоисключающие эпитеты» в нашей реальности и в наше время. Однако все может измениться.... как только Таненбаум закончит свою идеальную ОС :)

Jetty ★★★★★
()
Ответ на: комментарий от tailgunner

В Си не устраивает убогая система типов.

я не понял, тебе не нравится конкретно что в системе типов Си? если рассматривать ситуацию в разрезе системного программирования, конечно

shty ★★★★★
()
Ответ на: комментарий от Jetty

фактически именно компилятор должен выяснять все потенциально проблемные участки кода(а для этого он должен быть четко осведомлен о конечной архитектуре и среде выполнения)

ага, а также о решаемой тобой задаче...

- пап, а люди вкусные?
- да сынок, это фантастика

shty ★★★★★
()

Смотря что считать системным программированием. Если ядра писать --- то там асм с Си (и то, Си слишком высокоуровнев). А если к системному программированию отнести, например, компиляторы, то их популярно писать на языках с pattern matching-ом, вроде ML или Haskell, которые сплошь безопасные.

kike
()

C++ отсюда вычеркни. Любой, кто пытается написать что-то околосистемное на С++ - Full of BS. Nuff^WLinus said!
Это раз.
Два, а ЗАЧЕМ искать замену тому, что отлично выполняет свои функции?

AiFiLTr0 ★★★★★
()
Ответ на: комментарий от kike

А если к системному программированию отнести, например, компиляторы, то их популярно писать на языках с pattern matching-ом, вроде ML или Haskell, которые сплошь безопасные.

да-да, какой популярный компилятор не возьми - все на или на мл или на хаскеле

shty ★★★★★
()
Ответ на: комментарий от AiFiLTr0

Любой, кто пытается написать что-то околосистемное на С++ - Full of BS. Nuff^WLinus said! Это раз.

пусть твой «эторас» сначала синдром си-хакера вылечит

shty ★★★★★
()
Ответ на: комментарий от frozenix

Человек, пишущий драйвера может схватить топором по шарам просто потому, что не уследил за температурой платы. Язык в этому случае вообще ни при чем.

trex6 ★★★★★
()

ТС, не будь голословным!

Напиши модуль ядра на питоне! Удиви нас!

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от tailgunner

В Си не устраивает убогая система типов.

Чуть не подавился!

Какая же она убогая? Все, что нужно, в сях есть! А если не хватает — делай свой.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от mr_doug

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

Eddy_Em ☆☆☆☆☆
()

Безопасный язык для системного программирования

Для этого специально собирались и изобрели
Аду.

gensym ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.