Rust 1.7

new(1,Some(new(2,None,None)), Some(new(3,None,None)))

Эпичненько, впрочем это уже другая проблема Rust.

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

Arc<Box<>> для этого случая не пойдёт. Нужен Arc<Cell<>>, Arc не даёт изменять содержащиеся в нём значения, поэтому нужен Cell с interior mutability.

Эпичненько

Problems? http://is.gd/hfCsqu

К чему всё это? В свифт версии был конструктор с 1 аргументом, а у тебя отдельная функция с отсебятиной.

Блин, ну замените new на impl { fn new(key: i32) -> Box<Node> {...}}

Блин, ну замените new на impl { fn new(key: i32) -> Box<Node> {...}}

Как аналог не пойдет, в Swift есть опциональные параметры ^_^.

Как аналог не пойдет, в Swift есть опциональные параметры ^_^.

Какой ужас. Нужно написать None. Уже бегу на свифт, сейчас только лыжи смажу.

сейчас только лыжи смажу.

И не только лыжи.

Какой ужас. Нужно написать None. Уже бегу на свифт, сейчас только лыжи смажу.

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

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

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

Собственно, уже сейчас можно свой syntax extension написать. Но внутренности компилятора пока слишком нестабильные. Придётся переписывать под каждую версию раста.

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

struct Foo {
    a: i32,
    b: i32
}
impl Foo {
    fn new(a: i32, b: Option<i32>) -> Foo {
        Foo {
            a: a,
            b: b.unwrap_or_default(),
        }
    }
}

fn main() {
    let f1 = Foo::new(1, Some(2));
    let f2 = Foo::new(1, None);
}

Swift

Млять, сколько раз можно говорить, что Раст не конкурирует с вашими Штифтами и Гошечками? Никто вас, веб-макак, свои сайтики на Раст переводить не заставит, угомонитесь уже. У Раста - другая область применения и предполагаемая аудитория, не состоящая из «тупых пользователей».

Чтобы не усложнять компилятор и язык, надо полагать.

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

Собственно, уже сейчас можно свой syntax extension написать

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

Млять, сколько раз можно говорить, что Раст не конкурирует с вашими Штифтами и Гошечками? Никто вас, веб-макак, свои сайтики на Раст переводить не заставит, угомонитесь уже. У Раста - другая область применения и предполагаемая аудитория, не состоящая из «тупых пользователей».

Ну давай, расскажи чем Rust более системый чем Swift.

Всё делается явно, этим и доставляет.

Вот ты и обосрался, В Swift явно указывается имя параметра, а твое «Foo::new(1, Some(2))» абсолютно неявно и ни о чем не говорит. В том числе и не помешает поломать старый код изменением параметров или перепутать их порядок.

Ну давай, расскажи чем Rust более системый чем Swift.

Ручным управление памятью.

У Раста - другая область применения и предполагаемая аудитория, не состоящая из «тупых пользователей».

Ого, ещё никто хруст в продакшыне не видел, а хрусто-илитка уже нарисовалась.

Ручным управление памятью.

Особой разницы нет, в Rust у тебя нет GC и ты оперируешь данными на стеке, подсчетом ссылок и данными на куче через обертки, и в Swift у тебя нет GC и ты оперируешь данными на стеке, подсчетом ссылок и данными на куче через обертки.

Особой разницы нет

Разница есть. В Раст я сам решаю, размещать данные на стеке или в куче, а в Свифт, компилятор за меня решает. В раст я сам решаю, какие обёртки зля данных на куче использовать, а в Свифт - анально приделанный Arc. Кстати, как в Свифте имеют дело с циклическими ссылками?

абсолютно неявно и ни о чем не говорит.

В таких случаях будет:

impl {
fn new(a: i32) {}
fn with_b(a: i32, b: i32) {}
}

FIX

impl Foo {
    fn new(a: i32) -> Foo {}
    fn with_b(a: i32, b: i32) -> Foo {}
}

В Раст я сам решаю, размещать данные на стеке или в куче, а в Свифт, компилятор за меня решает.

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

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

В Swift точно так же есть всякие unsafe, на основе которых можно творить все что угодно.

Кстати, как в Свифте имеют дело с циклическими ссылками?

В коде - вручную, ну и если прогнать программу в Instruments, то оно найдет их и покажет диаграммку.

В таких случаях будет:
new
with_b

эскобар.jpeg

Но тут не смысла сравнивать с Rust - у него классов то нет.

Пусть лучше классов не будет, чем будущего. Свифт теперь каждый год по мажорной версии сбрасывают с отсутствием обратной совместимости - поставили хипстеров на рельсы.

Пусть лучше классов не будет, чем будущего.

Гарантом будущего Swift является Apple.

Свифт теперь каждый год по мажорной версии сбрасывают с отсутствием обратной совместимости

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

А можно аналог этого?

struct Tree<'a, T: 'a> {
    value: T,
    left: Option<&'a mut Tree<'a, T>>,
    right: Option<&'a mut Tree<'a, T>>,
}

Гарантом будущего Swift является Apple.

Представляем вашему вниманию Swift 9, в этом выпуске мы улучшили.. изменили.. Все нововведения вы можете опробовать прямо сейчас, загрузив Xcode 11.3.

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

На то и версия его была 0.x.x. Сейчас стабильность.

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

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

В Swift точно так же есть всякие unsafe

То есть, если я просто захочу вручную порулить выделением/освобождением памяти, мне придётся на каждый чих плодить unsafe? Даже в D обошлись простым @nogc.

В коде - вручную

Через unsafe?

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

Как-то так:

class Node<T> { 
    var key: T
    var left: Node? 
    var right: Node?
    
    init(value: T) {
        key = value
    }
}

Можно указать <T> для типа left и right, но у меня swift и так ругается, если пытаться всунуть ноду с другим типом, надо будет почитать гарантируется ли это.

Представляем вашему вниманию Swift 9, в этом выпуске мы улучшили.. изменили.. Все нововведения вы можете опробовать прямо сейчас, загрузив Xcode 11.3.
На то и версия его была 0.x.x. Сейчас стабильность.

У вас фетишизм относительно версий? Вон systemd вообще 229 вроде последний, и ничего, все довольны.

https://refactoring.guru/ru/catalog

Там разве наоборот не описывает зачем может быть нужен рефакторинг?

У Раста - другая область применения и предполагаемая аудитория, не состоящая из «тупых пользователей».

ага, оно и видно. особенно по red75prim. очень не «тупые пользователи», лол.

class Node<T> { 
    var key: T
    var left: Node? 
    var right: Node?
    
    init(value: T) {
        key = value
    }
}

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

У вас фетишизм относительно версий? Вон systemd вообще 229 вроде последний, и ничего, все довольны.

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

ЕМНИП, есть известные способы спровоцировать утечку

Ага, самый простой - std::mem::forget. Пользуясь случаем, поною - эта функция ещё и не unsafe! Логика понятна - в безопасном коде можно устроить циклические ссылки и точно так же допустить утечку, но она мне категорически не нравится. Было бы не лишним напомнить, что эту функцию надо применять аккуратно и сделать её unsafe.

Даже в D обошлись простым @nogc.

Пардон, GC.disable(), @nogc означает только, что память не выделяется.

Через unsafe?

Кстати, кто знает, в расте можно циклические ссылки только через unsafe?

Пруф.

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_...

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

После отработки оптимизаций в компиляторе никаких гарантий ни у кого ни на что нет. Даже в более низкоуровневом С. Так что твое требование не имеет смысла. Вот тебе код на Swift с массивами:

http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot

Работает быстрее чем код на Rust, памяти есть меньше. Это лучше чем «гарантии» или хуже?

То есть, если я просто захочу вручную порулить выделением/освобождением памяти, мне придётся на каждый чих плодить unsafe?

А в Rust типа не так. Посмотри стандартную библиотеку - там этих unsafe вагон и тележка. Ну и насчет «на каждый чих» - Rust это ли не тот язык, где нельзя безопасно написать двусвязный список? Не?

Даже в D обошлись простым @nogc.

А в Rust, повторюсь, нет классов, потому и разговор ни о чем.

Через unsafe?

Через weak.

Сравнение от блондинки:

• Swift - быстро, стремительно.. падать, судя по иконке.
• Rust - ржаветь.. на иконке буква R в шестеренке, механизм как бы. Получается, ржаведь - работать на векА. R похоже на Я - индивидуальность, при этом в шестеренке 5 круглешочков, символизирующих сообщество, взаимопомощь, заинтересованность.

Как назовешь корабль...

Дык в это-то и прикол, что если пришлось рефакторить, то в коде с вероятностью 95% есть:

Запахи кода

Rust - ржаветь

На самом деле Rust назван в честь пукциниевых грибов. Ещё смешнее, правда?

Насчет гарантий, кстати. Вот код на С++:

#include <cstdio>
#include <vector>

int main()
{
    std::vector<int> a { 1, 2, 3 };
    
    printf( "%d\n", a.size() );
}

Можно ли сказать что тут будет выделение памяти? Это же не массив, наверное, да. Но clang выдал это:

	.text
	.file	"./test.cpp"
	.globl	main
	.align	16, 0x90
	.type	main,@function
main:                                   # @main
	.cfi_startproc
# BB#0:                                 # %.lr.ph.i.i.i
	pushq	%rax
.Ltmp0:
	.cfi_def_cfa_offset 16
	movl	$.L.str, %edi
	movl	$3, %esi
	xorl	%eax, %eax
	callq	printf
	xorl	%eax, %eax
	popq	%rcx
	retq
.Lfunc_end0:
	.size	main, .Lfunc_end0-main
	.cfi_endproc

	.type	.L.str,@object          # @.str
	.section	.rodata.str1.1,"aMS",@progbits,1
.L.str:
	.asciz	"%d\n"
	.size	.L.str, 4


	.ident	"clang version 3.8.0-+rc2-1~exp1ubuntu2 (tags/RELEASE_380/rc2)"
	.section	".note.GNU-stack","",@progbits

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

Это лучше чем «гарантии» или хуже?

За производительность я не говорил. «Гарантии» - это про возможность работать без рантайма, который будет заботливо тебе выделять/освобождать память в куче. Олсо, ты специально тест подбирал? А то я на том сайте тебе могу найти тест, где PHP всех порвал.

написать двусвязный список

Для каждого проекта пишешь свою реализацию?

А в Rust, повторюсь, нет классов, потому и разговор ни о чем.

Разговор об управлении памятью. Зачем ты приплёл классы?

Можно ли сказать что тут будет выделение памяти? Это же не массив, наверное, да. Но clang выдал это:

Каков пример (оторванный от жизни), такой и результат.

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

Если должен, но не выделяет, ничего страшного. Главное, чтоб не выделял, когда не просят. А целом - наш диалог цирк какой-то. «Спешите видеть, вебмакака прибежала советовать язык для системного программирования!».

Короче, раст не нужен, свифт не нужен - все дружно лижем сишку, ибо FFI.

Ну так -O3 поди, или -O2 хотя бы, что ты хочешь.

А то я на том сайте тебе могу найти тест, где PHP всех порвал.

Давай.

Для каждого проекта пишешь свою реализацию?

Нет, но это и не я говорил, что в Swift на каждый чих нужен unsafe.

Разговор об управлении памятью. Зачем ты приплёл классы?

Затем, что в Swift разная модель для управления памятью для классов и других типов. И, все что есть в Rust, так же прекрасно размещается на стеке. Кроме классов, которые разместятся как компилятор захочет. И кивать в их сторону нет смысла, так как в Rust их просто нет.

Давай.

На http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna

А целом - наш диалог цирк какой-то. «Спешите видеть, вебмакака прибежала советовать язык для системного программирования!».

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