По-моему вы находитесь в рамках какого-то информационного пузыря. У вас наверное и эрланг это не живучий язык. Ну и статистика показывает что как минимум по популярности C# обходит плюсы и находится на уровне Java.
Не знаю на счет вечности, но чем больше на языке программирования созданно продуктов, тем дольше он будет жить, это частный случай Эффекта Линди . И в этом смысле и C# и С++ и Java и Кобол проществуют еще многие десятилетия, пока радикально не сменится сам фундамент вычислительных машин, например произойдет массовый переход на квантовые компьютеры
кто то решил что если убрать среднее звено управления то все упростится и удешевится, на деле это выглядит как спихивание обязанностей среднего на низшее звено с вытекающими
Это вопрос автоматизации труда и уровня агрессивности рынка. Длинные цепочки управления очень плохо работают при необходимости быстрого принятия решений, есть отличный пример нокиа, как истории провала во много про это.
Посмотрите на взрывной рост единорогов в Индии - финтех, екомерс, ИИ. Знаете почему?
Об Индии нет смысла говорить целиком, она слишком большая. Рост есть в Уттар-Прадеша, во-многом он обязан росту удаленки во время ковида, повышением стоимости труда в остальной азии и войне/санкциям на постсоветском пространстве(огромное количество аутсора перешло в EU, а значит повысились рейты). Это не высокотехнологичный рост, это рост дешёвого аутсорса для западных компаний. Никакого ит чуда в Мумбаи, конечно, не будет, их система трудового законодательства, созданное еще в 50х Индийским национальным конгрессом, где невозможно уволить человека если в компании сто и более занятых, делает экономическое развитие этого региона крайне затруднительным и ит центры как были в EU/US, так и останутся.
Европейские компании давно превратились в призраки
Кто именно призрак, ASML, Siemens, Mistral, Novo Nordisk, Spotify, Airbus, SAP?
Производство само себе ничего не даст, главные вопрос это поиск рынка сбыта, органищация логистики, маркетинга, привлечение инвестиций, разработка стратегии роста, решение юридических вопросов, менеджмент риска, управление и подбор персонала и т.д. И именно этим и занимается "бесполезный" офис в Лондоне.
Ну для меня, как человека который работает в финансовом секторе и имеет базовое экономическое образование помимо инженерного, то, что вы пишете звучит как рассуждения человека, который никогда даже hello world не писал и никогда в it не работал, но при это рассказывает о том как устроена облачная инфраструктура амазона, где у неё узкие места и как она будет масштабироваться. Ответьте себе почему капиталисты платят людям на позиции CTO в десятки раз больше чем синьор программисту, хотя это именно программист фиксит баги и пилит фичи.
Дайте угадаю - экономического образования у вас нет, на роли топ менеджера вы никогда не работали, собственное производства никогда не открывали, но как оно все устроено и чем закончится вы прекрасно знаете?
Не будет, MaybeUninit всегда будет занимать столько же, сколько внутрений тип, в этом собственно и есть его отличие от Option<T>, его ровно для этого сделали. Это не структура с полем на котором может быть паддинг, это не алгебраический тип с тэгом-дискреминатором, это тип-псевдоним, который не существует за пределами исходного кода. Между MaybeUninit<[u8; 4]>> и [u8; 4] нет никакой разницы с точки зрения лейаута по памяти в скомпилированной программе, может сами проверить и убедиться.
Во-первых причем тут динамическая память если пример на стеке аллоцирует, во-вторых это enum и согласно layout энамов раста она занимает ровно 500 байт, в размер самого буфера, присловутые zero-cost abstraction. Даже если вы сделаете Box, у вас точно так же будет 500 байт в куче + оверхед на чанк вашего аллокатора и 8 байт на стеке для указателя.
Ну технически она не содержит ничего кроме буфера. И вы же писали про "невозможность выделить все буфера при инициализации", а не про извлечение неинициализированный буфера без unsafe.
По-моему вы находитесь в рамках какого-то информационного пузыря. У вас наверное и эрланг это не живучий язык. Ну и статистика показывает что как минимум по популярности C# обходит плюсы и находится на уровне Java.
Не знаю на счет вечности, но чем больше на языке программирования созданно продуктов, тем дольше он будет жить, это частный случай Эффекта Линди . И в этом смысле и C# и С++ и Java и Кобол проществуют еще многие десятилетия, пока радикально не сменится сам фундамент вычислительных машин, например произойдет массовый переход на квантовые компьютеры
Вы бы ещё наличию проектов на C++ или Java удивились.
Max конечно же
Кто это говорит? У какого голландского пенсионного фонда сейчас кассовый разрыв?
Проблема с GC и STW всеравно останется.
Это вопрос автоматизации труда и уровня агрессивности рынка. Длинные цепочки управления очень плохо работают при необходимости быстрого принятия решений, есть отличный пример нокиа, как истории провала во много про это.
Об Индии нет смысла говорить целиком, она слишком большая. Рост есть в Уттар-Прадеша, во-многом он обязан росту удаленки во время ковида, повышением стоимости труда в остальной азии и войне/санкциям на постсоветском пространстве(огромное количество аутсора перешло в EU, а значит повысились рейты). Это не высокотехнологичный рост, это рост дешёвого аутсорса для западных компаний. Никакого ит чуда в Мумбаи, конечно, не будет, их система трудового законодательства, созданное еще в 50х Индийским национальным конгрессом, где невозможно уволить человека если в компании сто и более занятых, делает экономическое развитие этого региона крайне затруднительным и ит центры как были в EU/US, так и останутся.
Кто именно призрак, ASML, Siemens, Mistral, Novo Nordisk, Spotify, Airbus, SAP?
Производство само себе ничего не даст, главные вопрос это поиск рынка сбыта, органищация логистики, маркетинга, привлечение инвестиций, разработка стратегии роста, решение юридических вопросов, менеджмент риска, управление и подбор персонала и т.д. И именно этим и занимается "бесполезный" офис в Лондоне.
Ну для меня, как человека который работает в финансовом секторе и имеет базовое экономическое образование помимо инженерного, то, что вы пишете звучит как рассуждения человека, который никогда даже hello world не писал и никогда в it не работал, но при это рассказывает о том как устроена облачная инфраструктура амазона, где у неё узкие места и как она будет масштабироваться. Ответьте себе почему капиталисты платят людям на позиции CTO в десятки раз больше чем синьор программисту, хотя это именно программист фиксит баги и пилит фичи.
Дайте угадаю - экономического образования у вас нет, на роли топ менеджера вы никогда не работали, собственное производства никогда не открывали, но как оно все устроено и чем закончится вы прекрасно знаете?
Обычный синтаксис. Просто вы привыкли к семейству языков, которые идут от В https://en.wikipedia.org/wiki/B_(programming_language), а Раст из семейства языков, которые идут от ML https://en.wikipedia.org/wiki/ML_(programming_language)
ну тогда не надо плакаться что карму сливают.
Я думаю карму скорее сливают за вот такие комментарии.
#[repr(transparent)] в его декларации вы видите? что по-вашему это означает?
Чем по-вашему в расте union отличается от enum?
Не будет, MaybeUninit всегда будет занимать столько же, сколько внутрений тип, в этом собственно и есть его отличие от Option<T>, его ровно для этого сделали. Это не структура с полем на котором может быть паддинг, это не алгебраический тип с тэгом-дискреминатором, это тип-псевдоним, который не существует за пределами исходного кода. Между MaybeUninit<[u8; 4]>> и [u8; 4] нет никакой разницы с точки зрения лейаута по памяти в скомпилированной программе, может сами проверить и убедиться.
Почему в вашем случае нельзя писать как-то так? Unsafe останется только там, где происходит прямая работать с памятью, например в dma модуле.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=dabf667a7a70a9d83a894cedf9ad9946
Во-первых причем тут динамическая память если пример на стеке аллоцирует, во-вторых это enum и согласно layout энамов раста она занимает ровно 500 байт, в размер самого буфера, присловутые zero-cost abstraction. Даже если вы сделаете Box, у вас точно так же будет 500 байт в куче + оверхед на чанк вашего аллокатора и 8 байт на стеке для указателя.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=4ebda6aafb749be9144b39640cf538b1
Ну технически она не содержит ничего кроме буфера. И вы же писали про "невозможность выделить все буфера при инициализации", а не про извлечение неинициализированный буфера без unsafe.
Извините, я все еще не понимаю. Почему нельзя буфер вот так выделить, без unsafe и инициализации нулям?
А что ей тогда не позволяет читать в unsafe блоке из MaybeUninit?