а
Т-34 85
так они даже свою стандартную библиотеку не то, что без ансейфа не смогли написать, так там ещё и UB
где там UB кстати?
Size: a a a
2020 March 06
G
Т-34 85
так они даже свою стандартную библиотеку не то, что без ансейфа не смогли написать, так там ещё и UB
Лол
Т8
где там UB кстати?
а что, хочешь сказать, что нет?
IL
Т-34 85
мне надо как в плюсах. Раст так не может, тогда зачем он нужен?
Самый странный аргумент
MB
Т-34 85
а что, хочешь сказать, что нет?
из недавнего https://github.com/rust-lang/rust/issues/68206
MB
Ой, я это @rust_power адресовал
TS
И что это доказывает?
имхо, что не удобно писать на расте, надо прибегать к использованию unsafe чтоб добиться оптимальной производительности, более сложные структуры данных реализовать будет сложно, а без них будет сложнее добиться оптимальной производительности,
таким образом, для написания кода на расте понадобиться больше человека часов, чем на том же Си
Отсюда можно сделать вывод, что kernel на расте не взлетит
таким образом, для написания кода на расте понадобиться больше человека часов, чем на том же Си
Отсюда можно сделать вывод, что kernel на расте не взлетит
а
Т-34 85
а что, хочешь сказать, что нет?
нет, я прошу тебя уточнить что ты имеешь ввиду. я ничего не утвеждала
а
Ой, я это @rust_power адресовал
ок
Т8
нет, я прошу тебя уточнить что ты имеешь ввиду. я ничего не утвеждала
а
Т-34 85
спс
а
Т-34 85
прикольно)
MB
имхо, что не удобно писать на расте, надо прибегать к использованию unsafe чтоб добиться оптимальной производительности, более сложные структуры данных реализовать будет сложно, а без них будет сложнее добиться оптимальной производительности,
таким образом, для написания кода на расте понадобиться больше человека часов, чем на том же Си
Отсюда можно сделать вывод, что kernel на расте не взлетит
таким образом, для написания кода на расте понадобиться больше человека часов, чем на том же Си
Отсюда можно сделать вывод, что kernel на расте не взлетит
Это лишь доказывает , что в linux kernel'e будет существовать ансейф код. Это не доказывает, что весь код ядра будет ансейфным.
Я соглашусь с тем, что при написании эффективных коллекций трудно обойтись без ансейфа. Но мне вот с виду кажется, что например реализаций двусвязного списка будет 2-3 на все ядро (потому что каждая из них будет обобщенной, и будет использоваться в куче мест).
Так что код всяких структур данных не составляет большой доли в объеме.
Открываю рандомный файл (https://github.com/torvalds/linux/blob/master/include/crypto/aead.h) и не вижу никаких коллекций, например.
Я соглашусь с тем, что при написании эффективных коллекций трудно обойтись без ансейфа. Но мне вот с виду кажется, что например реализаций двусвязного списка будет 2-3 на все ядро (потому что каждая из них будет обобщенной, и будет использоваться в куче мест).
Так что код всяких структур данных не составляет большой доли в объеме.
Открываю рандомный файл (https://github.com/torvalds/linux/blob/master/include/crypto/aead.h) и не вижу никаких коллекций, например.
VD
Это лишь доказывает , что в linux kernel'e будет существовать ансейф код. Это не доказывает, что весь код ядра будет ансейфным.
Я соглашусь с тем, что при написании эффективных коллекций трудно обойтись без ансейфа. Но мне вот с виду кажется, что например реализаций двусвязного списка будет 2-3 на все ядро (потому что каждая из них будет обобщенной, и будет использоваться в куче мест).
Так что код всяких структур данных не составляет большой доли в объеме.
Открываю рандомный файл (https://github.com/torvalds/linux/blob/master/include/crypto/aead.h) и не вижу никаких коллекций, например.
Я соглашусь с тем, что при написании эффективных коллекций трудно обойтись без ансейфа. Но мне вот с виду кажется, что например реализаций двусвязного списка будет 2-3 на все ядро (потому что каждая из них будет обобщенной, и будет использоваться в куче мест).
Так что код всяких структур данных не составляет большой доли в объеме.
Открываю рандомный файл (https://github.com/torvalds/linux/blob/master/include/crypto/aead.h) и не вижу никаких коллекций, например.
А я вижу
TS
Это лишь доказывает , что в linux kernel'e будет существовать ансейф код. Это не доказывает, что весь код ядра будет ансейфным.
Я соглашусь с тем, что при написании эффективных коллекций трудно обойтись без ансейфа. Но мне вот с виду кажется, что например реализаций двусвязного списка будет 2-3 на все ядро (потому что каждая из них будет обобщенной, и будет использоваться в куче мест).
Так что код всяких структур данных не составляет большой доли в объеме.
Открываю рандомный файл (https://github.com/torvalds/linux/blob/master/include/crypto/aead.h) и не вижу никаких коллекций, например.
Я соглашусь с тем, что при написании эффективных коллекций трудно обойтись без ансейфа. Но мне вот с виду кажется, что например реализаций двусвязного списка будет 2-3 на все ядро (потому что каждая из них будет обобщенной, и будет использоваться в куче мест).
Так что код всяких структур данных не составляет большой доли в объеме.
Открываю рандомный файл (https://github.com/torvalds/linux/blob/master/include/crypto/aead.h) и не вижу никаких коллекций, например.
А еще! Ну вот как можно писать на языке, который делает то, чего его не просят???
MB
А я вижу
Что я пропустил?
VD
Что я пропустил?
VD
Что это по твоему?
TS
Какой-то скаттерь лист
TS
Ахах