reduce это ни разу ни foldLeft, о чём я как раз и пишу. Однородная свёртка удобна далеко не всегда.
Стримы в Java могут быть последовательными — у них есть соответствующая характеристика.
грубо говоря, если бы этот метод был, он имел бы полное право вернуть разные значения для двух последовательных вызовов
Этот метод мог бы иметь возвращаемое значение типа (T, Stream<T>) (с поправкой на то, что в джаве нету кортежей) и поглощать исходный поток — как, в общем-то, сейчас все операции над стримами и работают.
Я вполне в курсе, почему API выглядит именно так. Про проблемы стримового API уже много писали. В частности, эта широко рекламируемая параллелизация одной строкой кода в 95% случаев не нужна, а там, где нужна, как правило гораздо лучше воспользоваться специализированным под конкретную задачу решением. Разработчикам Java нужно было бы исходить из практичности, а не из весьма сомнительных идеалов.
Да, именно поэтому я и говорю про половинчатость :) к счастью, я давно уже работаю только на скале, но за джаву у меня, можно сказать, «душа болит») Мне не очень понятно, зачем авторы Java пошли по ущербному пути, не пользуясь всеми существующими наработками. Когда я спросил на Stackoverflow, почему в библиотеке потоков нет самой обычной последовательной свёртки, мне ответили, что
the API doesn't provide this is that the designers don't want encourage people to write non-parallelizable code
Несмотря на то, что лямбды и библиотека операций над коллекциями — это очень большой шаг вперёд, он всё равно какой-то половинчатый. Многих идиом, совершенно естественных в аналогичных библиотеках в других языках, просто нет — чего только стоит отсутствие банального foldLeft и, например, возможности разделить поток на голову и хвост без преобразования в итератор. Несериализуемый Optional, который рекомендуется использовать только и исключительно в контексте коллекций. Много боли также от несовместимости примитивов и объектных типов. Такие библиотеки, как ваша, здорово с этим помогут :)
Да, конкретно эта проблема довольно известна. Как мне кажется, её очень здорово решили в Scala — идентификаторы в паттерне, начинающиеся с маленькой буквы, всегда обозначают байндинги, а с большой — сравнение с конкретным значением. Но в Rust такой подход вряд ли прокатит, хотя бы потому что нет возможности эскейпить произвольные строки для использования как идентификаторов.
Я не очень понимаю причём здесь ToPrimitive, потому что он целиком и полностью заменяется кастом через as. FromPrimitive — да, его нестабильность пока что проблема.
А в целом enum'ы в Rust — это совсем другая концепция, чем enum'ы в С/C++ и прочем. Это алгебраические типы данных, tagged union'ы, если хотите — даже если они и могут быть представлены числами, как значения они с числами несовместимы. Собственно, именно поэтому непосредственно ваш пример не работает и не заработает никогда — и, имхо, это хорошо: лучше, когда котлеты отдельно от мух.
Под низкоуровневостью подразумевалось программирование в окружении с точным контролем над ограниченными ресурсами — в том числе, памятью. Скажем, программирование реалтаймовых систем.
Мой же поинт в том, что «драйвера» и по-настоящему «низкоуровневый код» — это достаточно узкая сфера и сводить к ней «нишу С++» не совсем корректно.
В том-то и дело — уже давно C++ используется либо в легаси-проектах, либо там, где нужна производительность (та самая «низкоуровневость», условно). В других областях он уже давно вытеснен более подходящими языками, и Go — только один из них. Повторюсь, именно поэтому когда говорят об «убийце C++», подразумевают язык, который способен вытеснить C++ из самых основных оставшихся ниш.
Это не моё определение. Отсутствие рантайма — необходимое условие для языка системного программирования. Вот определение с википедии:
A system programming language usually refers to a programming language used for system programming; such languages are designed for writing system software, which usually requires different development approaches when compared to application software.
System software is computer software designed to operate and control the computer hardware, and to provide a platform for running application software. System software includes software categories such as operating systems, utility software, device drivers, compilers, and linkers.
Два ключевых элемента — операционные системы и драйверы — на Go писать абсолютно непрактично, именно из-за того, что в Go многие фичи языка основаны на рантайме, который использовать в ОС/драйверах не получится. Безусловно, вы можете отключить рантайм и писать драйверы, и получится это гораздо легче, чем, например, на Java — но Go для этого не предназначен, и поэтому это будет просто пожирание кактуса. И именно поэтому Go не является заменой C++. А Rust — пусть и потенциально, но является, потому что он изначально проектировался практичным для тех областей, где используется C++, и он отлично работает даже на голом железе, что подтверждается проектами вроде zinc.rs.
С тем, что в определённых областях Go действительно заменяет C++, спорить действительно бессмысленно — вспомнить тот же докер. Но в подавляющем большинстве случаев соответствующие программы (вроде GUI-приложений) с самого начала стоило бы писать на чём-то более высокоуровневом.
Собственно, проблема в терминологии здесь в том, что когда говорят «замена C++», подразумевают такой язык, который способен заменить C++ именно в тех областях, где ему пока нет конкурентов — в низкоуровневом программировании. В большинстве других областей вместо C++ уже давно используются более подходящие языки.
видятся разработчики Rust'а, которые будут в свой проект пихать любые возможности, что захотят. Если не ошибаюсь, в след. стабильной версии они хотят к существующему способу обработок ошибок (с try!() и Result<>), добавить еще и исключения. Т.е. сразу они не могли понять что им нужно, поэтому ничто не остановит их в будущем еще что-то поменять и превратить Rust в ту-же «legacy помойку» как и C++, где в оном ничего нельзя изменить из-за совместимости
Я не знаю, почему у вас создалось такое впечатление, но оно очень далеко от реальности. Я также не знаю, где вы услышали про исключения — ничего подобного в планах нет и не предвидится.
Кроме того, в Rust никогда не тащили фичи просто так. Вы же не видели Rust где-то с два-три года назад, так? С точностью до наоборот, всё это время из языка пытались исключить лишние фичи, и что-то новое вводилось после обсуждения и с обоснованием необходимости. Посмотрите репозиторий github.com/rust-lang/rfcs — там практически у каждого RFC, в особенности связанных с масштабными изменениями, обсуждение растягивается на много страниц. У авторов языка есть весьма чёткое видение целей и задач в его отношении, а спорные моменты разрешаются в обсуждениях в тех же RFC или на форумах.
Можете поподробнее рассказать про match? Вот рабочая программа, с преобразованиями в обе стороны:
#![feature(core)]
use std::num::FromPrimitive;
#[repr(u8)]
#[derive(FromPrimitive)]
enum Number {
One, Two, Three
}
fn main() {
match Number::One as u8 {
0 => {}
_ => {}
}
match Number::from_u8(0) {
Some(Number::One) => {},
_ => {}
}
}
Да, пока что FromPrimitive — нестабильный трейт (поэтому его нельзя использовать с бетой), ну так и язык пока ещё только в бете.
Ну если я в C попытаюсь сравнить struct и int, то gcc мне так и напишет, что, мол, разные типы. А rustc мне писал (enum и u8) на пол страницы ошибок и я пол-часа вычитывал что-же он от меня хочет и как это исправить.
Вот такой код:
struct X;
fn main() {
match X {
10 => {}
}
}
даёт такую ошибку:
test2.rs:5:9: 5:11 error: mismatched types:
expected `X`,
found `_`
(expected struct `X`,
found integral variable) [E0308]
test2.rs:5 10 => {}
^~
error: aborting due to previous error
Нет, это не так. Go не является заменой C++ даже близко — он гораздо ближе по области применения к языкам вроде Python и Erlang. В частности, Go не является языком системного программирования, в частности, из-за рантайма и сборщика мусора, которые хоть и можно отключить, но без которых язык становится практически бесполезен. Насколько я помню, сами авторы писали, что жалеют, что называли его «systems programming language».
это из-за того, что в Rust'е постоянно менялся API, да и человеческой документации нет
Я на Stackoverflow регулярно отвечаю на вопросы про Rust и могу гарантированно заявить, что вопросов про изменившиеся API весьма мало, гораздо меньше, чем вопросов по существу.
Документация в виде официального гайда вполне себе наличествует и всё время совершенствуется, да и с API-документацией тоже в последнее время всё очень неплохо. Книга The Rust Programming Language очень хорошо рассказывает про особенности языка — в частности, там есть и пример использования enum'а в match.
Насчёт ошибок компилятора — вы извините, но ошибки от компилятора Rust по понятности даже близко не сравнить с ошибками от gcc, например. rustc и покажет в точности где произошла ошибка, опишет её совершенно прямолинейным английским и даже даст совет по её исправлению. Да. они занимают много места, ну и что? Как правило, большая часть ошибок — это куски кода с выделением, где собственно находится ошибка. Конечно, ничто не совершенно, и rustc ещё много где нужно доработать в плане сообщений об ошибках — и этим, в частности, разработчики собираются заниматься при подготовке финального релиза.
Как уже много раз говорилось, в стабильных версиях API серьёзно меняться не будет.
Весьма распространено заблуждение о том, что Go — это замена C++, в каждом обсуждении Rust кто-нибудь такое говорит. Go — не язык для системного программирования, у них с C/C++ и Rust совершенно разные нишы.
Vala, насколько я знаю, никогда особо и не рекламировали как убийцу C++, и у неё весьма своеобразная инфраструктура на основе GObject, которая, собственно, и не вышла за пределы Gnome и соседствующих проектов.
D — да, он позиционировался и позиционируется как улучшенный C++, но он развивался именно как «C++ с человеческим лицом». Да, он проще и удобнее C++, многих противоречивых фич там нет и много полезного добавлено, плюс бинарная совместимость с C++ с возможностью линковаться к C++-библиотекам (кроме D и, собственно, C++ так больше ни один язык не умеет), но как язык он практически ничего нового не привнёс. К тому же, насколько я знаю, его подвели проблемы в развитии — переход с D1 на D2, общая скорость развития низка. Например, сравните — 1637 вопросов по D на Stackoverflow начиная с 2008 года и 1841 вопрос по Rust, начиная, фактически, с 2013 года. Из-за того, что язык развивался и изменялся очень активно, многие грабли уже были собраны и исправлены. Я участвую в сообществе Rust уже несколько лет, и за последние год-два интерес к языку вырос колоссально. Релиз стабильной версии, я думаю, окажет ещё большее воздействие.
В отличие от других «убийц» Rust действительно принёс новые идеи, вернее, весьма практичную, полезную и удобную реализацию не очень известных ранее идей — владение данными и заимствование, которые на самом деле решают конкретные проблемы. Плюс полезные и удобные фичи из других языков, вроде трейтов-тайпклассов и паттернматчинга. Да, пока что в Rust есть острые углы, и реализовано далеко не всё, что хотелось бы, но и темпов развития авторы языка снижать не собираются.
В GPS учитываются по крайней мере два эффекта, предсказанных теорией относительности: замедление времени в гравитационном поле (ОТО) и замедление времени в движущейся системе (СТО). Очень кратко и популярно про это есть тут.
А вот понять, почему не стареет улетающий близнец, хотя относительно него улетала вся Вселенная, вот этого я понять не могу.
Тут уже про это говорили, но на самом деле ключевой момент формулируется просто. Когда один из близнецов улетает и возвращается обратно, он подвергается ускорению. В отличие от простого равномерного движения, которое действительно «относительно», ускорения ни разу не относительные, и для двух объектов всегда можно указать, какой из них ускорялся, а какой — нет. Собственно, в этом и заключается «асимметрия».
Hoshi правильно написал. В ОТО гравитация ничего не вызывает — она наблюдается нами как «сила притяжения», но на самом деле это такое искривление самого пространства, что «прямые» линии в нём (геодезические) больше не «прямые», а искривлённые. За счёт этого искривления, вызываемого массивными объектами, траектории объектов меняются, что мы и наблюдаем как «притяжение».
Вы не можете списать пример с GPS на неточность измерения и изготовления оборудования. Вы вообще понимаете, как это работает? Грубо говоря, если не вносить поправки, вычисленные согласно ОТО, GPS-позиционирование не будет работать вообще — вернее, с течением времени оно будет давать всё большую и большую ошибку, причём очень быстро. Это как раз и есть то, что называется экспериментальным подтверждением теории, и на таких подтверждениях держится современная физика — благодаря которой, например, вы можете сейчас читать хабр.
В математических теориях не бывает исключений, вы что-то путаете. Поскольку математические теории основаны на строгой логике, в них могут быть только логические противоречия — и тогда такие теории отбрасываются, поскольку в противоречивых теориях можно вывести всё, что угодно. В физических теориях тоже исключений не бывает — теория либо описывает данное явление, либо нет. Не описывать явление теория может либо в том смысле, что это другая область для этой теории (например, теория идеального газа не применима к твёрдым телам), либо же если её предсказания расходятся с экспериментом — и тогда либо теория дорабатывается, либо находится новая теория, которая включает в себя старую (как и произошло с ньютоновой механикой и теорией относительности, когда ТО «поглотила» НМ).
Стримы в Java могут быть последовательными — у них есть соответствующая характеристика.
Этот метод мог бы иметь возвращаемое значение типа
(T, Stream<T>)(с поправкой на то, что в джаве нету кортежей) и поглощать исходный поток — как, в общем-то, сейчас все операции над стримами и работают.Я вполне в курсе, почему API выглядит именно так. Про проблемы стримового API уже много писали. В частности, эта широко рекламируемая параллелизация одной строкой кода в 95% случаев не нужна, а там, где нужна, как правило гораздо лучше воспользоваться специализированным под конкретную задачу решением. Разработчикам Java нужно было бы исходить из практичности, а не из весьма сомнительных идеалов.
что, на мой взгляд, является полным BSом.
Несмотря на то, что лямбды и библиотека операций над коллекциями — это очень большой шаг вперёд, он всё равно какой-то половинчатый. Многих идиом, совершенно естественных в аналогичных библиотеках в других языках, просто нет — чего только стоит отсутствие банального foldLeft и, например, возможности разделить поток на голову и хвост без преобразования в итератор. Несериализуемый Optional, который рекомендуется использовать только и исключительно в контексте коллекций. Много боли также от несовместимости примитивов и объектных типов. Такие библиотеки, как ваша, здорово с этим помогут :)
ToPrimitive, потому что он целиком и полностью заменяется кастом черезas.FromPrimitive— да, его нестабильность пока что проблема.А в целом enum'ы в Rust — это совсем другая концепция, чем enum'ы в С/C++ и прочем. Это алгебраические типы данных, tagged union'ы, если хотите — даже если они и могут быть представлены числами, как значения они с числами несовместимы. Собственно, именно поэтому непосредственно ваш пример не работает и не заработает никогда — и, имхо, это хорошо: лучше, когда котлеты отдельно от мух.
В том-то и дело — уже давно C++ используется либо в легаси-проектах, либо там, где нужна производительность (та самая «низкоуровневость», условно). В других областях он уже давно вытеснен более подходящими языками, и Go — только один из них. Повторюсь, именно поэтому когда говорят об «убийце C++», подразумевают язык, который способен вытеснить C++ из самых основных оставшихся ниш.
Два ключевых элемента — операционные системы и драйверы — на Go писать абсолютно непрактично, именно из-за того, что в Go многие фичи языка основаны на рантайме, который использовать в ОС/драйверах не получится. Безусловно, вы можете отключить рантайм и писать драйверы, и получится это гораздо легче, чем, например, на Java — но Go для этого не предназначен, и поэтому это будет просто пожирание кактуса. И именно поэтому Go не является заменой C++. А Rust — пусть и потенциально, но является, потому что он изначально проектировался практичным для тех областей, где используется C++, и он отлично работает даже на голом железе, что подтверждается проектами вроде zinc.rs.
С тем, что в определённых областях Go действительно заменяет C++, спорить действительно бессмысленно — вспомнить тот же докер. Но в подавляющем большинстве случаев соответствующие программы (вроде GUI-приложений) с самого начала стоило бы писать на чём-то более высокоуровневом.
Собственно, проблема в терминологии здесь в том, что когда говорят «замена C++», подразумевают такой язык, который способен заменить C++ именно в тех областях, где ему пока нет конкурентов — в низкоуровневом программировании. В большинстве других областей вместо C++ уже давно используются более подходящие языки.
Я не знаю, почему у вас создалось такое впечатление, но оно очень далеко от реальности. Я также не знаю, где вы услышали про исключения — ничего подобного в планах нет и не предвидится.
Кроме того, в Rust никогда не тащили фичи просто так. Вы же не видели Rust где-то с два-три года назад, так? С точностью до наоборот, всё это время из языка пытались исключить лишние фичи, и что-то новое вводилось после обсуждения и с обоснованием необходимости. Посмотрите репозиторий github.com/rust-lang/rfcs — там практически у каждого RFC, в особенности связанных с масштабными изменениями, обсуждение растягивается на много страниц. У авторов языка есть весьма чёткое видение целей и задач в его отношении, а спорные моменты разрешаются в обсуждениях в тех же RFC или на форумах.
Можете поподробнее рассказать про match? Вот рабочая программа, с преобразованиями в обе стороны:
Да, пока что FromPrimitive — нестабильный трейт (поэтому его нельзя использовать с бетой), ну так и язык пока ещё только в бете.
Вот такой код:
даёт такую ошибку:
test2.rs:5:9: 5:11 error: mismatched types: expected `X`, found `_` (expected struct `X`, found integral variable) [E0308] test2.rs:5 10 => {} ^~ error: aborting due to previous errorЯ не знаю, что может быть понятнее.
Я на Stackoverflow регулярно отвечаю на вопросы про Rust и могу гарантированно заявить, что вопросов про изменившиеся API весьма мало, гораздо меньше, чем вопросов по существу.
Документация в виде официального гайда вполне себе наличествует и всё время совершенствуется, да и с API-документацией тоже в последнее время всё очень неплохо. Книга The Rust Programming Language очень хорошо рассказывает про особенности языка — в частности, там есть и пример использования enum'а в match.
Насчёт ошибок компилятора — вы извините, но ошибки от компилятора Rust по понятности даже близко не сравнить с ошибками от gcc, например. rustc и покажет в точности где произошла ошибка, опишет её совершенно прямолинейным английским и даже даст совет по её исправлению. Да. они занимают много места, ну и что? Как правило, большая часть ошибок — это куски кода с выделением, где собственно находится ошибка. Конечно, ничто не совершенно, и rustc ещё много где нужно доработать в плане сообщений об ошибках — и этим, в частности, разработчики собираются заниматься при подготовке финального релиза.
Как уже много раз говорилось, в стабильных версиях API серьёзно меняться не будет.
Vala, насколько я знаю, никогда особо и не рекламировали как убийцу C++, и у неё весьма своеобразная инфраструктура на основе GObject, которая, собственно, и не вышла за пределы Gnome и соседствующих проектов.
D — да, он позиционировался и позиционируется как улучшенный C++, но он развивался именно как «C++ с человеческим лицом». Да, он проще и удобнее C++, многих противоречивых фич там нет и много полезного добавлено, плюс бинарная совместимость с C++ с возможностью линковаться к C++-библиотекам (кроме D и, собственно, C++ так больше ни один язык не умеет), но как язык он практически ничего нового не привнёс. К тому же, насколько я знаю, его подвели проблемы в развитии — переход с D1 на D2, общая скорость развития низка. Например, сравните — 1637 вопросов по D на Stackoverflow начиная с 2008 года и 1841 вопрос по Rust, начиная, фактически, с 2013 года. Из-за того, что язык развивался и изменялся очень активно, многие грабли уже были собраны и исправлены. Я участвую в сообществе Rust уже несколько лет, и за последние год-два интерес к языку вырос колоссально. Релиз стабильной версии, я думаю, окажет ещё большее воздействие.
В отличие от других «убийц» Rust действительно принёс новые идеи, вернее, весьма практичную, полезную и удобную реализацию не очень известных ранее идей — владение данными и заимствование, которые на самом деле решают конкретные проблемы. Плюс полезные и удобные фичи из других языков, вроде трейтов-тайпклассов и паттернматчинга. Да, пока что в Rust есть острые углы, и реализовано далеко не всё, что хотелось бы, но и темпов развития авторы языка снижать не собираются.
Тут уже про это говорили, но на самом деле ключевой момент формулируется просто. Когда один из близнецов улетает и возвращается обратно, он подвергается ускорению. В отличие от простого равномерного движения, которое действительно «относительно», ускорения ни разу не относительные, и для двух объектов всегда можно указать, какой из них ускорялся, а какой — нет. Собственно, в этом и заключается «асимметрия».