LINUX.ORG.RU

Rust 1.14

 


1

6

Представлен релиз Rust 1.14 — системного языка программирования, нацеленного на безопасную работу с памятью, скорость и параллельное выполнение кода. В этот релиз вошли 1230 патчей.

Самое большое изменение в Rust 1.14 не связано с языком или компилятором: rustup достиг версии 1.0 и теперь является рекомендуемым способом установки Rust. Rustup предоставляет такие возможности, как установку Rust из официальных каналов, возможность обновления и переключения между стабильным, бета и ночным версиями компилятора, упрощение кросс-компиляции с бинарными сборками стандартной библиотеки под распространенные платформы. И, конечно, rustup работает на всех платформах, которые поддерживает Rust, включая Windows. Подробнее о rustup можно прочитать в официальном блоге или на странице GitHub.

Другая интересная новинка, это экспериментальная поддержка WebAssembly в качестве новой цели сборки, wasm32-unknown-emscripten. Поддержка находится на раннем этапе, поэтому разработчики просят помочь в тестировании и сообщать им о найденных ошибках. С установленным emscripten компиляция кода на Rust в WebAssembly выглядит следующим образом:

$ rustup target add wasm32-unknown-emscripten
$ echo 'fn main() { println!("Hello, Emscripten!"); }' > hello.rs
$ rustc --target=wasm32-unknown-emscripten hello.rs
$ node hello.js
Сообщество экспериментирует и делает интересную работу в этой сфере: некоторые примеры можно посмотреть на слайдах (Jan-Erik) с семинара Rust Belt Rust или классический проект TodoMVC (Tim Ryan) как пример, построенный на библиотеке webplatform (позволяет работать с DOM в Rust).

Касательно платформ, большое количество платформ получило дополнительную поддержку:

Для rustc:

  • mips-unknown-linux-gnu
  • mipsel-unknown-linux-gnu
  • mips64-unknown-linux-gnuabi64
  • mips64el-unknown-linux-gnuabi64
  • powerpc-unknown-linux-gnu
  • powerpc64-unknown-linux-gnu
  • powerpc64le-unknown-linux-gnu
  • s390x-unknown-linux-gnu

И для std:

  • arm-unknown-linux-musleabi
  • arm-unknown-linux-musleabihf
  • armv7-unknown-linux-musleabihf

Если вы используете одну из вышеперечисленных платформ, то следуйте инструкции по установке на сайте или добавляйте цели к текущей установке при помощи команды rustup target add.

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

Как и в примере работы сообщества над новой целью WebAssembly, в Rust на подходе другие, не менее примечательные, кроме вышеперечисленных, цели. Например, xargo упрощает кросс-компиляцию Rust для работы на голом железе. Если вы пишете операционную систему на Rust, или делаете что-то интересное на микроконтроллере, xargo может очень сильно облегчить вашу жизнь.

С появлением поддержки MIR в последних релизах, также продолжается работа над улучшением времени компиляции.

В языке появилось маленькое улучшение: поддержка RFC 1492. При помощи этого маленького улучшения увеличились места, где можно использовать ... Допустим, у вас есть структура:

struct Point {
    x: i32,
    y: i32,
    z: i32,
}
В любом контексте, где вы делаете сопоставление с образцом, вы могли использовать .., чтобы проигнорировать места, которые вам не интересны. Например:
let p = Point { x: 0, y: 1, z: 2 };

match p {
    Point { x, .. } => println!("x is {}", x),
}
.. игнорирует y и z.

Рассмотрим похожий Point, но в качестве структуры кортежа:

struct Point(i32, i32, i32);
Ранее, вы могли использовать .., чтобы проигнорировать все три элемента:
let p = Point(0, 1, 2);

match p {
    Point(..) => println!("found a point"),
} 
Но вы не могли использовать его, чтобы игнорировать часть кортежа:
let p = Point(0, 1, 2);

match p {
    Point(x, ..) => println!("x is {}", x),
}
Это привносило противоречивость, и теперь, когда RFC 1492 стабилизирован, в этом релизе всё замечательно компилируется. Это относится ко многим ситуациям кроме кортежей; для подробностей смотрите RFC.

Стабилизация библиотек

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

Более подробный список изменений.

Возможности Cargo

В Cargo был реализован RFC 1721. Cargo теперь будет передавать значение вывода команды rustc --print cfg сборочным скриптам. Мотивацией для этой функции послужила возможность Cargo компилировать объекты для статической компоновки с msvcrt под платформой MSVC.

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

Cargo теперь будет игнорировать конфигурацию panic для профилей test и bench. Это важно, так как человек запустивший тесты полагается на панику как непрошедший тест, и со значением panic=abort, непрошедший тест отменит весь набор тестов.

Более подробный список изменений.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: dotcoder (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

стандартный пень на 3 гигагерца, двухядерный
я ж забыл сделать релизную сборку :-)
да, у меня тоже меньше секунды - 0.139
а в гоу - 0.05 сек

все равно проигрыш почти в три раза

kto_tama ★★★★★
()
Последнее исправление: kto_tama (всего исправлений: 2)
Ответ на: комментарий от kto_tama

я ж забыл сделать релизную сборку :-)

Классика. И это уже ближе к истине.

все равно проигрыш почти в три раза

Вы сравниваете разные вещи.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от kto_tama

и раст - сам - закачивает и собирает эту библиотеку

И что, это основание считать любую стороннюю библиотеку частью стандартной?

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

Плохонький у тебя тест. Ты реализуй сам длинные числа на Go и Rust одинаково и тестируй. А так ты, возможно, сравниваешь разные реализации длинных чисел. Это может что-то говорить о том, что в Rust эти длинные числа работают медленней, чем могли бы, но делать на этом основании вывод о самом языке некорректно.

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

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

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

результат не всегда достигается минимумом кода.

Разумеется. А ещё ты можешь написать 1000 строк на JS за 20 часов и 12 часов их отлаживать, а на Java 24 и 40 соотвественно. Но по моему мнению проект с большей вероятностью быстрее напишется на JS.

Вот для примера, мне нужно было получить из строки запроса версию протокола и проверить, поддерживается ли она. Вот как это я сделал на Rust:

if query.get("p").map(|p| PROTOCOL_VERSIONS.iter().any(|&v| v == p)).unwrap_or(false) {/* ... */}
А если бы вместо него был Python, я написал бы вот так:
if query.get('p') in PROTOCOL_VERSIONS:
    # ...

Словом, в питоне я могу сосредоточиться на бизнес-логике и меньше париться с типами, в отличии от Rust. Поэтому запилить проект на питоне получится быстрее. Тоже самое и в Java и JS.

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

Так у вас в питоне нет проверки ошибок, а в расте есть. Типы тут вообще не при чём.

Но по моему мнению проект с большей вероятностью быстрее напишется на JS.

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

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Поэтому и кричать, что на динамических языках проще писать, смысла нет.

До определенного размера проекта — проще. Сопровождать же сложнее, имхо, вне зависимости от размера.

С аргументами Kilte в другом проблема: он сравнивает языки разного уровня.

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

У меня претензии к аргументации вида: «мне так кажется».

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

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

Взять бы всех питонописак, которые «меньше парятся с типами», да сжечь!

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

Вот как это я сделал на Rust

Вероятно, плохо сделал. Вот эквивалентный код:

if PROTOCOL_VERSIONS.contains(&query.get("p")?) {
}

Да, по итогу всё равно возни будет больше, но это от отсутствия исключений, а не от типизации.

Esper
()
Последнее исправление: Esper (всего исправлений: 1)
Ответ на: комментарий от Esper

Тут дело скорее в том, что None в Rust и None в Python — это две разные вещи. И что возможность отсутствия значения имеет самое непосредственное отношение к бизнес-логике.

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

А почему для раста ты код привел а для go нет?

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

Вероятно, плохо сделал. Вот эквивалентный код:

if PROTOCOL_VERSIONS.contains(&query.get("p")?) {
}

Да, по итогу всё равно возни будет больше, но это от отсутствия исключений, а не от типизации.

Это не эквивалент. Ты делаешь возврат ошибки, у него же в случае ошибки просто не выполнится if.

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

Ты делаешь возврат ошибки, у него же в случае ошибки просто не выполнится if.

А, ясно. Я думал, get выкидывает исключение. Впрочем, эмулировать contains через any - всё равно лютый ад.

Esper
()
Последнее исправление: Esper (всего исправлений: 1)
Ответ на: комментарий от Esper

Я решительно не понимаю, как можно было подумать иначе.

Это нормально.

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

Уже можно и фронтэнд и бэкэнд писать.

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

chimera19
()
Ответ на: комментарий от Esper

На тот момент не знал про contains. И тогда уж

if query.get("p").map(|p| PROTOCOL_VERSIONS.contains(&p)).unwrap_or(false) {
}

В случае с питоном исключения не будет. Там у словарей get возвращает None, если ключа не существует. Это ответ и RazrFalcon на

Так у вас в питоне нет проверки ошибок, а в расте есть. Типы тут вообще не при чём.

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

раз-раз и быстро что-то подправить

ага, раз-раз и в продакшн

А не ждать полчаса перекомпиляции.

В расте скоро будет инкрементальная компиляция.

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

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

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

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

чё стесняешься, давай сразу хаскель

anonymous
()
Ответ на: комментарий от Valeg

уже целую ОС навелосипедили.

Которая просто чтоб запуститься требует аж полгига памяти.

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

Которая просто чтоб запуститься требует аж полгига памяти.

микроядро же

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

Мои тесты:

1. Числа фибоначчи.

---/ GO /---

package main

import (
        "fmt"
        "math/big"
)

func main() {
        // Initialize two big ints with the first two numbers in the sequence.
        a := big.NewInt(0)
        b := big.NewInt(1)

        var limit big.Int
        limit.Exp(big.NewInt(10), big.NewInt(100000), nil)

        for a.Cmp(&limit) < 0 {
                // Compute the next Fibonacci number, storing it in a.
                a.Add(a, b)
                // Swap a and b so that b is the next number in the sequence.
                a, b = b, a
        }
        fmt.Println(a)
}

#go version go version go1.7.3 freebsd/amd64

#go build -o fibgo fib.go

#time ./fibgo

real 0m1.625s user 0m1.627s sys 0m0.015s

---/ RUST /---

extern crate num;
use num::{BigInt, Zero, One};
use num::bigint::ToBigInt;
use std::mem::swap;

fn main() {

    let mut f0: BigInt = Zero::zero();
    let mut f1: BigInt = One::one();

    let limit : BigInt = num::pow(10.to_bigint().unwrap(),100000);

    while f0 < limit {

        f0 = f0 + &f1;
        swap(&mut f0, &mut f1);

    }

    println!("{}", f0);
}

# rustc -V rustc 1.13.0

# cargo build --release

# time ./target/release/f

real 0m3.961s user 0m3.955s sys 0m0.000s

На текущий момент разница во времени ~2.4 раза (Go обгоняет Rust).

2. Тест на обычные целые + циклы, взят с http://www.freebasic.net/forum/viewtopic.php?t=23489 Тестирую С, Rust, Go.

---/ C /---

    #include <stdio.h>

    int main() {
      int left_edge, right_edge, top_edge, bottom_edge, max_iter,
        x_step, y_step, y0, x0, x, y, i, x_x, y_y, temp,
        the_char, accum, count;

      accum = 0;
      count = 0;
      while (count < 1545) {
        left_edge = -420;
        right_edge  =  300;
        top_edge  =  300;
        bottom_edge = -300;
        x_step    =  7;
        y_step    =  15;

        max_iter  =  200;

        y0 = top_edge;
        while (y0 > bottom_edge) {
          x0 = left_edge;
          while (x0 < right_edge) {
            y = 0;
            x = 0;
            the_char = 32;
            x_x = 0;
            y_y = 0;
            i = 0;
            while (i < max_iter && x_x + y_y <= 800) {
              x_x = (x * x) / 200;
              y_y = (y * y) / 200;
              if (x_x + y_y > 800 ) {
                the_char = 48 + i;
                if (i > 9) {
                  the_char = 64;
                }
              } else {
                temp = x_x - y_y + x0;
                if ((x < 0 && y > 0) || (x > 0 && y < 0)) {
                  y = (-1 * ((-1 * (x * y)) / 100)) + y0;
                } else {
                  y = x * y / 100 + y0;
                }
                x = temp;
              }
              i = i + 1;
            }
            accum = accum + the_char;
            x0 = x0 + x_step;
          }
          y0 = y0 - y_step;
        }
        if (count % 300 == 0) {
          printf("%d\n", accum);
        }
        count = count + 1;
      }
      printf("%d\n", accum);
      return 0;
    }

# gcc49 -O2 -o newc new.c

#time ./newc

real 0m1.852s user 0m1.849s sys 0m0.001s

---/ Rust /---

    fn main() {
      let mut left_edge;
      let mut right_edge;
      let mut top_edge;
      let mut bottom_edge;
      let mut max_iter;
      let mut x_step;
      let mut y_step;
      let mut y0;
      let mut x0;
      let mut x;
      let mut y;
      let mut i;
      let mut x_x;
      let mut y_y;
      let mut temp;
      let mut the_char;
      let mut accum;
      let mut count;

      accum = 0;
      count = 0;
      while count < 1545 {
        left_edge = -420;
        right_edge  =  300;
        top_edge  =  300;
        bottom_edge = -300;
        x_step    =  7;
        y_step    =  15;

        max_iter  =  200;

        y0 = top_edge;
        while y0 > bottom_edge {
          x0 = left_edge;
          while x0 < right_edge {
            y = 0;
            x = 0;
            the_char = 32;
            x_x = 0;
            y_y = 0;
            i = 0;
            while i < max_iter && x_x + y_y <= 800 {
              x_x = (x * x) / 200;
              y_y = (y * y) / 200;
              if x_x + y_y > 800 {
                the_char = 48 + i;
                if i > 9 {
                  the_char = 64;
                }
              } else {
                temp = x_x - y_y + x0;
                if (x < 0 && y > 0) || (x > 0 && y < 0) {
                  y = (-1 * ((-1 * (x * y)) / 100)) + y0;
                } else {
                  y = x * y / 100 + y0;
                }
                x = temp;
              }
              i = i + 1;
            }
            accum = accum + the_char;
            x0 = x0 + x_step;
          }
          y0 = y0 - y_step;
        }
        if count % 300 == 0 {
          println!("{}", accum);
        }
        count = count + 1;
      }
      println!("{}", accum);
    }

#rustc -C opt-level=2 -o newrs new.rs

#time ./newrs

real 0m2.001s user 0m1.992s sys 0m0.008s

---/ GO /---

package main

import "fmt";

func main() {


    var left_edge, right_edge, top_edge, bottom_edge, max_iter,
        x_step, y_step, y0, x0, x, y, i, x_x, y_y, temp,
        the_char, accum, count int;
    accum = 0;
    count = 0;

    for (count < 1545) {

        left_edge = -420;
        right_edge  =  300;
        top_edge  =  300;
        bottom_edge = -300;
        x_step    =  7;
        y_step    =  15;

        max_iter  =  200;

        y0 = top_edge;
        for (y0 > bottom_edge) {
          x0 = left_edge;
          for (x0 < right_edge) {
            y = 0;
            x = 0;
            the_char = 32;
            x_x = 0;
            y_y = 0;
            i = 0;
            for (i < max_iter && x_x + y_y <= 800) {
              x_x = (x * x) / 200;
              y_y = (y * y) / 200;
              if (x_x + y_y > 800) {
                the_char = 48 + i;
                if (i > 9) {
                the_char = 64;
                }
              } else {
                temp = x_x - y_y + x0;
                if ((x < 0 && y > 0) || (x > 0 && y < 0)) {
                  y = (-1 * ((-1 * (x * y)) / 100)) + y0;
                } else {
                  y = x * y / 100 + y0;
                }
                x = temp;
              }
              i = i + 1;
            }
            accum = accum + the_char;
            x0 = x0 + x_step;
          }
          y0 = y0 - y_step;
        }
        if (count % 300 == 0) {
          fmt.Printf("%d\n", accum);
        }
        count = count + 1;
      }
      fmt.Printf("%d\n", accum);
}

#go build -o newgo new.go

#time ./newgo

real 0m2.897s user 0m2.896s sys 0m0.009s

Как я понимаю go по умолчанию ставит оптимизацию. (Верно?) Если собирать без оптимизации (go build -gcflags '-N -l' -o newgo new.go), то результаты хуже.

Во втором тесте Rust идет почти на уровне С, а Go сильно похуже. Так что возможно в первом тесте сильно влияет реализация НЕ стандартной библиотеки.

Возражения?

...новую версию раста 1.14 еще не тестил...жду в портах фрибсд

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

Возражения?

Да. Публикуйте свои простыни где-нибудь на paste.org

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

Возражения?

Виновата реализация крейта num. конкретно:

  • рабочая лошадка BigDigit (u32)
  • вычисления выполняются в DoubleBigDigit (u64). Нижняя часть это результат, а верхняя это переполнение (которое либо 0 либо 1). В итоге на 64 битной системе, на один u32 у нас 2 сложения.
  • могло бы быть через adc, итого было бы 1 сложение на u64
  • всё потому, что feature(asm) unstable
  • занавес.
anonymous
()
Ответ на: комментарий от anonymous

Что-то мне кажется, что разработчики num тупо не читали документацию. Вот есть сложение с переносом. https://doc.rust-lang.org/beta/std/primitive.u64.html#method.overflowing_add

Возможно стоим им завести issue или даже прислать патч?

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

Что-то мне кажется, что разработчики num тупо не читали документацию. Вот есть сложение с переносом. https://doc.rust-lang.org/beta/std/primitive.u64.html#method.overflowing_add

Возможно стоим им завести issue или даже прислать патч?

Конечно будет лучше, но всё же минимум раза в два хуже чем c использованием asm для x86/amd64 (этих горе ISA).

anonymous
()
Ответ на: комментарий от Gorthauer

А почему это вдруг этот метод не должен превратиться в adc?

Он то превратится, но посмотри на вывод.

	addq	8(%rsi), %rcx
	addq	(%rdx), %rax
	adcq	$0, %rcx

Нет способа указать, чтобы компилятор использовал CF нормально. Нужен не overflowing_add, а overflowing_add_with_carry. С циклами или большими цислами вообще цирк.

.LBB0_2:
	testq	%rdx, %rdx
	je	.LBB0_3
	movq	(%rdx), %rcx
	addq	(%rdi,%rax,8), %rcx
	leaq	1(%rax), %rax
	sbbb	%r10b, %r10b
	addq	%rbx, %rcx
	sbbb	%bl, %bl
	orb	%r10b, %bl
	movq	%rcx, (%rdx)
	andb	$1, %bl
	movzbl	%bl, %ebx
	addq	$8, %rdx
	cmpq	%r9, %rax
	jb	.LBB0_2
.LBB0_3:

Вот для сравнения как можно написать вручную:

	clc
.Ltmp5:
	movq	(%rdi,%rbx,8), %rax
	adcq	%rax, (%rcx,%rbx,8)
	incq	%rbx
	decq	%rdx
	jne	.Ltmp5

anonymous
()
Ответ на: комментарий от mersinvald

Ага, только всё равно слишком много возни.

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

Только разница в том что все уже готово и работает в nightly, и библиотеки уже поправили, осталось только все протестировать и попадет в релиз.

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

У меня есть вопрос почему во втором тесте ты понизил оптимизацию со стандартного -C opt-level=3(который делает cargo --release) до 2, неужели так быстрее?
А еще нужно протестировать код на C собрав clang версии 3.9 тогда будет видно где разница gcc vs LLVM а где оверхед из за семантики rust.

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

Напоминает крики Java-разрабов. «Ждем версии $JAVA_VER+1, там будут все крутые фичи, вот тогда заживем!»

Все фичи уже есть, ждём стабилизации.

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

Как быть Васе, если у него по каким-то причинам нет возможности пересесть на Rust-1.10?

Насколько я могу судить, многие (оценка, разумеется, очень субъективная) вообще ночной раст используют.

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

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

Но вообще интересно, что может мешать обновляться на стабильную версию

Целевая система, которую запрещено обновлять.

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

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

Опять этот сарказм и демонстрация «опыта». А если подумать, то понятно, что при необходимости ориентироваться на древние дистрибутивы и нет возможности доставить нужное, то раст и так отпадает. Собственно можно начинать рассказывать о том, что заказчик будет диктовать и требования по выбору языка и прочее бла бла бла.

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

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

да мне без разницы, сторонняя это библиотека или не сторонняя

Тебя правда не смущает, что ты берёшь библиотеку с непонятной реализацией и сравниваешь со (судя по всему) стандартными вещами в другом языке и делаешь выводы о производительности языков, а не реализаций BigInt?

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

Допустим, что да.

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

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

Допустить-то мы что угодно можем, мне интересно насколько это реально на практике.

Насколько реально что именно - запрет на обновление системы? Совершенно реален. Наличие в составе такой системы транслятора Rust? На конец 2016 года нереально, дальше - почему бы и нет.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от eao197

Как-то я это сообщение пропустил. Если административные причины, то и решение такое-же - закладываем в сроки/стоимость разработки бэкпортирование нужных фич библиотеки на нужную версию раста.

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

Опять этот сарказм и демонстрация «опыта».

Сарказм относился к тому, что был задан простой вопрос, на который ожидался простой ответ «нравится»/«не нравится» и «создает проблемы»/«не создает». Вместо этого понеслось «а зачем», «а когда это может стать проблемой» и т.д.

заказчик будет диктовать

Будет. Обязательно будет. Rust уникален тем, что развивается намного интенсивнее, чем любые другие языки, с которыми доводилось сталкиваться. Вот и интересно, релизы языка каждые 2 месяца — это создает какие-то проблемы или нет.

Но, видимо, пока Rust нигде всерьез не используется, поэтому и проблем нет.

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