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

81–90 of 318 posts

Re: Swift is a more convenient Rust

#81

Post by benreesman »

bananapub wrote: post #76
zozbot234 wrote: post #67

Earlier quoted context omitted.

The whole point of Haskell as a programming language is to have lazy evaluation be the default. This comes with boxing data objects everywhere, which is the opposite of a focus on low-level performance. Haskell does support using strict, unboxed data but it's clunky and not the default. (Also, recent versions of Rust have now added support for "plug-in" laziness via the type constructors LazyCell and LazyLock .)

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'?

A dramatic over-simplification is that a lazy value referenced by some continuation/thunk is hard to stack allocate in-situ.

Now GHC does stack allocate, but it’s hard to count on without really aggressive hinting.

Re: Swift is a more convenient Rust

#83

Post by hardwaresofton »

Am I the only one that dislikes the dot syntax for variants?

Zig and Swift do it and I feel like it makes things harder to read, not easier.

`.variant` vs `Type::Variant`

IIRC the syntax is optional (you can include the type name) but it seems obvious that in any sufficiently long or complex code, not having the type name close would be annoying, especially if you didn’t have IDE like capabilities in your editor.

Re: Swift is a more convenient Rust

#84

Post by galangalalgol »

sgt wrote: post #58
pjmlp wrote: post #51

Earlier quoted context omitted.

Try to make Rust interop with C++, C and Objective-C as easy as Swift does it.

This is a big deal. In reality, most of the code that powers your systems (phones, tablets, any computers) is built using C and C++, regardless what OS you use.

Agreed, and rust-c interop is as good as any other I've used. The c++ interop was clunky but getting much better with crates like zngur. That is what was holding back its use on chrome for a while. Oddly its python interop is way better with pyo3 and maturin making it super easy.

Re: Swift is a more convenient Rust

#85

Post by mrtksn »

bhaney wrote: post #47
mrtksn wrote: post #31

Earlier quoted context omitted.

[flagged]

The modern tooling not being available for common hardware that's only a few years old is a problem with the tooling

It can be a bad value depending on what do you do with your tools but I wouldn't say that this is bad tooling.

The new tooling is amazing, its fast its snappy it runs the code you write for you mobile device directly on your tool. If that brings you value less that is less than 200$ a year, then it can be a bad deal but its not bad tooling.

Re: Swift is a more convenient Rust

#86

Post by neonsunset »

pjmlp wrote: post #45
neonsunset wrote: post #29

Earlier quoted context omitted.

You can get much smaller native binaries with .NET's NativeAOT nowadays: https://github.com/MichalStrehovsky/sizegame Funnily enough, I'm using C# to solve quite a similar type of tasks. It's a really pleasant experience.

Native AOT needs to get better tooling ergonomics though, the whole publish process is a bit convoluted versus toolchains that have AOT compilation as their default. Not counting having to learn about IL trimming, and the whole AOT compatible libraries.

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), with other static dependencies written in C/C++/Rust is not too different from other toolchains - you specify `DirectPInvoke` and `NativeLibrary` properties in .csproj, and they are linked into the final product as a part of the build process. You may need to forward linker arguments[0] for the imports referenced by those however, but this is expected regardless of .NET.

I think it's fair to criticize the additional compatibility effort required for high-level user libraries that rely on un-analyzable reflection, reflection emit or assembly loading, but none of these features usually have any relevance in the domain of systems programming.

When you write a project from scratch, you never have to think about whether it's native compilation or "JIT+CIL assemblies sandwich" executable, or anything else. It just works.

For example https://github.com/codr7/sharpl - the author was pretty much learning C# on the go and it needed exactly 0 changes besides adding `PublishAot` property to make it output a native executable.

[0]: https://github.com/U8String/U8String/blob/main/Examples/Inte...

Re: Swift is a more convenient Rust

#87

Post by zozbot234 »

benreesman wrote: post #75
zozbot234 wrote: post #67

Earlier quoted context omitted.

The whole point of Haskell as a programming language is to have lazy evaluation be the default. This comes with boxing data objects everywhere, which is the opposite of a focus on low-level performance. Haskell does support using strict, unboxed data but it's clunky and not the default. (Also, recent versions of Rust have now added support for "plug-in" laziness via the type constructors LazyCell and LazyLock .)

I’m aware of how boxing works in GHC, I learned it from Simon Marlowe. I don’t mean to be obtuse but I don’t see what that has to do with linear typing as a fucking weird mandatory default?

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/

Re: Swift is a more convenient Rust

#88

Post by valenterry »

SSLy wrote: post #79
nextaccountic wrote: post #64

Earlier quoted context omitted.

But Kotlin is like this too.

Indeed, and Scala (at least the version I've tried 10 years ago) tries to do both, somewhat poorly. shrug

Personally I found Scala's module/import system to be really really good. There are some annoying things with it, but they mostly come from JVM/Java compatibility.

Re: Swift is a more convenient Rust

#89

Post by smodo »

seanalltogether wrote: post #16

I keep trying to get into rust but I always hit a brick wall when looking at examples and the code looks so complicated. Examples like this straight from the rust website just make my eyes glaze over struct Task { future: Mutex >>, task_sender: SyncSender >, }

This may demonstrate the intricacy of the type system but isn’t a very intuitive example… I feel like the Rust Book does a good job of explaining the different types in std. For one thing it shows these types in their most idiomatic use cases. Rust is my first real low level language and I learned a lot by reading the book.

And by reading it I mean I actually read the thing front to back before touching a keyboard. Then I started to experiment with some simple code and after a couple of months I had some actually programs that I use often. Obviously I rewrote them after a year but hey ho, it’s all a learning experience.

Post reply on HN