Что отличает Раст от других языков, так это его система типов, основанная на улучшенном и кодифицированном своде лучших практик, отработанных поколениями программистов на C и C++. Так что Расту есть что предложить как опытным системных программистам, так и новичкам: опытные разработчики оценят сэкономленное на отладке время, а новичкам придётся по вкусу возможность писать низкоуровневый код, не беспокоясь о мелких ошибках, которые приводят к необъяснимым падениям их программ.
Что значит для Раста релиз 1.0?
Текущая версия Раста — результат множества итераций и экспериментов. Такой процесс разработки прекрасно нам послужил: Раст сейчас намного проще и мощнее, чем мы изначально представляли. Но из-за всех этих экспериментов поддерживать проекты, написанные на Расте, было очень сложно, так как язык и стандартная библиотека постоянно менялись.
Релиз версии 1.0 означает, что этому беспорядку пришёл конец. Этот релиз — официальное начало нашему пути к поддержанию стабильности (англ.). Начиная с этого момента изменения, ломающие совместимость, будут за пределами стабильной версии (за исключением некоторых вещей, вроде багов в компиляторе).
Учитывая сказанное, релиз 1.0 не означает, что язык Раст «завершён». У нас в запасе множество улучшений. На самом деле, ночные сборки уже содержат улучшения в скорости компиляции (а их будет ещё больше) и включают новые API и фичи языка, такие, как
std::fs и ассоциированные константы.Чтобы быть уверенными, что улучшения в компиляторе и языке входят в экосистему как можно более полно и быстро, мы решили использовать train-based модель релизов. Это означает, что мы будем выпускать регулярные релизы каждые шесть недель, как это делают команды Firefox и Chrome. Чтобы начать этот процесс, мы также выпускаем бета-релиз Раста 1.1 — одновременно со стабильным релизом 1.0.
Cargo и crates.io
Создание настоящего проекта — это не только написание кода, это ещё и управление зависимостями. Cargo — пакетный менеджер и система сборки Раста — создан, чтобы облегчить эту задачу. С использованием Cargo скачивание и установка новых библиотек проста настолько же, насколько просто добавить новую строчку в файл манифеста.
Конечно, чтобы использовать зависимость, её нужно сначала найти. Здесь появляется crates.io — центральный репозиторий пакетов Раста. С его помощью очень просто и искать чужие пакеты, и публиковать свои.
С момента анонсирования cargo и crates.io — месяцев шесть назад — число пакетов стабильно растёт. Однако сейчас мы в самом начале пути, так что есть ещё много замечательных пакетов, которые нужно написать. Если вам интересно создавать новые библиотеки, которые потрясут мир Раста — сейчас самое время!
Открытые и исходники, и управление
Раст был open-source проектом с самого начала. Последние несколько лет мы постоянно искали способы сделать наше руководство более открытым и управляемым сообществом. С тех пор, как мы ввели процесс RFC, чуть больше года назад, все основные решения по поводу Раста записываются и обсуждаются открыто. Недавно мы приняли новую модель управления, которая состоит в разделении на подкоманды, каждая из которых будет отвечать за RFC в своей определённой области. Если вы хотите помочь определить будущее Раста, мы будем рады любому вашему участию: загружайте библиотеки на crates.io, комментируйте RFC, или пишите сам код Раста.
Мы бы хотели выразить особую благодарность следующим людям, каждый из которых привнёс свой вклад с момента нашего предыдущего релиза (полный список контрибуторов здесь):
- Aaron Gallagher <_@habnab.it>
- Aaron Turon <aturon@mozilla.com>
- Abhishek Chanda <abhishek@cloudscaling.com>
- Adolfo Ochagavia <aochagavia92@gmail.com>
- Alex Burka <durka42+github@gmail.com>
- Alex Crichton <alex@alexcrichton.com>
- Alex Quach <alex@clinkle.com>
- Alexander Polakov <plhk@sdf.org>
- Andrea Canciani <ranma42@gmail.com>
- Andreas Martens <andreasm@fastmail.fm>
- Andreas Tolfsen <ato@mozilla.com>
- Andrei Oprea <andrei.br92@gmail.com>
- Andrew Paseltiner <apaseltiner@gmail.com>
- Andrew Seidl <dev@aas.io>
- Andrew Straw <strawman@astraw.com>
- Andrzej Janik <vosen@vosen.pl>
- Aram Visser <aramvisser@gmail.com>
- Ariel Ben-Yehuda <arielb1@mail.tau.ac.il>
- Augusto Hack <hack.augusto@gmail.com>
- Avdi Grimm <avdi@avdi.org>
- Barosl Lee <vcs@barosl.com>
- Ben Ashford <ben@bcash.org>
- Ben Gesoff <ben.gesoff@gmail.com>
- Bjorn Steinbrink <bsteinbr@gmail.com>
- Brad King <brad.king@kitware.com>
- Brendan Graetz <github@bguiz.com>
- Brett Cannon <brettcannon@users.noreply.github.com>
- Brian Anderson <banderson@mozilla.com>
- Brian Campbell <lambda@continuation.org>
- Carlos Galarza <carloslfu@gmail.com>
- Carol (Nichols || Goulding) <carol.nichols@gmail.com>
- Carol Nichols <carol.nichols@gmail.com>
- Chris Morgan <me@chrismorgan.info>
- Chris Wong <lambda.fairy@gmail.com>
- Christopher Chambers <chris.chambers@peanutcode.com>
- Clark Gaebel <cg.wowus.cg@gmail.com>
- Cole Reynolds <cpjreynolds@gmail.com>
- Colin Walters <walters@verbum.org>
- Conrad Kleinespel <conradk@conradk.com>
- Corey Farwell <coreyf@rwell.org>
- Dan Callahan <dan.callahan@gmail.com>
- Dave Huseby <dhuseby@mozilla.com>
- David Reid <dreid@dreid.org>
- Diggory Hardy <github@dhardy.name>
- Dominic van Berkel <dominic@baudvine.net>
- Dominick Allen <dominick.allen1989@gmail.com>
- Don Petersen <don@donpetersen.net>
- Dzmitry Malyshau <kvarkus@gmail.com>
- Earl St Sauver <estsauver@gmail.com>
- Eduard Burtescu <edy.burt@gmail.com>
- Erick Tryzelaar <erick.tryzelaar@gmail.com>
- Felix S. Klock II <pnkfelix@pnkfx.org>
- Florian Hahn <flo@fhahn.com>
- Florian Hartwig <florian.j.hartwig@gmail.com>
- Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
- FuGangqiang <fu_gangqiang@163.com>
- Garming Sam <garming_sam@outlook.com>
- Geoffrey Thomas <geofft@ldpreload.com>
- Geoffry Song <goffrie@gmail.com>
- Gleb Kozyrev <gleb@gkoz.com>
- Graydon Hoare <graydon@mozilla.com>
- Guillaume Gomez <guillaume1.gomez@gmail.com>
- Hajime Morrita <omo@dodgson.org>
- Hech <tryctor@gmail.com>
- Heejong Ahn <heejongahn@gmail.com>
- Hika Hibariya <hibariya@gmail.com>
- Huon Wilson <dbau.pp+github@gmail.com>
- Igor Strebezhev <xamgore@ya.ru>
- Isaac Ge <acgtyrant@gmail.com>
- J Bailey <jj2baile@uwaterloo.ca>
- Jake Goulding <jake.goulding@gmail.com>
- James Miller <bladeon@gmail.com>
- James Perry <james.austin.perry@gmail.com>
- Jan Andersson <jan.andersson@gmail.com>
- Jan Bujak <j@exia.io>
- Jan-Erik Rediger <janerik@fnordig.de>
- Jannis Redmann <mail@jannisr.de>
- Jason Yeo <jasonyeo88@gmail.com>
- Johann <git@johann-hofmann.com>
- Johann Hofmann <git@johann-hofmann.com>
- Johannes Oertel <johannes.oertel@uni-due.de>
- John Gallagher <jgallagher@bignerdranch.com>
- John Van Enk <vanenkj@gmail.com>
- Jonathan S <gereeter+code@gmail.com>
- Jordan Humphreys <mrsweaters@users.noreply.github.com>
- Joseph Crail <jbcrail@gmail.com>
- Josh Triplett <josh@joshtriplett.org>
- Kang Seonghoon <kang.seonghoon@mearie.org>
- Keegan McAllister <kmcallister@mozilla.com>
- Kelvin Ly <kelvin.ly1618@gmail.com>
- Kevin Ballard <kevin@sb.org>
- Kevin Butler <haqkrs@gmail.com>
- Kevin Mehall <km@kevinmehall.net>
- Krzysztof Drewniak <krzysdrewniak@gmail.com>
- Lee Aronson <lee@libertad.ucsd.edu>
- Lee Jeffery <leejeffery@gmail.com>
- Liam Monahan <liam@monahan.io>
- Liigo Zhuang <com.liigo@gmail.com>
- Luke Gallagher <luke@hypergeometric.net>
- Luqman Aden <me@luqman.ca>
- Manish Goregaokar <manishsmail@gmail.com>
- Manuel Hoffmann <manuel@polythematik.de>
- Marin Atanasov Nikolov <dnaeon@gmail.com>
- Mark Mossberg <mark.mossberg@gmail.com>
- Marvin Lobel <loebel.marvin@gmail.com>
- Mathieu Rochette <mathieu@rochette.cc>
- Mathijs van de Nes <git@mathijs.vd-nes.nl>
- Matt Brubeck <mbrubeck@limpet.net>
- Michael Alexander <beefsack@gmail.com>
- Michael Macias <zaeleus@gmail.com>
- Michael Park <mcypark@gmail.com>
- Michael Rosenberg <42micro@gmail.com>
- Michael Sproul <micsproul@gmail.com>
- Michael Woerister <michaelwoerister@gmail>
- Michael Wu <mwu@mozilla.com>
- Michal Czardybon <mczard@poczta.onet.pl>
- Mickael Salaun <mic@digikod.net>
- Mike Boutin <mike.boutin@gmail.com>
- Mike Sampson <mike@sambodata.com>
- Ms2ger <ms2ger@gmail.com>
- Nelo Onyiah <nelo.onyiah@gmail.com>
- Nicholas <npmazzuca@gmail.com>
- Nicholas Mazzuca <npmazzuca@gmail.com>
- Nick Cameron <ncameron@mozilla.com>
- Nick Hamann <nick@wabbo.org>
- Nick Platt <platt.nicholas@gmail.com>
- Niko Matsakis <niko@alum.mit.edu>
- Oak <White-Oak@users.noreply.github.com>
- Oliver Schneider <github6541940@oli-obk.de>
- P1start <rewi-github@whanau.org>
- Pascal Hertleif <killercup@gmail.com>
- Paul Banks <banks@banksdesigns.co.uk>
- Paul Faria <paul_faria@ultimatesoftware.com>
- Paul Quint <DrKwint@gmail.com>
- Pete Hunt <petehunt@users.noreply.github.com>
- Peter Marheine <peter@taricorp.net>
- Phil Dawes <phil@phildawes.net>
- Philip Munksgaard <pmunksgaard@gmail.com>
- Piotr Czarnecki <pioczarn@gmail.com>
- Piotr Szotkowski <chastell@chastell.net>
- Poga Po <poga.bahamut@gmail.com>
- Przemyslaw Wesolek <jest@go.art.pl>
- Ralph Giles <giles@mozilla.com>
- Raphael Speyer <rspeyer@gmail.com>
- Remi Rampin <remirampin@gmail.com>
- Ricardo Martins <ricardo@scarybox.net>
- Richo Healey <richo@psych0tik.net>
- Rob Young <rob.young@digital.cabinet-office.gov.uk>
- Robin Kruppe <robin.kruppe@gmail.com>
- Robin Stocker <robin@nibor.org>
- Rory O’Kane <rory@roryokane.com>
- Ruud van Asseldonk <dev@veniogames.com>
- Ryan Prichard <ryan.prichard@gmail.com>
- Scott Olson <scott@scott-olson.org>
- Sean Bowe <ewillbefull@gmail.com>
- Sean McArthur <sean.monstar@gmail.com>
- Sean Patrick Santos <SeanPatrickSantos@gmail.com>
- Seo Sanghyeon <sanxiyn@gmail.com>
- Shmuale Mark <shm.mark@gmail.com>
- Simon Kern <simon.kern@rwth-aachen.de>
- Simon Sapin <simon@exyr.org>
- Simonas Kazlauskas <git@kazlauskas.me>
- Sindre Johansen <sindre@sindrejohansen.no>
- Skyler <skyler.lipthay@gmail.com>
- Steve Klabnik <steve@steveklabnik.com>
- Steven Allen <steven@stebalien.com>
- Swaroop C H <swaroop@swaroopch.com>
- Sebastien Marie <semarie@users.noreply.github.com>
- Tamir Duberstein <tamird@gmail.com>
- Tero Hanninen <tejohann@kapsi.fi>
- Theo Belaire <theo.belaire@gmail.com>
- Theo Belaire <tyr.god.of.war.42@gmail.com>
- Thiago Carvalho <thiago.carvalho@westwing.de>
- Thomas Jespersen <laumann.thomas@gmail.com>
- Tibor Benke <ihrwein@gmail.com>
- Tim Cuthbertson <tim@gfxmonk.net>
- Tincan <tincann@users.noreply.github.com>
- Ting-Yu Lin <aethanyc@gmail.com>
- Tobias Bucher <tobiasbucher5991@gmail.com>
- Toni Cardenas <toni@tcardenas.me>
- Tshepang Lekhonkhobe <tshepang@gmail.com>
- Ulrik Sverdrup <root@localhost>
- Vadim Chugunov <vadimcn@gmail.com>
- Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
- Valerii Hiora <valerii.hiora@gmail.com>
- Wangshan Lu <wisagan@gmail.com>
- Wei-Ming Yang <rick68@users.noreply.github.com>
- Will <will@glozer.net>
- Will Hipschman <whipsch@gmail.com>
- Wojciech Ogrodowczyk <github@haikuco.de>
- Xue Fuqiao <xfq.free@gmail.com>
- Xuefeng Wu <xfwu@thoughtworks.com>
- York Xiang <bombless@126.com>
- Young Wu <doomsplayer@gmail.com>
- bcoopers <coopersmithbrian@gmail.com>
- critiqjo <john.ch.fr@gmail.com>
- diwic <diwic@users.noreply.github.com>
- fenduru <fenduru@users.noreply.github.com>
- gareins <ozbolt.menegatti@gmail.com>
- github-monoculture <eocene@gmx.com>
- inrustwetrust <inrustwetrust@users.noreply.github.com>
- jooert <jooert@users.noreply.github.com>
- kgv <mail@kgv.name>
- klutzy <klutzytheklutzy@gmail.com>
- kwantam <kwantam@gmail.com>
- leunggamciu <gamciuleung@gmail.com>
- mdinger <mdinger.bugzilla@gmail.com>
- nwin <nwin@users.noreply.github.com>
- pez <james.austin.perry@gmail.com>
- robertfoss <dev@robertfoss.se>
- rundrop1 <rundrop1@zoho.com>
- sinkuu <sinkuupump@gmail.com>
- tynopex <tynopex@users.noreply.github.com>
- Lukasz Niemier <lukasz@niemier.pl>
- ????? <ryogo.yoshimura@gmail.com>
Комментарии (61)
MrShoor
16.05.2015 00:56+2Я понимаю что язык молодой, но может к нему уже есть какие-либо быстро развивающиеся инструменты? Интересуют IDE с синтаксически корректным автокомплитом и хороший дебагер.
hell0w0rd
16.05.2015 01:04+7Rust до первых бета-версий был динамично развивающимся на столько, что код, работающий еще вчера, можно было не скомпилировать уже сегодня.
Однако есть некоторые движения в этом направлении, в частности racer — движок для автокомплита из любого редактора (плагин под atom, на пример). Также есть плагин под IDEA.
withkittens
16.05.2015 01:08+3Добавлю:
— Visual Rust — плагин для VS.
— Scrawl (очередной платный редактор? хотя выглядит вкусно) пилит поддержку Rust (Rust is very likely to be a first-class citizen. Community tooling is promising and should mature quickly now that Rust is 1.0)
PsyHaSTe
22.05.2015 18:17Visual Rust классный плагин, однако не поддерживает 2015 студию… Фиг с ним, попрограммировал бы и в блокнотике, но не нашел подсветку синтаксиса для раста. Не подскажете, может знаете, как можно из такой ситуации выйти, не снося 2015 студию?
withkittens
22.05.2015 20:18Хм, VS Community 2013 хорошо уживается рядом с 2015-й студией. Если не хотите ставить студию ради Rust, ещё есть, например, подсветка синтаксиса в Sublime.
PsyHaSTe
25.05.2015 22:54Нашел оптимальный способ — прямо на сайте языка: play.rust-lang.org
Из плюсов: подсветка синтаксиса, запускается везде, где есть интернет, внятные сообщения об ошибке — в студии большая часть ошибок фактически пишет только RS1234 в таком виде, или type mismatch, без указания, собственно, типов, что усложняет отладку и без того непростого языка с не таким уж большим числом документации и примеров, можно шарить шортлинками исходники.
Минусов как таковых разве что необходимость фигачить всё в один файл, для более-менее сложных проектов непригодно, но вот разобраться самое оно.withkittens
26.05.2015 01:30А-а, да, удобная штука. Я ей пользуюсь, чтобы накидывать примерчики и отшлифовывать острые углы :)
Ещё из минусов — вы ограничены стандартной библиотекой, подключить какие-то зависимости нельзя.
kstep Автор
26.05.2015 11:50Ну play как бы для быстрых экспериментов и для поделиться примером кода, а не для серьёзной разработки.
fogone
16.05.2015 18:23+11Я человек измученный нарзаном, т.е. джавой. И раст мне показался чем-то действительно свежим и новым, хорошо продуманным и инновационным, с приемлемой сложностью, быстрым рантаймом и без сборщика мусора. На мой взгляд раст одна из самых значимых ступеней современного языкостроения.
OberonForGood
17.05.2015 00:10+5Я согласен с Вами, мне кажется, Rust это будущее системного программирования.
mezastel
16.05.2015 20:02-8Уверен, что количество комментариев к этому топику примерно коррелирует с количеством заинтересованных в этом языке людей. То же самое можно сказать и про D (который мне нравится больше). Думаю у обоих этих языков было бы намного больше шансов если бы сейчас сам С++ не развивался семимильными шагами. Да, «плюсы» это естественно легаси, но последние подвижки плюс то что должно в скором времени выйти (например модули) может поставить С++ примерно на уровень C#/Java, хотя конечно и с поправкой на то что все равно уровень комфорта этих языков так просто не достичь.
ptQa
16.05.2015 23:44+4Как минимум у Rust больше шансов на успех чем у D поскольку за ним стоит Mozilla, которая на нем делает серьезный проект (servo). Т.е. это не язык ради языка. Да, для плюсов есть статические анализаторы, но когда они встроены в язык они как бы направляют программиста на путь истинный с первых «Hello worldов».
ptQa
16.05.2015 23:48-1+ Как следствие, тут создатели языка заинтересованы в стабильности и единообразии в отличии от D. Который имеет две несовместимых версии и две доминирующих библиотеки с одинаковой функциональность.
Korobochka
17.05.2015 03:23+5Интересно, сколько лет будет повторяться этот стереотип?..
Никаких активных изменений в D1 уже давно не происходит, а проблема со стандартными библиотеками решена несколько лет назад, сейчас даже вроде есть порт Tango на D2, совместимый с обычной стандартной библиотекой. А также менеджер пакетов и репозиторий для них (code.dlang.org).
В любом случае, D и Rust — очень разные языки, так что сравнивать тут особо нечего.
justaguest
18.05.2015 21:58-4но последние подвижки плюс то что должно в скором времени выйти (например модули) может поставить С++ примерно на уровень C#/Java
Да ни в коем случае! Вы же просто шутите, верно? Я не могу говорить за Java, но недавно вынужден был пописать на C#, и для меня, пришедшего из С++, он просто ужасен.
• Темлэйты. Пока в C# нет аналога темплэйтов, проекты (недавно и я) обречены на написание огромного кол-ва повторяемого кода. Вы же, надеюсь, не будете утверждать, что аналог темплэйтов — это дженерики, правда? ;)
• Мутная типизация числовых типов. Это просто убийственно — я занимался тем, что портировал относительно несложный код с С++ на C#, и подобные вещи меня убивали — попробуйте скомпилировать следующий код:
UInt16 two = 2; UInt16 foo = two + 2;
У вас будет выбор: либо писать, используя правильные размеры, но кастуя в каждой третьей строке, либо писать неправильно, зато без кастов. Прелестно.
• Полурабочий «sizeof». Он не может брать размеры переменных, только размеры типов. Это означает, что, если у меня в структуре есть переменная х типа UInt16, и я однажды ее поменяю на UInt32, мне придется перерывать весь код в поисках, где я делал «sizeof(UInt16)», подразумевая «sizeof(x)».
Вообще в C# знатный бардак с размерами типов. Например мне пришлось потерять как-то кучу времени на отладку, прежде, чем я понял, что хваленный, и везде рекомендуемый «Marshal.SizeOf(myStruct)» в моем случае не работает. Он возвращал мне неправильный размер структуры из-за того, что там был массив байтов — а с массивами он работает неправильно, причем в компиляторе нет даже предупреждения на эту очевидную ошибку (ибо кому может понадобиться брать размер массива, если заведомо вернется неверное значение?). При этом «Marshal.SizeOf()» применяется на объекте, а не на типе, т.о. логично ожидать, что возвращать он будет размер, занимаемый объектом.
Да, безусловно, например в полюбившимся последнее время Хаскелле, мне тоже неизвестно ничего подобного — но, черт подери, это же Хаскелл! Это сущая мелочь, в сравнении с тем, что ты получаешь. Что я получаю взамен в С#?
• Watchpoint'ы. Недавно мне крайне необходимо было воспользоваться подобным функционалом, и… Как выяснилось, их нет в C#. То есть не то, что их нет в конкретном дебаггере от Моно, или от Студии, либо еще где-то — словам людей с SO они принципиально невозможны в связи с устройством сборщика мусора, который имеет полное право двигать существующие объекты, приводя к ложным срабатываниям.
• В С++ есть любопытная малоизвестная конструкция стиля «if (const char* foo = myFunc()) {puts(foo)}»(disclaimer: внутри скобок «if» провозглашается переменная, и используется далее в блоке). Штука спорная, но мой опыт показывает, что плюсы использования перевешивают минусы. Потому что, когда у вас есть несколько функций 50-100 строк, которые вызывают одна другую, и в какой-то из них, вы точно знаете, есть ошибка — вам приходится тщательно проследить за каждой переменной, что бы понять, что с ними происходит. И, чем уже область видимости подобных переменных, тем меньше боли вам это доставит. Надо ли говорить, что аналога C# не имеет.
• Деструкторы. О-о, да, одно из самых слабых мест C#. Деструкторы вызываются в рэндомный момент, и потому не несут практически никакой пользы. Что же делать? Я не слышу, кто-то упомянул Disposable? Это аналог деструкторам, да? Это же великолепно, давайте напишем класс, которому жизненно необходим освобождать какой-то ресурс при выходе за область видимости, и обнаружим, что… эту функцию мы должны вызывать вручную! Какой смысл в нем, если мы должны делать все руками? Нет, я знаю, мы можем написать конструкцию в стиле «using (var x = new myDisposableType()){/*code*/}», вот только единственное место, откуда пользователь класса об этом узнает — один из комментариев в документации к классу. И дай Бог, что бы он был очень внимательным, когда будет читать это тысячное описание, т.к. компилятор даже предупреждения не вставит, если он забудет использовать подобного рода конструкцию, а об этом маленьком нюансе он узнает только после длительной и муторной отладки (потому что не всегда проблема, вызванной не-удалением ресурса, может быть очевидно, как было в моем случае).
• Кроссплатформенность. Нет, не упоминайте Моно, прошу, даже мое несложное приложение не работает там, как хотелось бы, из-за древнего бага, касающегося таймаута в серийных портах.
Это только то, что я смог вспомнить навскидку, но моя память говорит, что это были не единственные проблемы такого рода. Вы же ведь не серьезно это С++ сравнили с C#, вы просто шутили, верно?
P.S. Ох, как много текста… Прошу прощения, вынужден кодить какое-то время на этом языке, просто уж очень сильно накопилось :)mezastel
18.05.2015 22:40-3Проблемы которые вы ощущаете вполне реальны но все же весьма специфичны. То есть например как раз с типизацией все спорно т.к. в С++ непонятно что такое int вообще (т.е. сколько оно бит). Все что я хотел сказать это то что по степени комфорта общего программирования, не вдаваясь в сложные кейсы, С++ может дойти почти до уровня C#/Java.
justaguest
18.05.2015 23:28-3Вполне себе понятно — для «int» определена только нижняя граница в 2??. У него нет верхней границы, он может сколь угодно простираться, вы видите очень длинную прямую, чей хвост скрывается и меркнет вдали под влиянием Допплеровского эффекта. Если необходимо знать битность числа, то еще великие древние, что кодили на чистом С, использовали типы из стандартной библиотеки, вроде «int32_t» (limits.h)
Все что я хотел сказать это то что по степени комфорта общего программирования, не вдаваясь в сложные кейсы, С++ может дойти почти до уровня C#/Java.
Должно быть, вы хотели сказать «снизойти»? Потому что, даже, когда я мысленно вычеркиваю все упомянутое, и ставлю, казалось бы, вровень, эти языки — у меня остается в памяти, что в C# на каждой пятой строчке, я должен не забыть создать объект с помощью слова new. И да, вполне допустимо умудриться где-то не инициализовать поле, и обнаружить это только в рантайме. Какой вообще смысл использовать сборщик мусора, если я должен писать в полях класса это слово, тогда как, в столь, почему-то, принижаемом вами С++, поле с объектом в простейшем случае само о себе позаботится (для наглядности, создайте в C# класс с объектом List<>, и в С++ класс с объектом std::vector<>).
В С++ я могу провозглашать объекты на стеке, не пользуясь словом new, и делая свой код намного меньше, и, в то же время, будучи уверенным, что за меня об инициализации объекта позаботятся добрые дяди из GNU (ведь случаи использования кучи так же специфичны, как и прошлые примеры, верно?;).
a553
18.05.2015 23:43+2Вы же, надеюсь, не будете утверждать, что аналог темплэйтов — это дженерики, правда? ;)
Буду. В большинстве случаев, то, что есть в темплейтах, но не удобно сделать в дженериках, это костыли С++ ввиду отсутствия метаданных.Мутная типизация числовых типов.
Нахрена в методах использовать что-то меньше int? И ничего мутного нет, вся арифметика проводится только в int, и это даже отчасти хорошо. А в ваших short x + 2 вы наверняка забыли checked, да?Он не может брать размеры переменных, только размеры типов.
Marshal.SizeOfс массивами он работает неправильно
Вы не понимаете, что возвращает Marshal.SizeOf. Почитайте документацию.Деструкторы. О-о, да, одно из самых слабых мест C#.
Это сильная сторона C#, потому что это фича из низкоуровнего мира в высокоуровневом языке.Потому что, когда у вас есть несколько функций 50-100 строк, которые вызывают одна другую, и в какой-то из них, вы точно знаете, есть ошибка — вам приходится тщательно проследить за каждой переменной, что бы понять, что с ними происходит.
Разделите на классы и методы. Привет, ООП.компилятор даже предупреждения не вставит, если он забудет использовать подобного рода конструкцию
Предупреждение входит в базовый пакет Code Analysis.
Извините, но вы бред пишете. Не пишите больше, пожалуйста.justaguest
19.05.2015 00:04+1Буду. В большинстве случаев, то, что есть в темплейтах, но не удобно сделать в дженериках, это костыли С++ ввиду отсутствия метаданных.
Простите… «Костыли»? Серьезно? Напишите-ка мне на C# функцию, принимающую объект любого класса, и вызывающую функцию foo() из этого класса. Если у вас это получится, я возьму свои слова назад.
Нет, это в самом деле смешно — то есть тот факт, что я могу сделать больше на С++, и, при этом, сделать проверку во время компиляции, вы считаете костылем? Простите, у меня официальный опыт программирования всего год, но даже я уже знаю, что ошибки надо по максимуму находить во время компиляции, а не в рантайме. Вы, должно быть, новенький?
Нахрена в методах использовать что-то меньше int? И ничего мутного нет, вся арифметика проводится только в int, и это даже отчасти хорошо.
«Зачем делать ?, мне никогда не нужно было… о.о» Простите, но вам не кажется, что это детский вопрос. Если оно вам не нужно было, вероятно это не означает, что оно не нужно совсем ни кому. Конкретно в моем случае, у меня есть протокол передачи данных по каналам связи, и каждое поле там определенного размера. Зачем такого маленького размера? Да, что бы у вас же, уважаемый a553, не тормозил ютьюб. То есть, это, конечно, утрированный пример, с моим приложением вы, скорее всего, никогда не встретитесь — но заголовки пакетов надо делать настолько маленькими, насколько это возможно.
Вы не понимаете, что возвращает Marshal.SizeOf. Почитайте документацию.
Сейчас я понимаю, но, когда ты пытаешься написать приложение, следуя многочисленным гайдам и туториалам, где проблема совершенно однозначно решается неким способом, причем даже название метода соответствует тому, что все идет правильно — ты сначала пишешь код, а потом удивляешься, почему все хреново. Должно быть вы идеальный программист, кто после туториалов сразу кропотливо перечитывает документацию на каждую примененную функцию?
Разделите на классы и методы. Привет, ООП.
Все уже за вас продумано, и разделено. Это не отменяет, что есть некие функции размером в 50-100 строк, которые делить еще дальше просто нет смысла по разным причинам. У вас такого, должно быть, не бывает?
Предупреждение входит в базовый пакет Code Analysis.
Простите… Что? Я использую IDE Mono, и редактор Емакс. Для особо проблемного дебага запускаю Студию. Где там, для чего это, говорите, плагин? Емакса? Ах, нет, должно быть Моно?
Извините, но вы бред пишете. Не пишите больше, пожалуйста.
Если учесть, что я не увидел ни одного серьезного довода, зато вы обозвали меня юродивым, должно быть у вас что-то не в порядке с логикой. Не пишите сюда больше ;)a553
19.05.2015 00:13Лень отвечать на всё, вот вам ваши самые большие ошибки:
Напишите-ка мне на C# функцию, принимающую объект любого класса, и вызывающую функцию foo() из этого класса.
Да пожалуйста.
А вообще используйте интерфейсы.void M(dynamic o) { o.foo(); }у меня есть протокол передачи данных по каналам связи, и каждое поле там определенного размера
Текст не читай @ сразу отвечай. От ваших вычислений в short-ах у меня ютуб и тормозит :)название метода соответствует тому, что все идет правильно
Именно. Прочитайте всё-таки. Там абсолютно явно написано Marshal.Я использую IDE Mono, и редактор Емакс.
ССЗБjustaguest
19.05.2015 00:24Да пожалуйста.
void M(dynamic o) { o.foo(); }
Что ж… Беру слова назад — я не знал про это. Любопытно.
Я использую IDE Mono, и редактор Емакс.
ССЗБ
Я просто к чему говорю — этот ваш пакет, это сторонняя утилита. Я не должен для элементарных вещей искать статический анализ кода, а подобное предупреждение именно элементарно. Откуда разработчик может знать об этом? Должно быть, из случайного комментария на хабре?
deniskreshikhin
19.05.2015 12:41+3Простите, что встреваю, но с этим трудно согласиться
Буду. В большинстве случаев, то, что есть в темплейтах, но не удобно сделать в дженериках, это костыли С++ ввиду отсутствия метаданных.
Темплейты это вообще отдельный подход, мало связанный с дженериками и ООП. Темплейты вводят в c++ программирование типов, т.е. можно выполнять операции над типами во время компиляции — составлять списки типов, заменять типы и т.д. Т.е. это ещё один язык программирования на этапе компиляции, тьюринг полный.
Это легко продемонстировать, например можно вычислить факториал числа на этапе компиляции:
#include <iostream> template <int N> struct Factorial { enum { val = Factorial<N-1>::val * N }; }; template<> struct Factorial<0> { enum { val = 1 }; }; int main() { std::cout << Factorial<4>::val << "\n"; }
Темплейты это не замена рефлексии в java по определению, это совершенно другой подход в программировании, называемый метапрограммированием. Появление темплейтов было связано с желанием построить универсальную библиотеку для работы с абстрактными данными без вычислительного оверхеда, к ООП это имеет малое отношение.
Другой факт, уже исторический. Темплейты появились в С++ уже в 1994 году. Первая версия java была выпущена в 1996 году, и на тот момент в ней не было даже дженериков. Дженерики появились только в 2004 году.
Поэтому с исторической точки зрения, правильнее сказать, что дженерики это костыль который был привнесён в java что бы добавить немного метапрограммирования.a553
19.05.2015 13:16+1Единственный валидный пункт у вас — это то, что темплейты выполняются на этапе компиляции. Но именно это и есть самый большой костыль: большинству программ требуется, чтобы темплейты выполнялись на этапе компиляции, поэтому темплейты реализованы именно так. (Посмотрите, кстати, какое количество проблем из-за этого появилось.)
На самом деле вам не нужно знать факториал какого-то числа на этапе компиляции. Вас в этом убедил сам язык С++. Называется синдром жертвы. :) Это самому С++ нужны списки типов (потому что средств описать тип в рантайме очень немного, и они достаточно бедны), и это именно С++ нужны вычислимые константы, чтобы, скажем, выделить память нужного размера на стеке.
В большинстве случаев от темплейтов вы ожидаете константной и минимальной сложности выполнения какой-то операции. Например, вычисления факториала. Это — самая основная и главная цель метапрограммирования: взять себя, посмотреть внимательно и получить какую-то информацию, в данном случае, способ оптимизировать алгоритм. И программы на Java и C# реализуют метапрограммирование превосходно.
дженерики это костыль который был привнесён в java что бы добавить немного метапрограммирования
Ну а это полная чушь. Дженерики, тем более в Java, не относятся к метапрограммированию.deniskreshikhin
19.05.2015 15:20+2Я не особый любитель ни C++, ни Java. Тем не менее, придется некоторые вопросы осветить более подробно, что бы вывести дискуссию из тени таких чудовищных заблуждений.
На самом деле вам не нужно знать факториал какого-то числа на этапе компиляции.
В вычислительных программах иногда требуется максимально использовать априорную информацию, что бы оптимальным образом разместить объекты в памяти, убрать ненужные условные переходы, уйти от использования виртуальных функций, наследования. Т.е. всего того, что даже в С++ приводит к оверхеду.
Как пример, структура алгоритма может зависеть от свойств некоторого числа N. Конечно это не ряд фибоначи, это может быть что-то более сложное, вроде разложения на примитивные корни по модулю m.
И это никак не связано с отсутствием рефлексии, даже если бы она была, это не помогло бы исключать ненужные ветви выполнения кода без условных переходов и vtable.
Называется синдром жертвы.
А это называется «приписывание ярлыков», см. labeling theory
и это именно С++ нужны вычислимые константы, чтобы, скажем, выделить память нужного размера на стеке
Любому языку требуется информация о размере блока памяти, что бы выделить нужное количество памяти. Чем больше информации, тем больше возможностей для оптимизации. Но темплейты не для этого, хотя и могут быть использованы для передачи дополнительной информации о размерах.
Это — самая основная и главная цель метапрограммирования: взять себя, посмотреть внимательно и получить какую-то информацию, в данном случае, способ оптимизировать алгоритм.
С таким же успехом можно и javascript называть языком с метапрограммированием. Там тоже интерпретатор присматривается во время синтаксического анализа к коду, что бы для числовых массивов использовалась оптимизированная реализация. Но это не метапрограммирование, абсолютно.
Цель метапрограммирования — создавать программы которые создают программы.
И программы на Java и C# реализуют метапрограммирование превосходно.
Ну эта тема много раз поднималась на стековерфлоу, так что просто приведу ссылки:
Is metaprogramming possible in C#?
No, metaprogramming of this complexity is not supported directly by the C# language...
Is static metaprogramming possible in Java?
No, this is not possible. Generics are not as powerful as templates....
Ну а это полная чушь. Дженерики, тем более в Java, не относятся к метапрограммированию.
Во-первых, я не писал что они относятся к метапрограммированию, а писал что дженерики это костыль который был привнесён в java что бы добавить немного метапрограммирования.
Во-вторых, дженерики являются элементом обобщенного программирования т.н. generic programming. А generic programming это одно из путей развития идеи метапрограммирования. Хотя два термина не равнозначны, но когда речь идет о c++ то это практически одно и тоже, т.к. generic programming реализуется посредством template metaprogramming.
В-третьих, сам James Gosling автор Java указывал что generics это "kind of like templates" (вроде как темплейты). Вообще, generics и пришли в мир Java сначала в виде диалекта Generic Java который реализовывал generic programming, а потом уже это стало легальной частью языка.
Как-то так.a553
19.05.2015 16:15-2У вас прям микс получился из спорных определений и логических противоречий %)
Про размещение в памяти. Вы размещаете объекты в памяти в рантайме, компилятор этим не занимается для вашей программы. Проблема в том, что в С++ вы фактически не имеете информации о размере типов в рантайме, поэтому компилятору приходится выдавать «подсказки» программе: выдели 16 байтов на стеке, положи по смещению 0 инт, по смещению 4 вот этот шорт, а по смещению 8 — вот этот лонг. Но вашей программе на самом деле глубоко наплевать, сколько там байтов что занимает, и где конкретно оно расположено. Требование одно: три переменные! И пожелание: пусть доступ к ним будет быстрым. И всё это можно реализовать в рантайме, удобно и эффективно. И C#, в общем-то, так и поступает.
Как пример, структура алгоритма может зависеть от свойств некоторого числа N. Конечно это не ряд фибоначи, это может быть что-то более сложное, вроде разложения на примитивные корни по модулю m.
Вы вычисляете сложные алгоритмы, зависящие от разложения чисел, используя компилятор? Я считаю, вам надо пересмотреть подход к проетированию вашей программы, и вынести этот алгоритм в отдельную библиотеку. И после этого уже можно заниматься инлайнингом результатов.
И это никак не связано с отсутствием рефлексии, даже если бы она была, это не помогло бы исключать ненужные ветви выполнения кода без условных переходов и vtable.
Нет, цель метапрограммирования — создавать программы которые создают программы. С таким успехом можно и javascript называть языком с метапрограммированием. Там тоже интерпретатор присматривается во время синтаксического анализа к коду, что бы для числовых массивов использовались оптимизированную реализацию. Но это не метапрограммирование, абсолютно.
Определение некорректное. Кроме того, вы хотите сказать, JS — язык без метапрограммирования?
Ну эта тема много раз поднималась на стековерфлоу, так что просто приведу ссылки:
Вопрос по ссылке: «можно ли в C#/Java выполнять код на этапе компиляции?» С ответами не поспоришь, нельзя. Однако именно в этих языках появился АОП, например.
дженерики это костыль который был привнесён в java что бы добавить немного метапрограммирования
Ну нет же. Дженерики в джаву были введены для упрощения статического анализа, а следовательно избежания многих популярных ошибок, а также избежание вездесущих кастов.
дженерики являются элементом обобщенного программирования т.н. generic programming. А generic programming это одно из путей развития идеи метапрограммирования.
Это разные понятия. Обобщенное программирование — это подход к написанию программ, а дженерики — это фича языка. Они зачастую используются вместе, но вы также можете выбрать что-то одно. Более того, вы же не считаете использование opaque pointer в С/С++ метапрограммированием, верно?
сам James Gosling автор Java указывал что generics это «kind of like templates»
Нет, он говорит, что реализация типового полиморфизма в джаве похожа на типовой полиморфизм шаблонов. В этом плане они действительно похожи.
Мне кажется, у вас лишь поверхостное знание того, что такое метапрограммирование в управляемых языках, и что из себя представляют дженерики. Будет время — изучите обязательно, очень интересно! Советую начать с обзоров АОП-фреймворков, например — вот где настоящее метапрограммирование!deniskreshikhin
19.05.2015 18:22+3Простите, отвечу немного не по порядку.
Мне кажется, у вас лишь поверхостное знание того, что такое метапрограммирование в управляемых языках, и что из себя представляют дженерики.
Мне кажется это опять «приписывание ярлыков», см. labeling theory
Нет, он говорит, что реализация типового полиморфизма в джаве похожа на типовой полиморфизм шаблонов. В этом плане они действительно похожи.
Именно! Да, конечно с точки зрения бюрократии Java это типовый полиморфизм шаблонов, т.к. в java нет template metaprogramming, но в c++ есть. Поэтому в c++ templates это не только полиморфизм, но инструмент метапрограммирования.
Который появился на 10 лет раньше чем в java.
Таким образом безосновательность вашей фразы должна уже быть очевидна:
В большинстве случаев, то, что есть в темплейтах, но не удобно сделать в дженериках, это костыли С++ ввиду отсутствия метаданных.
Да, в C++ отсутсвуют метаданные, но это является частью дизайна языка, т.к. несет огромные плюсы. Но при этом темплейты введены в язык абсолютно по другим причинам.
Вы вычисляете сложные алгоритмы, зависящие от разложения чисел, используя компилятор? Я считаю, вам надо пересмотреть подход к проетированию вашей программы, и вынести этот алгоритм в отдельную библиотеку.
Так нет же, алгоритм создается на основе заданных свойств. Если я вынесу все в отдельную библиотеку, то мне надо будет сделать еще и генератор c++-кода.
Но вашей программе на самом деле глубоко наплевать, сколько там байтов что занимает, и где конкретно оно расположено.
Абсолютно не все равно. Очень и очень часто требуется что бы байты лежали в каком-то исключительном порядке. Так происходит всегда когда необходимо использавать аппаратное ускорение OpenGL/OpenCL, аппаратные аудио/video кодеки и т.п.
Кроме этого с одной стороны требуется наличие унифицированного доступа к совершенно разным данным, с другой стороны требуется минимизировать использование виртуальных функций, наследования и т.п. вещей из-за оверхеда. Темплейты в таких местах успешно это все решают.
цель метапрограммирования — создавать программы которые создают программы.
Определение некорректное
Приведите корректное. Это между прочим определение David Abrahams'а (один из авторов стандарта C++, разработчик языка Apple Swift, автор книги про метапрограммирование, уважаемый человек одним словом): Metaprogramming is usually defined as the creation of programs which generate other programs.
Crazy_Owl
19.05.2015 16:31+1Ссылки на стековерфлоу доказывают не «отстутствие метапрограммирования», а скорее, то, что в C# и Java оно реализовано по-другому.
upd: отредактировал комментарий, потому что из родительского поста на время почему-то пропали ссылки на стековерфлоу, а потом появились обратно.deniskreshikhin
19.05.2015 16:44+1Безусловно, в Java и C# нет «того самого» метапрограммирования, что есть в C++.
Crazy_Owl
19.05.2015 16:52+1Но ведь у С++ нет «монополии» на метапрограммирование, не так ли?
deniskreshikhin
19.05.2015 17:03+2Конечно, но так дискуссия о словах a553
В большинстве случаев, то, что есть в темплейтах, но не удобно сделать в дженериках, это костыли С++ ввиду отсутствия метаданных.
Я лишь показываю, что метапрограммирование это отдельный подход. И в C++ этот подход был реализован в виде темплейтов, которые в свою очередь не сводятся исключительно к параметрическому полиморфизму и появились на 10 лет раньше чем дженерики в Java.
Т.е. это в любом случае не костыль, и метаданные тут не причем.
uvelichitel
16.05.2015 21:13Are we web yet?
alist
17.05.2015 21:47Берем Node.js, Go или что-то аналогичное. Обработку запросов делаем на них, а уже они пусть пробрасывают данные в Rust. Можно растовую часть скомпилировать как аддон или библиотеку, а можно общение между Node/Go и Rust сделать по bsd-соккетам или ZeroMQ, например.
Но вообще смысл HTTP запросы обрабатывать на языке с такой строгой типизацией мне кажется неудобным.uvelichitel
17.05.2015 22:131. Предложенная Вами архитектура не снимает вопроса — вы все requests на одном соккете предполагаете обслуживать, для обслуживания request инициировать системный поток или event-callback диспетчер?
2.HTTP запросы обрабатывать на языке с такой строгой типизацией мне кажется неудобным
Go statically typed.
zenden2k
16.05.2015 22:34-37Нет, серьезно, еще один язык программирования в 2015 году?
Какие задачи он позволяет решить эффективнее, чем существующие языки?
Говорите, на 5% эффективнее и безопаснее чем С++? Зато на С++ в 100500 раз больше библиотек и инструментов.
Судьба никому не нужного языка D никого ничему не научила?
Нет, я конечно понимаю, что на хабре сидят в основном вЭб-кодировщики, которые привыкли к выходу очередного кофи/тайп/wtf-script-a, который якобы исправляет недостататки изначально ущербного джаваскрипта, или каждый день новый никому не нужный css-говнопрепроцессор.
Но кто в здравом уме будет переписывать что-то на педеРаст? Или начинать новый проект. Кто будет переписывать библиотеки, писать биндинги к существующем? Я уже видел, как разрабатывают стандартную библиотеку языка D. Обкуренные студенты вобразили себя невесть что и пишут велосипеды, которые уже давно написаны и тщательно протестированы в других языках.
Друзья, давайте будем реалистами.kstep Автор
16.05.2015 22:50+18Ёлки-палки, чего ж вы все такие крутые сишники паритесь и, простите, на говно-то исходите? Я, конечно, нарываюсь на минуса в карму, но что ж вам так раст покоя не даёт? Ну не нравится он вам, не видите в нём смысла, но вас же никто не заставляет силком на него переходить! Если он вам так не нужен, что вы забыли в этом и аналогичных топиках? Вот вам этот языке не нужен и не нравится, а другим людям нужен и нравится. Ну так и пройдите себе мимо! Зачем и себе и другим нервы трепать? Вот нравится некоторым фигнёй с никому не нужными языками страдать, ну так а вас это как касается? Вас что, глубоко раздражает, что кто-то пишет не на Си++? Почему вы на питонщиков тех же так не наезжаете? Ведь си же круче!
oberon87
17.05.2015 01:00+6Это же борьба за место под солнцем. Если вы придете со своим Растом и отберете у него заказчиков, уставших от сегфолтов, он потеряет ресурсы и деньги. Все как у зверей. Просто этот конкретный хабраюзер выразил свои неосознанные опасения толсто. Это еще не так плохо, более опасны те юзеры, которые придут и будут разумно и более вежливо (не нарываясь на минусы) пояснять Вам, что Раст это просто продукт бессмысленной деятельности людей без разума, без умений и без понимания нужд индустрии.
JIghtuse
17.05.2015 08:29+6Не обращайте внимания. У этого товарища в профиле раньше было написано, что на php пишет. А сейчас он всеми силами стремится получить зелёную плашку.
RomanTsegelskyi
16.05.2015 23:21+2Откуда сколько желчи? Такое впечатление что вас засталяют программировать на ___ (тут вставьте свой ненависный язык). По вашему так у всех дожна быть одна модель машины, один столовый прибор и тому подобное. При чем тут вообще реализм? Rust это часть эволюции языков программирования как и D. Да, он может не выстрелить, может оказаться ненужным, но даже это не значит что Rust это провал. Для создания новых языков нужно проверять идеи и хотя бы в этом плане Rust это однозначно успех.
DmitryKoterov
17.05.2015 03:12А знает ли кто-нибудь, была ли в каком-то другом языке до Раста похожая система типов и видов указателей, как в Расте? Т.е. вот эта идея «сборщик мусора не нужен, потому что язык так построен, что сборщик мусора в нем вырождается в пустой код».
Потому что если нет, и это совершенно новое изобретение, то шансы Раста на успех ИМХО растут очень сильно (и они у него больше, чем у D, как бы все ни уважали Александреску).
Duduka
17.05.2015 05:07+1ru.wikipedia.org/wiki/Cyclone_(язык_программирования)
ru.wikipedia.org/wiki/BitC
phozzy
17.05.2015 08:38Я уже и не помню, когда в рассылке у BitC последнее сообщение пролетало.
kstep Автор
17.05.2015 09:15Ну битс, судя по описанию, закончился, не успев начаться, потому что главный автор на него просто забил. Хотя я не могу его за это судить, возвращаться к давно заброшенному, полузабытому и уже не интересному проекту — не сахар.
Вот циклон выглядел интересно, но судя по всему его убила излишняя академичность.
В любом случае ни один из них сравнивать с Растом до конца нельзя. У него открытая разработка, управляется он целой командой, а не одним BDFLом, который может потерять интерес к языку и забить, плюс достаточно большое и активное сообщество.
В общем посмотрим, что будет.
potan
18.05.2015 13:03+2Он безопаснее и удобнее C++, сохраняя realtime-гарантии и почти не завися от специфического runtime (по этому параметру он даже превосходит C++ приближаясь к чистым C).
Есть области, где еще нет 100500 библиотек.
Там же, где они есть, С++ не предоставляет стандартных средств для управления ими — а для rust есть cargo.
tgz
Это просто прекрасно! Дождались!
deniskreshikhin
Не обольщайтесь, сейчас просто невозможно написать полноценное приложение используя «стабильную» версию.
Очень много из стандартной библиотеки оказалось за пределами «стабильности».
Так что если интересен rust в плане попрограммировать — ставьте ночной билд.
tgz
Мне и на стабильной версии неплохо живется. Головняка как раз меньше, чем с бетами.