Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift is a more convenient Rust

blog.namangoel.com

Post reply on HN
Print view View original

251–260 of 318 posts

Re: Swift is a more convenient Rust

#251

Post by iknowstuff »

nicce wrote: post #226
jb1991 wrote: post #177

> But when you need extra speed you can opt into an ownership system and “move” values to avoid copying. I've been using Swift a long time and don't quite get what this is referring to. Also: > Swift too gives you complete type-safety without a garbage collector. Type-safety and memory-safety are two entirely different things; this is an odd sentence.

> I've been using Swift a long time and don't quite get what this is referring to. Latest Swift release (June 11th) added ownership system.

Seems odd for an article which is comparing rust and Swift not to delve into the new Swift ownership system...

Re: Swift is a more convenient Rust

#252

Post by ahlCVA »

lukeh wrote: post #11

I don’t know Rust, but I’m loving Swift for systems programming. Most recent project was an 802.1Q SRP implementation and I couldn’t imagine going back to C. Higher up the stack, I’ve also used it with a custom runner to build the business logic for an embedded Flutter app. My only beef is that the binaries are quite large. I’m hoping the new Foundation will improve things, in the interim I’m trying to eliminate my F…

Fascinating that somebody is using Swift "in production" for that!

I work on small-ish embedded Linux systems and I've been looking for an alternative to C for a long time. Rust does not fit the bill, both because I don't enjoy the ergonomics of it (but I could get over that were it not for the other issues) and because the binaries are huge, so unless you go for a busybox-style multicall binary (and even then) you'll be wasting a lot of space. Both the standard size reduction techniques and splitting out things into shared objects (the ABI instability is not an issue on an embedded system which always gets compiled as a whole anyway) don't really move the needle compared to what you can achieve using plain C.

I've been meaning to give Swift a shot for applications like this. From what I've seen I had assumed that it would have less of a tendency to monomorphize everything (like Rust and C++ like to do when you use them idiomatically), leading to less binary size bloat.

You also mention binary size, but in relation to a library - is it that the absolute cost of including the library in the image is too high or is there a per-binary effect here as well?

Could you maybe share some of your experiences with Swift on embedded Linux in the context of that project? What is working well, what are the warts? What kind of distribution (like buildroot, Yocto, ...) are you using?

Sorry for the ton of questions, it's just something that has been on my bucket list for quite a while and it very exciting to hear that somebody is already doing this.

Re: Swift is a more convenient Rust

#253

Post by eska »

Ygg2 wrote: post #221
xolox wrote: post #197

Earlier quoted context omitted.

malloc/free are for heap based allocations. The grand parent explicitly mentioned he was referring to stack based allocations, which are kind of automatic (implicit).

Sure, however you still have to do them manually. That's what manual in manual memory management stands for. Stack based allocation are essentially registers, right?

  {
    int8_t x = 1;
  }
allocates a byte on the stack, binds it to a variable named x, sets it to 1, then deallocates it from the stack. There is no explicit allocation or deallocation.

As an optimization it can be put into a register instead of the stack, again without explicit allocation and deallocation (this is done by the compiler playing musical chairs with registers).

I would not consider this manual. Manual would instead be something like in embedded programming

  int8_t* y = (int8_t*)0xB4DC0FF3;
  *y = 1;
because one needs to keep track of used memory locations (do allocation management)

Re: Swift is a more convenient Rust

#254

Post by neonsunset »

consteval wrote: post #246
est31 wrote: post #240

Earlier quoted context omitted.

> Rust's memory management is automatic in that you can write entire Rust programs without once calling `free` manually. Personally I'd put the bar around not requiring people to distinguish different pointer types (owned vs shared). Languages like Java, JS, Python, Swift, Go, etc all have this "everything is a smart pointer" paradigm, (or at least the strong and widely used default). I'd say Rust is manually managed…

Most GC langs have these features too they're just not in your face. Technically C# has true value types like C++. Rust makes the distinction between stack and heap references, like C++. Other, more high-level languages don't - there's only one kind of reference, you can't take a reference to a stack object. Maybe you implement that by making all objects heap allocating (Java) or you just say they have to be copied e…

The assessment on C# does not match language spec at all.

Not only instance methods on C# structs are implicitly byref, you can easily pass structs by reference via ref, out and in keywords. On top of that, ref structs can hold `byref` pointers aka 'ref' keyword which can point to arbitrary memory, or have references to other structs/variables/anything.

There is also regular C syntax with &T and T* for unmanaged references/pointers. On top of that, .NET's compiler has gotten very good at struct optimizations and pretty much ensures they stay in registers all the time unless address-taken, including SIMD registers for Vector and Vector128/256/512 even their "deconstructed" form when specified width is not supported so they get handled as e.g. 256x2. There was a big jump in codegen quality in .NET 8 which can now sometimes trade blows with GCC and Clang around struct optimizations.

All these features are first-class and are heavily used by all kinds of performance-sensitive code.

Also, structs can implement interfaces and can be generic arguments that satisfy interface constraints, which works exactly like generics with trait bounds in Rust - you get a generic instantiation aka monomorphized function body, making the abstraction zero-cost.

Re: Swift is a more convenient Rust

#255

Post by thiht »

noobr wrote: post #223
Loic wrote: post #129

Earlier quoted context omitted.

In this context, ML is Meta Language: https://en.wikipedia.org/wiki/ML_(programming_language)

thanks, i'm bad at abbreviations and don't like when people just throw them like this without first using the whole term at least once

This is indeed an abbreviation, but it doesn’t convey meaning. At this point ML is just the name of the thing, it could not expand to anything and still convey the same meaning.

If you don’t know ML, knowing what it stands for won’t help you. It’s like JS, either you know what JS is or you don’t. It’s not about what it means, it’s about what it is.

Re: Swift is a more convenient Rust

#256

Post by farmeroy »

benreesman wrote: post #92
zozbot234 wrote: post #87

Earlier quoted context omitted.

I'm not sure what's supposed to be especially weird about linear typing (or rather, uniqueness typing which is what Rust ultimately relies on). If you want to see the use of such types in a language that's clearly even less "convenient" and more principled than Rust, you can look at Austral https://austral-lang.org/

I think I’m going to be a hard pass on a language more militant about BDSM type system level memory management than Rust.

Is their code linter called whippy?

Re: Swift is a more convenient Rust

#257

Post by tialaramex »

tcbrindle wrote: post #230
tialaramex wrote: post #216

Earlier quoted context omitted.

Scoped enums ("enum class") are a very small improvement on the previous enum, the main thing they deliver is that they don't pollute your namespace as badly thanks to the scoping. Their notional status as "strict types" means nothing in a language which doesn't really care anyway, that's why memory_order::relaxed In Rust if you write nonsense like that it doesn't compile, these aren't comparable things. In C++ they'…

> memory_order::relaxed No it isn't. https://godbolt.org/z/bz7EhMhMT

I knew I should have checked that in Godbolt before posting it. You're correct, the types don't coerce and so this actually doesn't work.

Re: Swift is a more convenient Rust

#258

Post by est31 »

consteval wrote: post #246
est31 wrote: post #240

Earlier quoted context omitted.

> Rust's memory management is automatic in that you can write entire Rust programs without once calling `free` manually. Personally I'd put the bar around not requiring people to distinguish different pointer types (owned vs shared). Languages like Java, JS, Python, Swift, Go, etc all have this "everything is a smart pointer" paradigm, (or at least the strong and widely used default). I'd say Rust is manually managed…

Most GC langs have these features too they're just not in your face. Technically C# has true value types like C++. Rust makes the distinction between stack and heap references, like C++. Other, more high-level languages don't - there's only one kind of reference, you can't take a reference to a stack object. Maybe you implement that by making all objects heap allocating (Java) or you just say they have to be copied e…

> Most GC langs have these features too they're just not in your face.

That's what I meant by "strong and widely used default". Defaults and syntactic sugar do matter and influence the type of code written.

Re: Swift is a more convenient Rust

#259

Post by Ygg2 »

arghwhat wrote: post #237
Ygg2 wrote: post #221

Earlier quoted context omitted.

Sure, however you still have to do them manually. That's what manual in manual memory management stands for. Stack based allocation are essentially registers, right?

The stack is fully automatic arbitrary memory and has nothing to do with registers. You can allocate as much as you want (including e.g. bytearrays), until you run into the allocated stack limit. That limit can be arbitrary, and some languages even dynamically scale the stack. That you also have access to manual memory on the heap doesn’t matter. You can also do manual memory management in Rust if you want, as one ha…

Ok. Then manual memory applies to just heap memory management.

It's not rocket science. If you are calling malloc/free to maintain your memory you're doing manual memory management.

> You can also do manual memory management in Rust

You can do Garbage Collection in C, it doesn't make it Garbage Collected language.

You're confusing default memory management with what's possible.

By your logic, Arena allocators can be used in many different languages, including GC ones like Java. So that means GC languages like Java are manually memory managed. Which is defeats the definition of it.

Re: Swift is a more convenient Rust

#260

Post by lostmsu »

The article is outright wrong at times (like the need for Box or special status of enums), and is missing 80% reason to use Rust: it helps to ensure correctness of multi threaded synchronization at compile time.

So no, Swift is not a "more convenient Rust". It is not Rust at all. It is more of a variant of C#/Java. And I haven't seen any indication that it is an improvement over either. The only reason to use Swift is having to deal with Apple.

Post reply on HN