Опубликован релиз языка программирования общего назначения Rust 1.72, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59656

• Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 21:52 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Иваня, 01:54 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,An2, 02:25 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 03:31 , 25-Авг-23
      • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 04:31 , 25-Авг-23
      • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,penetrator, 05:36 , 25-Авг-23
      • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 09:23 , 25-Авг-23
        • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Пряник, 09:41 , 25-Авг-23
          • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 09:57 , 25-Авг-23
            • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 10:20 , 25-Авг-23
            • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,User, 11:01 , 25-Авг-23
              • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 13:40 , 25-Авг-23
                • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,User, 14:05 , 25-Авг-23
            • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 15:04 , 25-Авг-23
            • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Пряник, 12:48 , 29-Авг-23
• Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,pin, 21:53 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 21:56 , 24-Авг-23
    • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,pin, 22:25 , 24-Авг-23
    • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,пох., 23:02 , 24-Авг-23
    • Выпуск Rust 1.72. Решение поставлять макрос  serde_derive то...,Аноним, 13:12 , 25-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 22:06 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 08:32 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,1, 09:39 , 25-Авг-23
      • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 10:17 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 11:57 , 26-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Anonymous116723333333333, 22:06 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,burjui, 01:47 , 25-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Минона, 10:14 , 25-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Tron is Whistling, 22:07 , 24-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 22:09 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноньимъ, 08:49 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 13:09 , 27-Авг-23
      • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноньимъ, 14:26 , 27-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 22:10 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 22:12 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним2, 22:18 , 24-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 06:43 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Ананимус, 15:07 , 25-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноньимъ, 11:09 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Серб, 11:36 , 25-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,НяшМяш, 22:20 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 22:26 , 24-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,pin, 22:27 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,An2, 02:29 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Прохожий, 21:41 , 26-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,12yoexpert, 10:05 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,НяшМяш, 13:01 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,freecoder, 13:12 , 25-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Минона, 10:23 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 06:21 , 26-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 20:05 , 25-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 22:21 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,12yoexpert, 10:06 , 25-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Ananimus, 22:28 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 22:44 , 24-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Ananimus, 23:13 , 24-Авг-23
      • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Витюшка, 23:57 , 24-Авг-23
        • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Ananimus, 00:20 , 25-Авг-23
          • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 02:15 , 25-Авг-23
            • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,An2, 02:35 , 25-Авг-23
          • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Пряник, 09:46 , 25-Авг-23
            • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 20:12 , 25-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 22:40 , 24-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Анонин, 23:42 , 24-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 00:05 , 25-Авг-23
      • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Анонин, 00:07 , 25-Авг-23
        • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 11:20 , 26-Авг-23
      • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноньимъ, 11:17 , 25-Авг-23
        • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 11:18 , 26-Авг-23
          • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноньимъ, 15:25 , 26-Авг-23
            • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 13:31 , 27-Авг-23
              • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноньимъ, 14:24 , 27-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,_kp, 03:00 , 25-Авг-23
      • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 10:27 , 25-Авг-23
        • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,_kp, 19:37 , 26-Авг-23
  • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,12yoexpert, 10:07 , 25-Авг-23
    • Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,Аноним, 11:16 , 26-Авг-23
• Выпуск Rust 1.72. Решение поставлять пакет serde_derive толь...,pashev.ru, 22:49 , 24-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 23:34 , 24-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 07:25 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:50 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,ALTruist_linux, 10:00 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,пох., 10:42 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Прохожий, 22:10 , 26-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 23:48 , 24-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ananimus, 23:50 , 24-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,burjui, 01:44 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,_, 04:13 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,burjui, 09:48 , 25-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:53 , 25-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,burjui, 12:55 , 25-Авг-23
            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,_, 17:29 , 26-Авг-23
              • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,burjui, 14:52 , 27-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:10 , 25-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноньимъ, 11:21 , 25-Авг-23
            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 11:43 , 25-Авг-23
              • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,morphe, 12:37 , 25-Авг-23
                • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 12:49 , 25-Авг-23
                  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 13:22 , 25-Авг-23
                    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 14:16 , 25-Авг-23
                      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 14:19 , 25-Авг-23
                        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 14:32 , 25-Авг-23
                          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 14:52 , 25-Авг-23
                            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 15:07 , 25-Авг-23
                              • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 15:31 , 25-Авг-23
                                • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:03 , 27-Авг-23
                                  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 18:15 , 27-Авг-23
                                    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 19:07 , 27-Авг-23
                                      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 21:06 , 27-Авг-23
                                        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 23:10 , 27-Авг-23
                                          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 12:48 , 28-Авг-23
                                          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 12:51 , 28-Авг-23
                                            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 15:54 , 28-Авг-23
                                              • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 16:14 , 28-Авг-23
                                                • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 17:45 , 28-Авг-23
                                                  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 13:27 , 29-Авг-23
                                                    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 16:09 , 29-Авг-23
                                                      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 16:55 , 31-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,burjui, 18:01 , 25-Авг-23
            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 21:43 , 25-Авг-23
            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Someone, 22:36 , 25-Авг-23
              • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,_, 17:38 , 26-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Someone, 22:27 , 25-Авг-23
            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 01:18 , 26-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:10 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Минона, 10:32 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:34 , 25-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,morphe, 23:47 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 13:26 , 25-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:47 , 26-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Someone, 22:39 , 25-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:56 , 26-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 11:27 , 26-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Твайлайт Спаркл, 06:43 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,burjui, 18:07 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,eganru, 08:35 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:45 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,eganru, 13:22 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 13:23 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Someone, 22:42 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Вы забыли заполнить поле Name, 00:26 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,burjui, 01:58 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 07:57 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 11:05 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноньимъ, 08:53 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:43 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,пох., 10:44 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Прохожий, 22:25 , 26-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 13:42 , 31-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,1, 09:47 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,пох., 10:45 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,burjui, 09:53 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 12:39 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,НяшМяш, 13:07 , 25-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Вы забыли заполнить поле Name, 23:55 , 25-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,НяшМяш, 00:48 , 26-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 08:53 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:01 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:08 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:40 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:50 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:59 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:59 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:55 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:03 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,eganru, 10:09 , 25-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:11 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,12yoexpert, 10:12 , 25-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:17 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:18 , 25-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 14:01 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,12yoexpert, 10:11 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:16 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 11:10 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 09:58 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 13:32 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 13:48 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 13:55 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 14:27 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Вы забыли заполнить поле Name, 21:03 , 26-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 21:30 , 26-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Вы забыли заполнить поле Name, 00:06 , 29-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 10:10 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,User, 12:39 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Glenorman, 12:43 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 13:00 , 25-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 15:57 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,xsignal, 13:08 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 16:21 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Прохожий, 22:36 , 26-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 22:53 , 26-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 00:41 , 27-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Вы забыли заполнить поле Name, 16:39 , 27-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 13:38 , 25-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 21:11 , 25-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Могилла, 22:38 , 25-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 13:34 , 31-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ан, 07:20 , 26-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 07:25 , 26-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 12:12 , 26-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 11:41 , 26-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ан, 19:12 , 26-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 22:45 , 26-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 22:56 , 26-Авг-23
            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 00:18 , 27-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ан, 06:09 , 28-Авг-23
            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 12:45 , 28-Авг-23
              • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ан, 19:06 , 29-Авг-23
                • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 16:51 , 31-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Прохожий, 22:39 , 26-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ан, 06:47 , 28-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ананимус, 12:46 , 28-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Ан, 19:16 , 29-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 12:32 , 29-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,BeLord, 09:46 , 28-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,VladSh, 22:23 , 02-Сен-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,gdg, 20:25 , 26-Авг-23
  • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 13:35 , 27-Авг-23
    • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,gdg, 14:00 , 27-Авг-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,gdg, 14:01 , 27-Авг-23
        • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 23:30 , 27-Авг-23
          • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,gdg, 23:50 , 27-Авг-23
            • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 12:10 , 28-Авг-23
              • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,gdg, 16:25 , 28-Авг-23
                • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 21:16 , 28-Авг-23
              • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Аноним, 13:30 , 31-Авг-23
                • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,freecoder, 15:16 , 01-Сен-23
      • Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,yet another anonymous, 22:38 , 28-Авг-23
• Выпуск Rust 1.72. Поставка пакета serde_derive только в ском...,Andrewpotam, 19:26 , 01-Сен-23

Ни на чём этот язык не сфокусирован. Обычное шило на мыло.

Потому я выбрал Golang для прототипирования и C++ для продакшена.

Значительно ли повысилась производительность и уменьшилось потребление памяти?

>Golang для прототипирования

А почему именно Го, а не python?

Потому что Python уже выбрал я, пришлось из оставшихся вариантов выбирать

и то УГ и то УГ, наваять на коленке что-то сойдет, но называть это "прототипированием" я бы не стал

Потому что у Python мерзкий синтаксис.

Попался криворукий.

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

Такого уже лет 10 как не встретишь. А то и больше

А я вот минифицированный js как-то раз на лету правил - тоже то ещё приключение было. Далеко идущие выводы из этого факта делать уже можно?

Это тут при чём? Форматирование блоков кода отступами в Питоне встроенное и принудительное, от него никуда не денешься. А минифицировать/обфусцировать код можно на любом языке, тут язык не при делах.

При том, что при форматировании дупой - любой язык становится излишне увлекательным.

Твой редактор кода не умеет в замену табов на пробелы?

И в чём трудность поменять везде на 4 пробела? В редакторе замена текста не работает?

Дорастаманились.

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

> былой безопастности

Да какой там...

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

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

ну вот и дождались!
И здесь маски сорваны, маскарад окончен...
Красота.

Готовьте кредитки, скоро будете ПЛАТИТЬ!

Но почему сразу кредитки ?
Может они добавят телеметрию (исключительно для безопасности) и кредитки не понадобятся.

Емнип, она и так есть, если не в самом компиляторе, то в тулинге. Хотя могу ошибаться, не цитируйте.

Не кредитки, а ЦВЦБ.

Хаха, поставлять скомпилированный бинарник в пакете это, конечно, сильно. Но зато я теперь понял, что значит по-настоящему значит memory safe.

Какая связь?

> поставлять скомпилированный бинарник в пакете это, конечно, сильно

Юзай генту =)

> поставлять crate-пакет serde_derive с макросом derive только в уже скомпилированном бинарном виде. Пакет serde_derive применяется для сериализации и десериализации данных и используется в качестве зависимости в 5495 других пакетах

Любители лить в рот прямо из трубы опять предсказуемо влетели.

Да в общем-то и раньше умные люди критиковали макросы.

> То есть на самом деле разбор форматной строки является не просто частью подключаемой по умолчанию библиотеки, что можно было бы предположить в случае println!, использованного в примере вывода Hello World, а и вовсе частью компилятора Rust. Сказки о невероятных удобствах и возможностях макросов, якобы позволяющих перенести в компайлтайм любое вычисление, рушатся уже на этапе написания первой программы на этом удивительном языке! Более того, с тем же успехом объяснить базовый пример можно было так, что непосредственно в языке есть конструкция вывода — и не городить огород с макросами.

Это бред.
Макросы не только лишь для принтлн нужны.
Это абсолютно нормально начиная с 80х годов прошлого столетия иметь полноценное метапрограммирование.

сишный define это не полноценное метапрограммирование.

> сишный define это не полноценное метапрограммирование.

А сишка то тут причем?

Полноценное метапрограммирование было в Лиспе примерно всегда.

А вот в сишечке такой ***** с блоками не было.

*блобами

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

Да обосрались они со скоростью трансляции вот и пробуют экономить теперь на спичках/
По мн е так тупиковый язык и идея

> Было

Кто сказал firefox?

У сишки и пакетного менеджера не было.

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

И в итоге сишкины либы как раз в большинстве бинарными блобами распространяются.

> И в итоге сишкины либы как раз в большинстве бинарными блобами распространяются.

Сколько там процентов у debian'а пакетов с воспроизводимыми сборками?

И на чем написаны проекты оставшихся пакетов - с не воспроизводимыми сборками?

> Мэйнтейнер проекта Serde отказался идти на компромисс и заявил, что предкомпилированная реализация макроса будет единственным вариантом поставки пакета serde_derive.

Это не так. 4 дня назад он откатил изменения: https://github.com/serde-rs/serde/releases/tag/v1.0.184 Но бугурт поднял конечно знатный, ведь самое забавное то, что заметили это случайно меинтейнеры федоры и к тому времени скомпилированный бинарник уже распространялся недели три. Это к слову о том что опенсорс смотрят миллионы глаз, да.

> 4 дня назад он откатил изменения

Но осадочек остался. Теперь буду знать, что serde разрабатывают дурачки. В прямом смысле этого слова. От того, что дурачки прогнулись под дизлайками, дурачками они от этого быть не перестали.

Может наоборот, свой труд уважают?

> Это не так.

Это было именно так. Ещё к тому же он просто заткнул рот возражающим, заблокировав возможность оставлять комментарии к тому issue. Типа всё уже решено (им) окончательно, и возмущения бесполезны.

Было и есть. Прошлое и настоящее. Гм...

растом пользуются полтора землекопа, каким-то васянским пакетом - ещё меньше. откуда миллион глаз лишь бы ляпнуть?

> растом пользуются полтора землекопа, каким-то васянским пакетом - ещё меньше. откуда миллион
> глаз лишь бы ляпнуть?

Я же не кексперт, умею интернетом пользоваться.
https://crates.io/crates/serde
https://crates.io/crates/serde_derive
500 тысяч загрузок _в день_

У serde_derive 172 миллиона загрузок.

> Это к слову о том что опенсорс смотрят миллионы глаз, да

Это главный миф опенсорса.
Реально в исходники смотрят только сами разработчики, а мейнтейнеры пакетов только когда сборка фейлится.

А ещё лет 15 назад, пользователи Gentoo, ставили флаги для Сишечки -Wall -Werror=format-security -fPIC и патчили сорцы, слали репорты в апстрим. А сегодня вместо флага -Werror=format-security используют ржавого.

> случайно меинтейнеры федоры и к тому времени скомпилированный бинарник уже
> распространялся недели три. Это к слову о том что опенсорс смотрят миллионы глаз, да.

Он себя повел так как будто хотел втулить через мутный централизованный сервис бэкдор. А федористам факовв. Дебианщики нормально пакетят либы в деб-пакеты как обычно вместо вот этих самопалов с блобами. При таком управлении системой невозможно не заметить такую подляну. Но если вы камлаете на самопальный недо-пакетник от гугл-амазон-майкрософта то конечно получите характерный для маздая экспериенс. А что вы ожидали то?

Что нужно чтобы начать использовать безопасный язык? curl | sh, исчерпать свободное место на диске уязвимостью cargo и установить несколько бинарных блобов.

> исчерпать свободное место на диске уязвимостью cargo

я думал, выжирать место на диске - это фишка раста

Да все уже, откатили прекомпилированный бинарник. К чувакам пришли в багтрекер и они в итоге сдались.

>К чувакам пришли в багтрекер и они в итоге сдались.

То, что они откатили, еще не значит, что сдались ;)
Ну и сдача, конечно не останавливает поехавшей у них крыши - это да.

> Ну и сдача, конечно не останавливает поехавшей у них крыши - это да.

Драма из ничего, в опенсурсе регулярно кто-то упоротые идеи выдает. Вспомни какую дичь Ульрих творил в glibc.

Какую? Спрашиваю любопытства ради

> Какую? Спрашиваю любопытства ради

Например, Ульрих решил что ему не очень интересно возиться с ARMи embedded в целом и отказывался принимать патчи. В итоге поцоны из Дебиана до 2014 года тащили свой форк elibc, который потом влили в glibc.

Можно подробнее? Ссылка на архив рассылок подойдёт. А то уже часто бывало, что Ульриха гнобили за якобы бредовые поступки, а на поверку оказывалось, что парень всё правильно сделал. Да и дебианы уже светились с кривыми патчами, которые апстрим не хотел принимать (история с cdrtools в пример).

Но я не троллинга ради, мне правда интересно.

https://snapshot.debian.org/package/eglibc/

2.9 (2009) .. 2.19 (2014). Т.е. где-то 5 лет неудобств. А то "до 2014" прозвучало, как будто неопределённо долго.

Ещё, кстати, была история с переходом на libav (форк ffmpeg):
0.6.2 (2011) .. 11.3 (2015 + длительная поддержка в stable Debian 8).

https://snapshot.debian.org/package/libav/

Слабо тянет на дичь.

> Слабо тянет на дичь.

Коменты в редгадской багзиле и рассылках от этого фрика были более чем колоритные.

Сабж это ад.
Нет даже так... адддище.
На роллинге еще норм, но релизный дистр - да оно или пересобирать сабж или отказываться от фокса и симанки.
Например, в дебиане 10 и 11 специально под это дело акромя древнего системного раста есть еще раст-мозилла.
Сейчас это 1.59 - а значит выше 102 фокса и полугодовалой 2.53.15 симанки не собрать...
А свежий раст-моззила просит кучу зависимостей конских и неделю на пересборку...

> в дебиане 10 и 11 специально под это дело акромя древнего системного раста есть еще раст-мозилла.

ну а как можно иначе с таким древнем мамонтовым Г?

> неделю на пересборку

смени свой четвертый пень на что-то поадекватнее

> неделю на пересборку
> смени свой четвертый пень на что-то поадекватнее

теоретик?

там же надо прежде чем llvm пересобрать и еще с 10-ок пакетов...

так что на 4-пне оно бы год собиралось, наверное...

Конечно теоретик! Я от четвертого пня избавился еще лет 15 назад, когда корки вышли.
Хз сколько оно бы на нем собиралось, но на наверное тебе можно доверять)))

видимо еще и неадекват-теоретик... не смог прочитать что речь не столько о железе...

Что за бред сумасшедшего.
Прийду домой проверю сколько оно из портов под Фрей собирается.
День там на дохлом 4хядереом бульдозере будет собираться десктоп полноценный.

читать не пробовали?
под 11 фрю собери и проверь как оно собирается...

Эм, 11 фря больше не поддерживается. Инфраструктура просто отключена.
Новый софт под нее никакой не собрать. В смысле без приключений правки мейкфайлов и прочего.

Фаерфокс ничем особенным не выделяется на фоне всего остального в этом плане.

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

Дак я как раз и писал о том, что сборка FF и SM упираются именно в сабж.
Как по самому времени пересборки, так и по ресурсам требуемым на сборку и времени на решение проблем с зависимостям.
В итоге получается быстрее и проще хромиум собрать, чем с ФФ возиться...

> Дак я как раз и писал о том, что сборка FF и
> SM упираются именно в сабж.
> Как по самому времени пересборки, так и по ресурсам требуемым на сборку
> и времени на решение проблем с зависимостям.
> В итоге получается быстрее и проще хромиум собрать, чем с ФФ возиться...

Для сборки раста нужно:

Build dependencies:

        cmake : devel/cmake-core
        ninja : devel/ninja
        pkgconf>=1.3.0_1 : devel/pkgconf
        python3.9 : lang/python39

Library dependencies:

        libcurl.so : ftp/curl

>>смени свой четвертый пень на что-то поадекватнее

Пересборка, это не запустил, попил кофе..и готово.
Но и ручное вмешательство. То, что то ошибку выдало, то не та версия, то пропатчить надо, то тесты не прошли и 6ачинай по новой..
Ну пересборка делается же в основном для нового, а старое и в бинарном виде можно уже готовое скачать.

Смени cmake на cargo. Там все автоматически собирается без перерывов на кофе и ошибки

> Смени cmake на cargo. Там все автоматически собирается без перерывов на кофе
> и ошибки

Так речь только о сборке уже готового, пусть и свежего. А бывает что помимо мелких патчей, в худшем случае надо скестить ежа с ужом. ;)

а в чём проблема с пересборкой? gentoo с растом и firefox на ryzen 5950x собирается за два часа

читать не пробовали? речь не о роллинге по готовым ебилдам собрать...

Он уже сдал назад: https://github.com/serde-rs/serde/releases/tag/v1.0.184

> В будущем выпуске Rust 1.76 планируется прекратить поддержку платформ Windows 7, 8 и 8.1

как самоотверженно стали закапывать...

Нет, не по указке. Нет, не синдикат. У вас паранойя. Покупайте последние процессоры и последние версии ОС, иначе бог не полюбит вас.

Забавно что последние версии Mozilla Firefox 116.0.x, которые как бы прекратили поддержу Windows 7 и автоматически не установятся, на практике прекрасно работают в Windows 7 если их скачать и распаковать вручную

Какой б..г то? Редмонтовский?

Переносимый язычок (с единственным и неповторимым запретом на клонирование) такой вот переносимый.
Винда, винда, еще винда но только правильная - и, вот, нате-на-лопате еще linoops (тоже далеко не любой).

Модному поколению не нужны лишние сложности при сборке, "и так сойдет!"

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

А почему Microsoft можно прекращать поддержку Windows 8.1 (платная ОС, а разработчикам Rust (бесплатная среда разработки) - нельзя? Наверное потому, чтобы великому эксперту пох-у было что ляпнуть.

> требует обязательной инициализации значений переменных перед использованием

Может и безопасно, но снижает производительность.

>> требует обязательной инициализации значений переменных перед использованием
> Может и безопасно, но снижает производительность.

Говорят нам любители сишных strlen() и LIST_FOR_EACH(), ага :D

Производительность чего, чтения мусора из памяти?

Ну если у тебя в памяти мусор то И ...
Но ты ведь помнишь как дебиановцы "лохов" из OpenBSD/OpenSSH поправили и проинициализировали :)
После этого пароль подбирался на простом кнопочном калькуляторе за 5 минут.
Откатили после всепланетного рофла :)
Так что же выходит - не весь мусор в памяти одинаково вреден? Представляю как растишек в этом месте "... разрывает на части!(С)" :)

> Ну если у тебя в памяти мусор

Чтение неинициализированной памяти - UB, будь то Rust или C, если за читаемым адресом действительно память, а не MMIO.

> Но ты ведь помнишь как дебиановцы "лохов" из OpenBSD/OpenSSH поправили и проинициализировали

Не помню, напомните.

https://github.com/g0tmi1k/debian-ssh

Для инициализации PRNG следует использовать специально для этого предназначенные источники энтропии, и в Linux это /dev/random, а не мусор из памяти.

Ну дык что - пропвтчишь ssh то, покажешь лохам как надо? Или так потрепалсО и в кусты? :-)

Иди сам пропатч, чудо. Этому багу уже больше 10 лет.

> Чтение неинициализированной памяти - UB, будь то Rust или C

нет, расширяй кругозор

https://github.com/u-boot/u-boot/blob/291055efee4e1ae4ad0b62...

Объясните как из приведенной ссылки следует что это не UB ?

> как из приведенной ссылки следует что это не UB ?

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

Для тебя есть примеры попроще - многоядерные системы с общей памятью, или просто шаред мемори  в многопотоке - инициализация нужна только с одной стороны, с другой вообще может быть только ридонли.

А при чём тут железо вообще? UB это про то, что компилятор имеет право подобный код скомпилировать как угодно
https://research.swtch.com/ub#uninit

> А при чём тут железо вообще?

при том что ответ был на пост про железо

> Чтение неинициализированной памяти - UB, будь то Rust или C, если за читаемым адресом действительно память, а не MMIO.

и привёл примеры где нет никакого неопределенного поведения при доступе к неинициализированной памяти "не MMIO"

https://en.wikipedia.org/wiki/Memory-mapped_I/O_and_port-map...

> и привёл примеры где нет никакого неопределенного поведения при доступе к неинициализированной памяти

Примеры чего? В стандарте написано что чтение неинициализированной переменной это UB.

Например:

int b;

if (b > 10)
    puts("опеннетчики не могут в стандарт C");
else
    puts("опеннетчики точно не могут в стандарт C");

Вот это применр невалидного кода, с которым цомпилятор может сделать что угодно. Например, выкинуть обе ветки.

> Примеры чего? В стандарте написано что чтение неинициализированной переменной это UB.

примеры того что можешь подтереться стандартами и UB нет

> цомпилятор может сделать что угодно. Например, выкинуть обе ветки

для таких случаев есть volatile int b - иди подучись

> примеры того что можешь подтереться стандартами и UB нет

Ты же понимаешь что компилятор не очень заботит чем ты подтираешься и он будет следовать стандарту?

> для таких случаев есть volatile int b

То есть ты настолько настроен писать говнокод что вместо инициализации переменной будешь volatile совать?

> вместо инициализации переменной будешь volatile совать?

конечно если это нужно, а ты переменную в памяти которую можно только читать будешь инициализировать ?

> конечно если это нужно, а ты переменную в памяти которую можно только читать будешь инициализировать ?

Ветка вообще не про это.

> Ветка вообще не про это.

как раз про это - ты не понимаешь что часто требуется не инициализировать память, но ведь чтобы понять надо опыт программирования иметь а не языком чесать про безопасность.

> как раз про это - ты не понимаешь что часто требуется не инициализировать память, но ведь чтобы понять надо опыт программирования иметь а

Ох... это требуется в двух случаях: tight loop и общение с железом. В первом случае нет никаких чтений неинициализированной памяти (потому что это мать его UB), а второе это специальный случай с volatile.

> Ох... это требуется в двух случаях: tight loop и общение с железом. В первом случае нет никаких чтений неинициализированной памяти (потому что это мать его UB), а второе это специальный случай с volatile.

в ядре Linux 80% кода это драйверы железа, т.е примерно всегда, охай дальше

Прекрасно, как код драйвера железа относится к exfat?

>> в ядре Linux 80% кода это драйверы железа
> как код драйвера железа относится к exfat?

exfat по твоему к железу относится ? тебя кто-то обманул

> exfat по твоему к железу относится

Нет, я спрашиваю как exfat или device mapper относятся к железу. Потому что дыреней там из-за пердолева с неинициализированной памятью не меньше.

> Нет, я спрашиваю как exfat или device mapper относятся к железу. Потому что дыреней там из-за пердолева с неинициализированной памятью не меньше.

ты знаешь что не относится к железу но всё равно спрашиваешью Это наверно как-то должно отменить факт что доступ к регистрам MMIO повсеместно через volatile, может ты считаешь что CPU програмно должен инициализировать тысячи регистров в железе а не его аппаратный сброс и это как-то поможет устранить ошибки exfat и device mapper ? Тебя кто сильно обманул.

> Это наверно как-то должно отменить факт что доступ к регистрам MMIO повсеместно через volatile

Это прекрасно, но то что доступ к MMIO через volatile не отменяет того факта что код вокруг этого volatile это капля в море и все равно специальный случай.

>> Нет, я спрашиваю как exfat или device mapper относятся к железу. Потому что дыреней там из-за пердолева с неинициализированной памятью не меньше.
> наверно как-то должно отменить факт что доступ к регистрам MMIO повсеместно
> через volatile, может ты считаешь что CPU програмно должен инициализировать тысячи
> регистров в железе а не его аппаратный сброс

Чтобы не быть голословным:

$ cd ~/src/linux/drivers/net/ethernet/intel
$ git grep -c volatile .
e1000/e1000_hw.h:11
i40e/i40e_txrx.h:1

> $ cd ~/src/linux/drivers/net/ethernet/intel
> $ git grep -c volatile .

в коде драйверов кроссплатформенные readX/writeX, ioreadX/iowriteX и тд и надстройки над ними, а  implmentation defined реализации этих ф-ций в /arch

https://www.opennet.dev/openforum/vsluhforumID3/131335.html#172

> в коде драйверов кроссплатформенные readX/writeX, ioreadX/iowriteX и тд и надстройки над ними, а  implmentation defined реализации этих ф-ций в /arch

Ага. Поэтому у тебя работа с volatile спрятана в двух функциях и не торчит наружу. Прямо как ненавидимый местными поциентами unsafe :D

> работа с volatile спрятана в двух функциях

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

>> работа с volatile спрятана в двух функциях
> она не спрятана - ф-ции чтения/записи с гарантией того что вызовы не
> будут переупорядочены зависит от модели памяти архитектуры на которой исполняется код,
> если не заметил кроме volatile в реализации есть ещё барьеры памяти,
> сделано так чтобы писать кроссплатформенные драйверы.

Она спрятана в функции. Прям внутри.

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

Так что на общий случай "положили массив на стек" или "создали пару переменных" наличие volatile не влияет никак.

> Она спрятана в функции. Прям внутри.
> начал орать что мы ничего не понимаем

объяснил на пальцах, и да ты ничего не понимаешь

> обращение к памяти устройства это как раз-таки специальный случай

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

> переменные все-таки хорошо бы инициализировать

так их и надо инициализировать когда нужно, а когда не нужно  - не надо, до тебя такие простые вещи не доходят

> так их и надо инициализировать когда нужно, а когда не нужно  - не надо

Ты условил самую суть! Поэтому в Rust память инициализируются по умолчанию. Для тех случаев, когда не надо сделали MaybeUninit.

Хорошо, здесь вы правы, я выразился неточно: UB не сам факт чтения, и именно использование неинициализированной памяти.

(void) readl((void *) rank1_base);

Т.к. здесь данные не используются, UB нет. Впредь постараюсь быть точнее.

> Т.к. здесь данные не используются, UB нет.

они могут и использоваться - буферы DMA from device, общая память IPC mailbox/msgbox в SoC из которой читаешь сообщения от асинхронной корки - пишет туда сопроцессор которым упраляешь а не твой код на CPU, это аналогично MMIO но в обычной памяти.

Разве в стандарте не говорится просто об чтении?
В любом случае для LLVM чтение неинициализированной памяти кажется точно UB

Тогда бы им можно было только хилоуворды(С) собирать. А им даже вёдра собирают.

Это UB для LLVM. Это означает что компилятор может скомпилировать этот код как ему захочется, например просто выкинуть.

Ведь записи в память не происходит, а значит и чтения тоже нет.

> Это UB для LLVM. Это означает что компилятор может скомпилировать этот код как ему захочется, например просто выкинуть.

при чём тут LLVM - шланг стандарт С не признаёт и выкинет доступ к volatile ?

https://elixir.bootlin.com/u-boot/latest/source/arch/arm/inc...

https://elixir.bootlin.com/u-boot/latest/source/arch/arm/inc...

Допустим, есть большой массив. Есть поток данных. Массив постепенно заполняется, по мере поступления данных. Инициализация всего массива – лишняя и ненужная трата времени, если алгоритм программы его и так весь заполнит.

Речь о том что после аллокации памяти под массив из него попытались что-то прочесть раньше чем записать.

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

> Ансейф раст — всего лишь маркер,
> что компилятор снимает с себя полномочия по доказательству корректности и перекладывает
> их на разработчика

Не верно, никаких он полномочий не перекладывает, все гарантии из safe rust там сохраняются.
Однако в unsafe{} блоке можно вызывать unsafe функции (Сторонние библиотеки например, FFI, или просто функции в которых есть unsafe, и корректность вызова которых должен доказывать пользователь), разыменовывать указатели (не путать с ссылками), обращаться с изменяемыми статичными переменными (static mut), и обращаться к полям union.
Кроме этих дополнительных _разрешений_ unsafe блок ничего не делает.

Это буквально то как работает Vec в Rust. Я понимаю что сишным пердолям сложно и они по привычке используют слайсы, но господи Иисусе, нельзя же быть НАСТОЛЬКО некомпетентными.

Vec – динамический массив, а я про обычный. Работа с динамической памятью может быть медленней, особенно на микроконтроллерах.

Для этого есть https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html. Создаешь, пишешь, используешь

Здорово, но... Лишние строчки кода.

Если ты боишься что это медленнее будет, то не будет, весь сахар эфемерный и уйдет после компиляции. Если ты хочешь той же семантики что у Vec, то ArrayVec.

Можно и неинициализированной памятью пользоваться, но это уже придётся оборачивать unsafe.

Но в неё можно только писать, т.е. инициализировать. Использование неинициализированной памяти - UB, независимо от того, unsafe это или нет.

В большинстве случаев нет.

В rust есть оптимизатор, который позволяет в простых случаях всё ненужное убрать.

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

Я пока вилами и факелом в угол не загнали стараюсь не оптимизировать код, который работает.

> Ну, *лично я* как правило не доверяю оптимизациям

Собираешь с -O0?

https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html

Это то что нужно знать, если уж хочется неинициализировать данные

В npm такое часто. Это я к тому откуда ноги растут...

Сколько бычков набежало в комменты на красную тряпочку в виде одного мейнтейнера с потёкшим чердаком... И, как назло, тот дырку заклеил. Эх, опять Rust не получилось закопать, что же такое.

А почему все критекуют тут раст за безопасность причем тут безопасная работа с памятью и написанный код.

> А почему все критекуют тут раст за безопасность причем тут безопасная работа с памятью и написанный код.

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

Что-то я не понял прикола. В чем соль бинарников вместо исходников?
Если у меня отличная от бинарников архитектура?

Кстати, да. Это ж под все архитектуры надо свои бинарники.

_обе_. О каких "всех" идет речь у компилятора, который тестируют только на винде последней версии и еще...вот ?

Чуть больше, о великий эксперт. https://doc.rust-lang.org/nightly/rustc/platform-support.html

Считать научись. По ссылке буквально подтверждение, что две платформы. Варианты с разными библиотеками - это не платформы, про tier 2 даже не заикайся - они не гарантируют работоспособности.

Значит тебе не нужен serde_derive

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

Просто автор хотел сэкономить пользователям serde время на компиляцию процедурных макросов, которые, по сути, являются плагинами компилятора. Идея интересная, только:
- У пользователя должен быть выбор, использовать прекомпилированные макросы или собирать их каждый раз с нуля (без учёта кеширования)
- Уже давно существует sccache

автор (dtolnay) сделал фантастическую фигню, сделав морду кирпичом и прикрываясь жалким блеянием про скорость процедурных макросов. учитывая компетентность товарища - его просто прогнули, 99% вероятности - гугл, где он работает. в гугле такая же жалкая аргументация для пропихивания мерзких дурно пахнущих "фич"

хорошо то, что бредятину откатили, но это только пока

> автор (dtolnay) сделал фантастическую фигню, сделав морду кирпичом и прикрываясь жалким
> блеянием про скорость процедурных макросов. учитывая компетентность товарища - его просто
> прогнули, 99% вероятности - гугл, где он работает. в гугле такая
> же жалкая аргументация для пропихивания мерзких дурно пахнущих "фич"
> хорошо то, что бредятину откатили, но это только пока

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

>> автор (dtolnay) сделал фантастическую фигню, сделав морду кирпичом и прикрываясь жалким
>> блеянием про скорость процедурных макросов. учитывая компетентность товарища - его просто
>> прогнули, 99% вероятности - гугл, где он работает. в гугле такая
>> же жалкая аргументация для пропихивания мерзких дурно пахнущих "фич"
>> хорошо то, что бредятину откатили, но это только пока
> На реддите и в других ветках на гитхабе ему нормально так по
> морде надавали. Ведь при наличии инкрементальной компиляции эта байда компилируется один
> раз и время потраченное на это в сравнении с компиляцией всего
> проекта вообще незаметно.

Санта-Барбара какая-то... Не лень вам участвовать в большой стирке?

> Санта-Барбара какая-то... Не лень вам участвовать в большой стирке?

Хоть какое-то развлечение. Не кекспертов же местных обсуждать.

>Агент влияния NSA, для этого ставший мейнтейнером проекта Serde отказался идти на компромисс

Ясно.

>несогласным с новой политикой разработчикам предложено создать и поддерживать собственный форк пакета.

Абсолютно правильно. Но есть немного другой вариант. Так как crates.io принадлежит Rust Software Foundation, то она может предложить мейнтейнеру serde создать свой содственный ЯП, пакетный менеджер, луна-парк и лунный модуль. А имя отжать и повесить по нему свой форк.

>даже на бросающийся в глаза перевод serde_derive в бинарную форму обратили внимание только спустя 4 недели и 12 релизов. При таком отношении профессионально обфусцированная вредоносная вставка в исходных текстах вероятно может годами оставаться незамеченной.

Я вам больое скажу, даже абсолютно не обфусцированная и абсолютно явная.

Проверил в реестре зарегистрированных торговых магок США, serde там нет.

Раст - лучший яп

Потому что он умеет безопасно работать с памятью)))

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

И американо-госбезопасно работать с сообществом.

Лучший по причинению страданий программисту
Если не считать Malbolge

А ты писал что-то на расте или просто слышал звон и не знаешь где он? Какие же страдания у тебя вызывает раст? Заставляет тебя обробатывать возможные ошибки? Единственное, так это некоторые моменты с временем жизни ссылок могут быть не вмегда сразу очевидны. Но компилятор все разжует и в рот положет.

Но компилятор все разжует и в рот положет. - в некоторых случаях лучше не знать, через какое отверстие будет выходить результат пережевывания.

Тебе ставят клизмы с питательным раствором?

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

Конечно видел, ведь я его пишу. И читаю код других. Так что с ним не так?

https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-...

> https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-...

Автор какой-то странный. Растовый аналог его гошного кода

package main
import "fmt"
type Update struct{}
type Handler func(*Update)
type Dispatcher struct {
    handlers []Handler
}
func (dp *Dispatcher) pushHandler(handler Handler) {
    dp.handlers = append(dp.handlers, handler)
}
func main() {
    dp := Dispatcher{handlers: nil}
    dp.pushHandler(func(upd *Update) {
        fmt.Println(upd)
    })
}

Будет такой код:

#[derive(Debug)]
struct Update;
type Handler = fn(&Update);
struct Dispatcher(Vec<Handler>);
impl Dispatcher {
    fn push_handler(&mut self, handler: Handler) {
        self.0.push(handler);
    }
}
fn main() {
    let mut dp = Dispatcher(vec![]);
    dp.push_handler(|upd| {
        println!("{:?}", upd);
    });
}

для него уже есть хоть одна IDE не на джаве (включая джавускрипт)?

Она появилась сразу же - Oak. Была написана на самом расте. По сути это gui  с интегрироаанным вимом. Но автор, похоже, давно забросил проект. А по сути какая IDE  тебе нужна? Я открываю емакс в терминале, потом открываю вторую вкладку в терминале и в емаксе пишу код, а во второй вкладке его запускаю. Или ты без кнопки run  жить не можешь?

Qt Creator/KDevelop/Kate + https://github.com/rust-analyzer/lsp-server (жрёт очень много памяти, как и все LSP).

>решив отложить переход на поставку в бинарном виде до принятия в пакетный менеджер crate изменений для полноценной поддержки верификации предкомпилированных макросов. Разработчиками Serde подготовлен RFC с предложением реализовать в Crate верификацию предкомпилированных пакетов, проводимую на сервере репозитория crates.io через сверку бинарного файла с повторяемой сборкой из исходных текстов

Это лишь косметическая мера для того, чтобы успокоить псевдопараноиков-конформистов.

За Rust взялись серьёзно в качестве элемента кибервойны. Статическое связывание всех библиотек в случае их компрометации приведёт статическому внедрению бэкдора в весь софт, от них зависящий. Вычистить его оттуда будет на практике невозможно - это надо будет пересобрать весь софт с чистыми библиотеками. Но Rust устроен так, что это невозможно - библиотеки требуют конкретных версий зависимостей и Cargo их удовлетворяет, а есщи их поменять - то компиляция ломается чаще, чем необходимо, ибо "разработчиков" (в кавычках) на Rust приучили, что ломать API можно без последствий, нужно лишь заплатить налог в виде держания последнего nightly-компилятора, установленного из `curl | sudo`, и гигантских бинарников и долгой компиляции. Тепень фарш нельзя провернуть назад - это придётся переделать пакетный менеджер и все либы, это будет язык, не совместимый с Rust, то есть будет уже не Rust, а другой ЯП с тем же именем. Поэтому его просто не будет.

Но проблема усугубляется тем, что написано уже куча софта и либ на Rust, которые интегрированы в кучу другого софта. Где-то просто потому, что Rust обещал безопасность и производительность. Где-то потому, что кто-то написал реализацию на Rust, а других реализаций под пермессивной лицензией никто не написал. В результате придётся переписать весь такой софт. Кто это делать будет?

Далее предположим на секундочку, что ОК, ну раз необходимо - значит перепишут. Но если весь софт забэкдорен, то что мешает в бэкдор засунуть функциональность вируса, встраивающую в компилирующиеся программы этот самый бэкдор-вирус? Если у нас весь софт инфицирован, где-то потому, что написан на Rust и зависит от вредоносных зависимостей, где-то потому, что на компьютере, где происходит сборку, был установлен забэкдоренный софт, который инфицировал софт во время сборки (т.н. Ken Thompson compiler hack), то как нам получить чистую систему, на которой можно собрать чистые версии софта? Как - понятно - взять старый комп с холодного хранения, там система будет чистая. Но новый софт полностью из исходников такая система не соберёт. И даже если соберёт - в старой системе будут уязвимости, которые можно будет проъксплуатировать и залить новый бэкдор-вирус, поэтому её нельзя вообще к инету подключать.

Эту инициативу нужно давить в зародыше.

1. выкинуть разраба из Rust Software Foundation
2. отжать имя пакета на crates.io и повесить туда форк
3. начать переделывать cargo для ликвидации безответственного и развратного подхода к управлению зависимостями.

3.1 каждая зависимость (имя ящика) на всё дерево зависимостей должна быть в одном экземпляре. Вводить постепенно - через дельту в номере версии, которые считаются "одной версией", захардкоженную в cargo. То есть если в одном месте требуется 1.3.1, 1.3.2 и 1.3.5, то чтобы считалось, что при Δ=1 нужно только 1.3.2 и 1.3.5, а при Δ=3 - только 1.3.5. Дэльту увеличивать так, чтобы на каждое изменение сломался определённый малый процент библиотек на crates.io. Разрабам сломанных библиотек придётся прогнуться и изменить свои привычки. Им не впервой, прогнутся, конформаисты же.

3.2 построить workflow вокруг возможности использования предкомпилированных shared библиотек, при этом какой тип библиотек используется, shared, static или source - должно контролироваться лицом, производящим сборку.

В любом проекте генерируется Cargo.lock файл в котором указаны все зависимости проекта. Обычно этот файл не редактируется вручную, но ничто не мешает залезть туда и поменять версии и репозитории любых зависимостей.

Я так и делаю, в значительном числе случаев после этого проект перестаёт компилироваться, потому что обратной совместимости в Rust просто не существует, и в языках с таким подходом к связыванию она не может и существовать. Поэтому приходится делать иначе: проходить по всей истории, править уже Cargo.toml, откатывать изменения и сливать конфликты. Это кропотливая ручная работа, которая в отсутствии системы контроля версий, работающей на уровне AST, а не строк, может целый день занять для одного проекта. А теперь представь, что это не 1 проект, а все проекты. Кто это всё будет делать? И, в гипотетических будущих условиях, когда весь софт скомпрометирован и безопасности тебе от вычистки пакетов прибавится пренебрежимо мало, зачем? Проще расслабить булки, что большинство и сделает.

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

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

Лично я подменой зависимостей занимался, и каких-то серьёзных проблем с этим не имел. В отличии от вас. Так что мне тут больше сказать вам нечего.

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

В плане безопасности статическое связывание как раз лучше. Один раз собрал и точно знаешь, что обновление другого пакета не добавит уязвимости в конечную программу. Крупные конторы на С++ давно все статически собирают.

Конторы живущие поддержкой одного большого программного обеспечения.

Если не будешь компилировать статически, кто же будет покупать поддержку с исправлением всех дырок во всех библиотеках?

> Конторы живущие поддержкой одного большого программного обеспечения.
> Если не будешь компилировать статически, кто же будет покупать поддержку с исправлением
> всех дырок во всех библиотеках?

Как предлагается пинать пользователей обновить уязвимые динамические зависимости?

Ещё в качестве дополнительной меры воздействия можно задействовать по алгоритм, изложенный в https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi?az=p...

1. Заходим на https://github.com/dtolnay
2. Выбираем Block or Report
3. Block user

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

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

Что-то мне это напомнило, а пару месяцев назад, не стели принимать очет об ошибке в одну библиотеку на почве национальности. Мну , аккуратно скопировал из неё  все классы ,переименовав их на букву Z , чуток потер комментарии, и поставил пару костылей , чтобы баг исправлялся только в моем частном случае , но никак не в общем... Сижу жду горения.

Причём тут национальность? Мы тут о человеке по его поступкам судим. Человек злоупотребил своим положением и влиянием в проекте для продвижения вредоносных изменений. Я сам - ярый сторонник бинарных пакетов, но тот способ поставки бинарного пакета, который он продвигает - это простотзаведомо небезопасно. Впрочем как и вся экосистема Rust.

Кто-то приложил своё влияние для продвижение изменения, в результате которого всем заведомо хуже становится. Тут пока полностью не прокатило, но на полшишечки-то прокатило, а значит со временем прокатит и полностью.

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

> Но у нас тоже есть кое-какое влияние для ответки. Не такое большое, как у него, но зато нас много.

нет у вас ничего против корпораций кроме языка на их яичках

https://www.opennet.dev/opennews/art.shtml?num=58969

Проприетарщина, что и требовалось доказать. И это только начало.

Плюсую. Далее, с бинарников они перейдут на частично несвободную лицензию.

Два эксперта не удосужились проверить, что автор уже откатил все свои хотелки.

> Два эксперта не удосужились проверить, что автор уже откатил все свои хотелки.

Это спасает проблему с инфраструктурой раста?

Когда большинство проектов при сборке вытаскивают последние версии зависимостей и собирают с ними?

Ну так не используй все это и пиши как на сишке все сам руками, кто тебе мешает-то.

> Два эксперта не удосужились проверить, что автор уже откатил все свои хотелки.

Сегодня откатил, завтра не откатит, завтра он будет уже не один. Такие явления - это звонок.

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

Шаг с выбросом Вин7 это сильный шаг. То есть нет. Наоборот.

Вот представим что юзеры Вин7 хотят некий тул. Например текст редактор. И что ? На Раст теперь его не напишешь. Хахаха ! А вот на Лазарус напишешь.

Вот представим, есть неконсумерист/параноик с Windоws 7. Рекламу отключает или просто игнорит и ничего по ней не покупает, ибо денег нет. Нужно ли на такого ресурсы команды разработки браузера тратить иресурсы сервера с телеметрией? Просто дропнем Windows 7 в браузере. А потом и в Rust. Хочешь использовать современные программы - купи и современный зондокомп с Windows 11. Не готов? Ну а а зачем ты нам такой нужен, посмотрим как ты запоёшь, когда без современного смузи-софта останешься. Придётся тебе самому переписать его на C++, весь лунный модуль и весь луна-парк, вместе с посетителями.

Это наивный взгляд на вещи. Прецедент с прекращением поддержки старых ОС это 100% отказ от использования в системах ESR, критичных для бизнеса.

Этот момент в Rust конечно пугает. Допустим твои клиенты пользуются Windows 7 (или Windows 10 в будущем), и тут из под тебя выдергивают стул. Или сидеть на последней работающей версии или спонсировать разработку компилятора/std. С C++ как-то все надежней, поддержка Windows XP есть в Visual Studio 2015.

А зачем на сайте юниксоидов ты пишешь про Виндовс? Страдай, твои проблемы! Лучше иди-ка ты на сайт вантузников.

Где на сайте написано что он для юниксоидов?

Грустно быть опеннетчиком. Читаем оригинал:

Currently Windows 7 and 8 are listed as Tier 1 supported platforms. However, this has not been true for a long long time. We simply do not have the testing infrastructure. And with so much software now abandoning Windows 7 and 8 (everything from Git to Go to every major browser), continuing to provide the little support that we do is only getting more difficult. There is also a lack of vendor support for these targets.

[…]

Support for Windows 7 and 8 may continue beyond these dates through the creation of new "legacy" targets for older Windows versions. Individuals or organisation(s) who can commit to providing some level of legacy testing and support should go through the normal process for creating new targets.

> Грустно быть опеннетчиком. Читаем оригинал:

И что там в оригинале? Ровно то что я и сказал, если захочешь поддержку Windows 7 (или Windows 10 в будущем), придется стать такой organization(s) or individual которые будут поддерживать target. Хватит ли нашей гипотетической компании бюджета на это большой вопрос.

Более того, нет особо никакого понимания как все будет. Просыпаешься такой утром, читаешь новости, "это версия будет последней для вашей платформы".

На чем ты предлагаешь им тестировать свой код, если win7 не продается с конца 17го года и не поддерживается с начала 23го, лол?

Ты можешь использовать виртуалку хоть с Windows NT.

Где брал не помню, но помню, что MS сама выкладывала для разработчиков виртуалки со старыми своими версиями.

Нет, не можешь, для тестирования тебе нужна та же система, на которой будут гонять твой код. И если ты не можешь ее купить, а вендор говорит что больше не будет ее поддерживать, то ты ее дропнешь. Как уже сделали Git, Go и прочие.

А куда делась инфраструктура? Раньше была и вдруг резко пропала, а новую не купить?

> а новую не купить?
> Окончание продаж Windows 7: 31.10.2016

А ты догадливый!

Так куда пропала инфраструктура?

> Так куда пропала инфраструктура?

Её никогда и не было. Windows 7 сдохла раньше, чем они начали регулярные сборки Tier1 :D

Кто мешает (запрещает) использовать старую версию Rust? Visual Studio 2015 сколько годков? Вот возьмёте такую же версию Rust и вперёд и с песней. Или это другое?

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

> Можно, я и написал этот вариант. Но в целом теперь я думаю
> что C++ может выглядит если честно более жизнеспособным если проект рассчитан
> на работу на машинах клиентов.

Нет, не выглядит, потому что VS свежих релизов тоже не поддерживает Windows 7. Так что разницы буквально никакой :D

Текущий проект собирается на VS2005, VS2015, clang, gcc (разные версии). Я вот думаю можно ли так было бы сделать на rust? Наверное в каких-то пределах можно, если не будет зависимостей с crates.io.  Вроде VS2022 с трудом но ставится на Windows 7

Кратко: всё устройство языка Rust и его экосистемы.

Весь софт для археологов уже есть, раз в семь-десять лет можно себе позволить менять все, а не тащить легаси веками.

Я вообще не понял, при чём тут версия ОС к языку программирования...

Zig выигрывает у сабжа примерно во всём относительно системного программирования.

> Zig выигрывает у сабжа примерно во всём относительно системного программирования.

Сомневаюсь, но! Rust - это наследие и развитие C++, с иной философией. Поэтому его прямой конкурент - это плюсы и некоторое подмножество высокоуровневых языков (Java, Go, Pythion). Rust больше подходит для разработки прикладного софта с вкраплениями системщины или системного софта с приличной долей прикладного кода. Поэтому он сужает область выгодного использования C и Zig, но не претендует на их полную замену. В отличии от области плюсов.

>> Zig выигрывает у сабжа примерно во всём относительно системного программирования.
> Сомневаюсь, но! Rust - это наследие и развитие C++, с иной философией.
> Поэтому его прямой конкурент - это плюсы и некоторое подмножество высокоуровневых
> языков (Java, Go, Pythion). Rust больше подходит для разработки прикладного софта
> с вкраплениями системщины или системного софта с приличной долей прикладного кода.
> Поэтому он сужает область выгодного использования C и Zig, но не
> претендует на их полную замену. В отличии от области плюсов.

Где системное программирование и где плюсы. Я специально подчеркнул область применения.

>>> Zig выигрывает у сабжа примерно во всём относительно системного программирования.
>> Сомневаюсь, но! Rust - это наследие и развитие C++, с иной философией.
>> Поэтому его прямой конкурент - это плюсы и некоторое подмножество высокоуровневых
>> языков (Java, Go, Pythion). Rust больше подходит для разработки прикладного софта
>> с вкраплениями системщины или системного софта с приличной долей прикладного кода.
>> Поэтому он сужает область выгодного использования C и Zig, но не
>> претендует на их полную замену. В отличии от области плюсов.
> Где системное программирование и где плюсы. Я специально подчеркнул область применения.

А прикладнику в 2к23 лучше писать на языке со сборкой мусора.

> А прикладнику в 2к23 лучше писать на языке со сборкой мусора.

Прикладной софт, требовательный к производительности, в 2к23 лучше писать на безопасном языке с borrow checker.

>> А прикладнику в 2к23 лучше писать на языке со сборкой мусора.
> Прикладной софт, требовательный к производительности, в 2к23 лучше писать на безопасном
> языке с borrow checker.

Я так не считаю, критичные для перфа места  всегда можно написать на чистом си, это будет и быстрее, и читабельнее, чем раст. Дальнейший разговор считаю бессмесленным, он будет просто бесполезным обменом субъективными мнениями.

Комментарии для того здесь и нужны, чтобы обмениваться мнениями. Или вы что, боитесь потерять веру в свою религию? )

Ну, например - регулярные выражения. Производительность в Rust может в разы быть лучше других языков (и на порядок лучше Java и Go): https://github.com/mariomka/regex-benchmark

Или, веб серверы. В топе 10 - пять написаны на Rust: https://www.techempower.com/benchmarks/#section=data-r21&tes...

На алгоритмических задачах - и снова производительность Rust на уровне C и C++: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Отсюда вопрос: так зачем мучиться, лепить франкенштейна - половину кода писать на Java/Go, половину на C (причём и прикладного тоже), когда можно просто взять Rust? И бонусом ещё получить типобезопасную многопоточность (Java тут вообще в сторонке курит).

>[оверквотинг удален]
> боитесь потерять веру в свою религию? )
> Ну, например - регулярные выражения. Производительность в Rust может в разы быть
> лучше других языков (и на порядок лучше Java и Go): https://github.com/mariomka/regex-benchmark
> Или, веб серверы. В топе 10 - пять написаны на Rust: https://www.techempower.com/benchmarks/#section=data-r21&tes...
> На алгоритмических задачах - и снова производительность Rust на уровне C и
> C++: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Отсюда вопрос: так зачем мучиться, лепить франкенштейна - половину кода писать на
> Java/Go, половину на C (причём и прикладного тоже), когда можно просто
> взять Rust? И бонусом ещё получить типобезопасную многопоточность (Java тут вообще
> в сторонке курит).

Я тоже умею натягивать сову на глобус, но с возрастом это занятие теряет свой шарм. Адьо, теоретик.

Кроме вашего возраста, больше аргументы нет против?

>Производительность в Rust может в разы быть лучше других языков

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

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

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

>>> Zig выигрывает у сабжа примерно во всём относительно системного программирования.
>> Сомневаюсь, но! Rust - это наследие и развитие C++, с иной философией.
>> Поэтому его прямой конкурент - это плюсы и некоторое подмножество высокоуровневых
>> языков (Java, Go, Pythion). Rust больше подходит для разработки прикладного софта
>> с вкраплениями системщины или системного софта с приличной долей прикладного кода.
>> Поэтому он сужает область выгодного использования C и Zig, но не
>> претендует на их полную замену. В отличии от области плюсов.
> Где системное программирование и где плюсы. Я специально подчеркнул область применения.

Есть некоторое количество операционок, написаннх почти полностью на плюсах. Не говоря уже про другие области, относящиеся к "системному программированию".

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