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

131–140 of 318 posts

Re: Swift is a more convenient Rust

#131

Post by benreesman »

bananapub wrote: post #117
benreesman wrote: post #81

Earlier quoted context omitted.

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.

ah, right, laziness can cause the control flow to become extremely complicated - makes sense, thanks!

Also true! And in very real sense literally what I meant.

But not so much in the conditional branch sense of the phrase “control flow”.

More like, I’ve got a bunch of references and one of them is a reference to a function I might evaluate, damn, I need that reference and the transitive closure of everything it knows about, all of which are probably on the heap.

Re: Swift is a more convenient Rust

#132

Post by pjmlp »

neonsunset wrote: post #86
pjmlp wrote: post #45

Earlier quoted context omitted.

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), wit…

As you are well aware, I know .NET since it was "partners only beta software", so dealing with "dotnet publish" plus csproj configuration, is still way easier than something like NGEN.

However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary".

Which is the experience I think the team should strive on as goal, especially for newcomers.

More so when comparing IDE experience of something like Delphi or Swift to keep it in context (press build), versus Visual Studio (besides csproj, create publish properties file, followed by a solution publish, which is hardly documented still).

Re: Swift is a more convenient Rust

#133

Post by lukeh »

BiteCode_dev wrote: post #18

Swift won't be able to compete with rust until it has a great scripting story. Rust is currently the defactor choice if you want to make something with js/python bindings, of id you want to speed up a dynamic bottleneck because it makes it super easy. Swift doesn't even have a good ffi.

Swift can import C (and C++) modules directly, and it's fairly straightforward to wrap existing C APIs with callbacks to be usable from structured concurrency. Here's an example I just worked on. [1]

[1] https://github.com/PADL/NetLinkSwift

Re: Swift is a more convenient Rust

#134

Post by pjmlp »

DasIch wrote: post #96
pjmlp wrote: post #34

What Rust did great was bringing affine type systems into mainstream culture. However outside very specific use cases, where no kind of automatic resource management is allowed, no matter what, like in high integrity computing, or critical kernel code, approaches that mix and match both solutions are much more ergonomic. Swift isn't the only one going down this route, we see it as well in D, Chapel, Linear Haskell, O…

Rust is more popular than all of these languages except swift combined. So it seems empirically that ergonomics and expressiveness don't matter that much or these languages don't manage to do significantly better than rust.

It appears more popular, which isn't the same thing.

Re: Swift is a more convenient Rust

#135

Post by nelup20 »

x3ro wrote: post #21
arghwhat wrote: post #14

Earlier quoted context omitted.

Not to praise Swift, but Swift and Xcode are unrelated projects. Saying that Swift is inconvenient because of Xcode issues is like saying C++/C# is inconvenient because of Visual Studio. You can install Swift on Linux if you want and code away, just like with Rust - but as it hasn't really caught on for anything other than building apps for the Apple ecosystem, it's not a particularly normal thing to do.

The defacto standard matters. The vast majority of Swift programmers will be using Xcode, and I definitely immediately think of the pains I've had with Xcode when I hear Swift. For example, I don't know of any other good IDE environment for Swift, though maybe there is one. You could also argue that e.g. Rust is not cargo, but almost every Rust programmer will be using cargo. Sure I could use something else, but why…

Yep, I've only started using Swift a couple of months ago, but Xcode just isn't pleasant to use imo (though I'm probably spoiled by Jetbrains' IDEs), and the Swift extension for VS Code is clunky.

I'm still really sad Jetbrains decided to sunset AppCode :(

So the quality of tooling/IDEs is definitely a factor, I just don't see myself using Swift outside of the Apple ecosystem when there are so many other alternatives.

Re: Swift is a more convenient Rust

#136

Post by lolinder »

est31 wrote: post #27
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…

> Rust is the first language to bring non-GC automatic memory management to the mainstream. It won't be the last and it might well be the worst. Other languages in this space include Swift 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…

> 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 spent time troubleshooting a memory leak in JavaScript in the past month, caused by someone keeping a pointer around longer than necessary.

Rust's memory management is automatic in that you can write entire Rust programs without once calling `free` manually. I'm not sure what definition of automatic you're working off of, but if it excludes JavaScript it doesn't seem especially useful.

Re: Swift is a more convenient Rust

#137

Post by foldr »

sorentwo wrote: post #126
swiftcoder wrote: post #22

Earlier quoted context omitted.

I'll grant you that is probably too complicated an example to appear early in the docs, but how often are you actually building multithreaded job dispatch systems from scratch (which appears to be what this example is doing), and how simple would it be in other languages?

Transparently parallel, lightweight tasks are part of the language in Elixir. Fully multithreaded and able to utilize all cores out of the box.

Yes, but the Rust code is the kind of thing you'd write if you wanted to build that kind of thing yourself. I do think normal Rust can get too typey, but this is probably not the best example of that.

Re: Swift is a more convenient Rust

#138

Post by lolinder »

tgv wrote: post #80
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…

Rust is not really an ML language, is it? &mut is a very noticeable difference. Calling Rust, Scala, Swift and Kotlin ML seems to be taking it too far. Scala and Kotlin even have all the traditional OOP features. You might just as well put C++ in the ML list.

If &mut makes Rust not in the ML family then none of the languages they list are in the Smalltalk family either—there's no concept of an image, everything is in files!

It's pretty clear that we're talking about very broad families, which is okay—Rust has more in common with ML than it does with Smalltalk or ALGOL (though the ALGOL heritage is definitely present).

Re: Swift is a more convenient Rust

#139

Post by afavour »

lukeh wrote: post #130
afavour wrote: post #111

As someone that’s recently been working on integrating Rust into an iOS Swift app I do agree with a lot of this. I love Rust but the more I’ve used Swift the more I find myself wishing I was just using Swift all the time. That said , the difference between the two has a lot less to do with the language itself than the world surrounding it. You can use Swift cross platform but it’s very obvious that Apple platforms ar…

Well, that article also presents a pure Swift (non-Foundation) solution, WeakRef.

Yes, I mentioned that. There’s probably a better example but this is off the top of my head as something I experienced myself. My point is that the blog post suggests the Swift native version then discusses NSMapTable without ever calling out the fact that you can’t use the latter cross-platform. I find that endemic in the Swift community, there’s a base assumption you’re coding on an Apple platform (and often specifically on iOS!), it adds an additional barrier to getting things done.

Re: Swift is a more convenient Rust

#140

Post by neonsunset »

pjmlp wrote: post #132
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…

As you are well aware, I know .NET since it was "partners only beta software", so dealing with "dotnet publish" plus csproj configuration, is still way easier than something like NGEN. However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary". Which is the experience I think the team should strive on as goal, especially for newcomers. More so when comparing IDE experience of somethi…

> However this is somehow cumbersome versus doing a plain "aot-lang-compiler source -o binary".

But...it works in this exact way?

  dotnet publish -o folder -p:PublishAot=true
Does not need -p argument either, as noted in the previous comment, if `PublishAot` is specified in .csproj, like with any AOT template (e.g. dotnet new console --aot or dotnet new webapiaot).

On Visual Studio, I have started to recommend to newcomers to avoid its publishing UI which is convoluted and is easy to get side-tracked with. CLI offers much cleaner UX. Not that it matters outside of Windows. But you don't need to create publish file either, just tick the boxes you care about in the modal window.

Edit: you can't be serious, no one in their sane mind would consider a single extra keyword to get the final product once you're done writing code a learning curve too steep, unless you're in a bad mood and want to make a bad faith argument. Consider what you make the comparison against - C and C++ with their CMake, Ninja, or even raw MSBuild, Swift is barely better too. Rust with Cargo is about the same amount of effort as .NET CLI. Cmon, Pjmlp.

Post reply on HN