Вышел Rust 1.0 Beta

Значит нет. Мне нужна среда на подобие QtCreator'а с подсветкой и авто дополнением.

Есть vim с подсветкой и автодополнением.

А где бенчмарки rust vs go, rust vs c++, rust vs java(script)?

Не удивлюсь, если ржавчина сольёт node.js в тестах.

Возможно. Но запускается нода очень долго. У меня в тестах около 30 запусков интерпретатора с минимумом кода. Выполняются 2 секунды

Это ты ещё джаву не видел.

Для низкоуровневых операций, где каждый бит дорог, ничего лучше asm всё равно не будет

fixed

Очередная попытка сделать C++, только лучше. Ничего путного не выйдет

пока получается вполне годно. я не уверен, что rust по фичам приближается к С++, но уж точно обходит С, при этом (по крайней мере, так заявлено) без ущерба для производительности

Т.е. Вас просто назначили на неподходящую для вас часть проекта.

ни разу не видел в вакансиях (или резюме) что-то вроде

знаю C++, кроме templates, overloading

Исключений нет.

Вут? Что это за новая мода пошла..

Ну в расте оно может и к месту. В принципе есть panic, вроде как он прибивает поток, а не программу, так что можно писать всякие серверы без прокидывания SQLException-ов наверх.

py

if "chunked" in request.transfer_encodings:
   return

ruby

return if request.transfer_encodings.include? 'chunked'

d

if (request.transferEncodings.canFind("chunked"))
   return;

c++

const auto& arr = request.transfer_encodings;
if (find(arr.begin(), arr.end(), string("chunked")) != arr.end())
   return;

Как тоже самое будет на Rust? Пока я так и ну услышал ни одного реального преимущества над D. Понятно дело, что в каких-то очень узких местах может быть перевес, но вопрос, на сколько в реальных задачах язык будет удобен. Пока что, что никаких преимуществ не нашел.

Реальная задача - катить арбуз поиск подстроки?

Задача простых примеров показать на сколько просто тривиальные задачи решаются.

if request.transferEncodings.contains("chunked") {
    return;
}

если я правильно понял, что ты хочешь.

можно и во втором случае contains.

Да, cgi будет тормозить и на том и на другом. Вот интересно, а go тоже нетороплив при запуске?

Пока я так и ну услышал ни одного реального преимущества над D

Нет GC, куда реальнее-то.

разрабатывается некоммерческой организацией, в отличие от

Вот интересно, а go тоже нетороплив при запуске?

не, норм, быстро стартует

каждый топик по расту на любом форуме это детектор неосиливших кресты

Сравнивать &str и String напрямую нельзя же. В случае с contains придется делать «chunked».to_string(), т.е. аллоцировать вектор символов в куче. У того чудика сверху в примере с С++ так и делается, лол. А в моем примере String-и (std::string) без какого то оверхеда кастуются в &str (const char*) и сравниваются с &'static str (static const char*).

http://www.ioann.ru/parts/put-sudba/pochemu-nuzhno-nesti-svoj-krest

каждый топик по расту на любом форуме это детектор неосиливших кресты

Ты забыл ещё про D, go и др. Есть одно обстоятельство: целиком осилившему кресты в их современном виде больше уже ничего не нужно от жизни.

Сравнивать &str и String напрямую нельзя же.

А в моем примере String-и (std::string) без какого то оверхеда кастуются в &str (const char*) и сравниваются с &'static str (static const char*).

Внимательно посмотри как реализованно сравнение строк

целиком осилившему кресты в их современном виде больше уже ничего не нужно от жизни

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

Вру. Сравнивать можно, есть стандартная реализация трейта:

impl<`a> PartialEq<&`a str> for String
impl<`a> PartialEq<String> for &`a str

Ты забыл ещё про D, go и др

ескобар.джпеге

современном виде

в современном виде вобще норм

Сравнивать &str и String напрямую нельзя же. В случае с contains придется делать «chunked».to_string(), т.е. аллоцировать вектор символов в куче. У того чудика сверху в примере с С++ так и делается, лол. А в моем примере String-и (std::string) без какого то оверхеда кастуются в &str (const char*) и сравниваются с &'static str (static const char*).

Ну да, тоже верно. С другой стороны можно хранить все заголовки исходного сообщения, как один массив байтов в объекте запроса, а в этом массиве transfer_encoding хранить &str, ссылающиеся на этот массив.

Нет GC, куда реальнее-то.

И где вам GC мешает-то?

Квазицитаты балансируют. http://docs.scala-lang.org/overviews/quasiquotes/intro.html

И где вам GC мешает-то?

Мне на андроиде мешает

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf

In particular, when garbage collection has five times as much memory as required, its runtime performance matches or lightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management.

Теперь посмотри, сколько твой браузер съедает памяти, умножь на 5, и подумай, почему мозилла не хочет писать свой следующий браузер на языке с GC. Или умножь на всего на 2, но представь его медленнее в 1,5 раза. Ну ты понял.

А вот и неправильно. В (идиоматичном) Rust изначально был бы создан enum со всеми возможными значениями transfer_encodings. Для примера смотрите как это делают в любой сетевой либе из Cargo.

неосиливших кресты

Как будто в этом что-то плохое.

мудило на крестах такой же неосилятор как и все кто ему ответил потом

if (find(arr.begin(), arr.end(), «chunked») != arr.end())

у std::basic_string есть operator==() который принимает const CharT*

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

будет как с gtk и gimp, язык под одно приложение

Не понятно, как ты так решил - memory safety без GC это прямой конкурент С/С++ - но даже в этом случае, это будет на одно приложение больше, чем D.

Гомоиконность же

Это только разработчикам компиляторов нужно.

открой для себя наконец то std::shared_ptr<>

если ты про borrow checking то нужность данной вещи весьма сомнительна

Зачем она нужна, если нет макросов?

каждое приложение на плюсах — это детектор неосиливших кресты.

fixed

Для персистентности, к примеру. В лиспе можно просто сохранить в файл sexp, не мучаясь со всякими xmlями и jsonами.

ООП там совсем другое.

Аминь

Именно поэтому Rust никогда не взлетит. Единственный язык который активно используется и имеет сильно другое ООП - это javascript, но так уж сложилось и альтернативы тут просто нет, и объем кода обычно позволяет обойтись без тяжелого ООП.

Ничего существенного, прорывного в плане развития индустрии программирования rust предложить не может. Поэтому его удел - домашние проектики задротов-илитариев.

Именно поэтому Rust никогда не взлетит. Единственный язык который активно используется и имеет сильно другое ООП - это javascript

В Go похожее ООП (гораздо более угребищное за счет отсутствия дженериков).

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

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

Ну, кроме того, если язык гомоиконный, ему не нужны макросы.

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

-- data.lua
Entity({1, 2, {"yo"})
Entity({"two", "three")
...

-- main.lua
function Entity(...)
  -- Сохранить даные 
end
dofile("data.lua")

Но это только десериализация. А вот сериализацию не сделаешь ни через sexp ни через другие языки. Так что XML или JSON.