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

221–230 of 318 posts

Re: Swift is a more convenient Rust

#221

Post by Ygg2 »

xolox wrote: post #197
Ygg2 wrote: post #192

Earlier quoted context omitted.

> non-GC *automatic memory* management to the mainstream would be either Forth or C Emphasis mine. It's not C. You do manual memory management there. You have to call malloc/free. Didn't use Forth, so I can't say anything about it.

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?

Re: Swift is a more convenient Rust

#222

Post by tialaramex »

pessimizer wrote: post #207
lolinder wrote: post #136

Earlier quoted context omitted.

> Rust's memory management is not automatic, you have to explicitly manage memory. It's just made extremely easy for you by the language thanks to stuff like RAII, and there is checks that prevent memory safety violations like double free. But those checks won't prevent leaks, although the many lints do make it harder to forget about a value. By this logic no language on earth has automatic memory management. I've sp…

> you can write entire Rust programs without once calling `free` manually. If you mean "drop," it's just syntactic sugar for calling a trait that manually deallocates the memory and that you're free to reimplement. It feels like people are equating "manual memory management" with "onerous memory management." People are usually going to want to do the boring thing with memory, and everything in the standard library by…

You can't call Drop::drop for type T at all. Try it if you don't believe me.

It would be unacceptable to allow this because Drop::drop says it only takes a mutable reference &mut T (and indeed it does) but now the thing is destroyed, so, that wasn't just a mutable reference at all!

You can call core::mem::drop but well, look at it, here's the code:

pub fn drop(_x: T) {}

Like, duh, we give it a T and then it doesn't give anything, the T is gone. That's not magic library code by the way, if we make our own:

pub fn vanish(_x: T) {}

Now we can call our vanish function and the same happens.

So yeah, automatic memory management.

Re: Swift is a more convenient Rust

#223

Post by noobr »

Loic wrote: post #129
noelwelsh wrote: post #13

Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks: 1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds. 2. Rust is the fi…

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

Re: Swift is a more convenient Rust

#224

Post by neonsunset »

Measter wrote: post #209
neonsunset wrote: post #86

Earlier quoted context omitted.

What kind of issues did you have with the build process? (as in, if you had a specific case, it might be worth submitting an issue or updating documentation) It's a very straightforward process - you pass a single flag, maybe specify optimization preference and instruction set target, and it gives you the binary upon 'dotnet publish'ing the project. The process of static linking (if you care about this scenario), wit…

How are build times for AOT these days? Last time I tried it (~2019) it was slower than Rust at building the same project.

If you refer to R2R, then it's more like pre-JIT - it embeds pre-JITed code into the executable that still very much uses JIT. It will also re-JIT R2Rd code if it's deemed hot enough and in need for further optimization.

This is an older mechanism that works differently to NativeAOT, it's also used by host-installed runtime to improve startup latency, and you can do your own R2R, either full or granular, to further improve this: https://learn.microsoft.com/en-us/dotnet/core/deploying/read... It can slow down the build quite a bit from what I've seen.

NativeAOT is different - when you use it, ILLink (which previously was the Mono Linker and now has evolved) trims all unreachable and links together all of the remaining CIL bytecode and metadata from the CIL assemblies that the application/library consists of. After that, ILC (IL AOT Compiler) compiles everything (and performs AOT-specific optimizations) into a single static bundle emitted as COFF or PE (or Mach-O?) file containing machine code. Then the toolchain invokes a host-provided linker which produces the final native executable or library, much like it happens with C, C++ or Rust. It even has the OS-specific symbol format, so you can feed it to the same tools that work with native code.

Technically speaking, .NET's compiler still retains the name "RyuJIT", but in practice it's not JIT-specific and ILC drives the same back-end as JIT compilation at runtime, but with different optimizations and options.

This is a new feature that was introduced in .NET 7, and has substantially improved further in 8 and upcoming 9. Completely different output aside, NAOT builds take less time than the ones that have R2R from my experience.

Your mileage may vary depending on how big the application is, how complex linking it requires and how much the native code to compile there is.

The main difference with Rust is that compilation time whether it's good or bad has much less relevance because for development you can use JIT (both debug and release, i.e. plain 'dotnet run') or even hot-reload which can recompile actively running code without restarting the application with 'dotnet watch' which works surprisingly well.

Re: Swift is a more convenient Rust

#225

Post by hyperbrainer »

noelwelsh wrote: post #13

Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks: 1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds. 2. Rust is the fi…

About the time travel to past aspect, I wonder if we will have an age of lisp now? I know Lisp is very popular in some niches(zB Emacs), but I really want to see innovations in syntax from the current standard of too many brackets. (M-expressions?)

Re: Swift is a more convenient Rust

#226

Post by nicce »

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.

Re: Swift is a more convenient Rust

#227

Post by GrantMoyer »

hardwaresofton wrote: post #200
robjwells wrote: post #152

Earlier quoted context omitted.

Fortunately in Rust you can have it both ways, as in `Type::Variant` most of the time and `use Type::Variant; … Variant …` in cases where the type name just causes noise. Example in the playground: https://play.rust-lang.org/?version=stable&mode=debug&editio...

I’ve never done this but this is a great point. I think I’d avoid doing this though because variants often have really short, reusable/general names (leaning into the overall type name being close)

You can put the use statement in the function with the match, or even limit the scope further:

  {
    use MyEnum::*;
    match my_enum {…}
  }

Re: Swift is a more convenient Rust

#228

Post by pjmlp »

neonsunset wrote: post #224
Measter wrote: post #209

Earlier quoted context omitted.

How are build times for AOT these days? Last time I tried it (~2019) it was slower than Rust at building the same project.

If you refer to R2R, then it's more like pre-JIT - it embeds pre-JITed code into the executable that still very much uses JIT. It will also re-JIT R2Rd code if it's deemed hot enough and in need for further optimization. This is an older mechanism that works differently to NativeAOT, it's also used by host-installed runtime to improve startup latency, and you can do your own R2R, either full or granular, to further i…

The last point is exactly the value of having compiler toolchains with JIT/AOT in the box, as standard toolchain, which only a few are around.

We get to enjoy both worlds, and picking the best deployment options as per scenario.

Rust development experience would be much better if they adopted a similar approach, which by the way, is common on other ML inspired languages.

Re: Swift is a more convenient Rust

#229

Post by benreesman »

throwaway17_17 wrote: post #205
bananapub wrote: post #76

Earlier quoted context omitted.

perhaps a dumb question, but why does laziness imply boxing? or does 'boxing' in haskell mean something other than 'embed a simple bit of data in a fancy thing on the heap'?

I seem to be missing the implication as well. I am under the impression that Haskell relies on boxed values primarily due to its parametric polymorphism. There is a Simon Peyton Jones talk somewhere discussing the acrobatic GHC requires for the type theory to deal with unboxed types and their implicit requirement for an alternative Kind at the type level. The laziness as a default just makes boxing closure values a s…

On everything from the JVM to GHC to v8 there is a critical distinction between the semantics of a boxed type and the practical outcome on the gear. Every managed language runtime done by pros (and those all are, I should have said the CLR too) will quietly unbox in all the easy cases and some of the hard ones.

Parametric polymorphism is kind of orthogonal to that. It’s related I guess. It can involve some kind of runtime dispatch, but usually that gets JITed or inlined or whatever unless you really insult the compiler.

And even full frontal invokedynamic it’s still like, is it in the BTB and the I-cache? Ok well we’re still doing business.

Re: Swift is a more convenient Rust

#230

Post by tcbrindle »

tialaramex wrote: post #216
secondcoming wrote: post #128

Earlier quoted context omitted.

C++'s scoped enums are strict types.

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
Post reply on HN