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

Swift Static Linux SDK

swift.org

Post reply on HN
Print view View original

171–180 of 274 posts

Re: Swift Static Linux SDK

#171

Post by manmal »

mdhb wrote: post #84
manmal wrote: post #75

Earlier quoted context omitted.

Isn’t “data-race free” in Dart achieved by just not really sharing mutable memory between isolates? Probably because the web version needs to map isolates to web workers, right?

For now but this is in the pipeline too. https://github.com/dart-lang/language/blob/main/working/333%...

Great writeup, and I love that the authors looked at a lot of other languages. The solution section on how to prevent races is a bit light still - I‘m curious how they will solve this.

I think there will need to be exceptions to a strict race-free model eto not take away from dart‘s current capabilities, and without forcing people into something like a borrow checker. Swift has `@unchecked Sendable` which lets you tell the compiler "I promise I'll take care myself to keep everything in there race-free".

What I‘ve been missing in Swift are tools that let me add safety _within_ such @unchecked Sendables. There's the Swift Atomics lib: https://www.swift.org/blog/swift-atomics/, but its quite limited in its capabilities. So for now, I find myself reaching for tools provided by the community, like pointfree's LockIsolated: https://github.com/pointfreeco/swift-concurrency-extras/blob....

Re: Swift Static Linux SDK

#172

Post by manmal »

Sytten wrote: post #82
manmal wrote: post #57

Earlier quoted context omitted.

The concurrency story is quite good now with Swift 6, and it’s arguably easier to handle than the borrow checker, but still very safe.

The way I view it as a Rust experienced programmer: Its kinda like if everything in your program was Arc and we didnt have the mess that are the async executors. But I might be wrong. Love rust but god that sometimes I curse the choices that were made and how slow it evolves.

I don't have a lot of experience with Rust, but that sounds about right.

Re: Swift Static Linux SDK

#173

Post by frankjr »

NekkoDroid wrote: post #108
frankjr wrote: post #26

Earlier quoted context omitted.

Fedora and Debian do this too. That's why it sometimes takes longer for a project to be packaged - you literally have to recursively package all of the dependencies first.

> Fedora and Debian do this too. IIRC Arch does as well (or at least tries to).

Arch does for quite a few ecosystems (Python, Ruby, Haskell, ...) but currently not for Rust.

Re: Swift Static Linux SDK

#174

Post by Redoubts »

potatolicious wrote: post #101
OKThatWillDo wrote: post #88

Earlier quoted context omitted.

Thanks. What is a "protocol server?"

Not a super-expert but I've used Vapor on some personal projects. Do you have a link to the mention for "protocol server"? I'm not familiar with the concept but might be able to help.

I'm guessing they clicked onto the Built with SwiftNIO link and saw this at https://github.com/apple/swift-nio.

Re: Swift Static Linux SDK

#176

Post by j1elo »

icedchai wrote: post #151
j1elo wrote: post #107

Earlier quoted context omitted.

I just knew the basics. So I was just following commands from stack overflow or similar. Silly me, thinking that it would work logically like other languages do! Later I ended up learning about all that stuff with venvs and whatnot, not to mention it's not even a unified solution but there are multiple alternatives, adding to the confusion... All this, no doubt, is a consequence of how terrible the Python packaging s…

You are right. It's not a good experience for new developers, especially given how long Python has been around.

They are so close, though! I think one lesson Python took is that it's better, even mandatory, to use venv and install stuff in isolated containment.

This is exactly what Node/NPM does: "npm instal" creates a new dir, "./node_modules" and installs stuff there, and next "npm" commands will transparently refer to that subdir. This is, in effect, the same thing as a Python's venv! to the point that in my scripts I always name them "python_modules", to give other unfamiliar devs a clue of what it is.

If "pip install" just did this transparently, without introducing the whole concept of venvs to the user, it would be a huge step forward. I cannot imagine how it would suck if NPM didn't make its node_module dir, and instead it forced you to first learn all the idiosyncrasies of module isolation.

Re: Swift Static Linux SDK

#177

Post by wg0 »

glhaynes wrote: post #162
wg0 wrote: post #133

Earlier quoted context omitted.

> IMO Swift 6 is a better Go and than Go, and a better Rust for app-dev type stuff, which seems to be what people want to use Rust for. This is a great assessment. There are some shortcomings in go that I wish weren't and I'm kind surprised that people having decades of language design experience under their belt ended up designing go. I'm looking for a way to generate server stubs from OpenAPI specs. If that, I'm al…

I'm looking for a way to generate server stubs from OpenAPI specs I don't have experience with OpenAPI, but is this what you're looking for? https://www.swift.org/blog/introducing-swift-openapi-generat...

You're right. This actually is first class Apple[0] and can't get any better than that whereas with Go, I am stuck with so many third party packages. They work well but kinda... not so elegant. Decent enough given what the language can offer.

[0] https://github.com/apple/swift-openapi-generator

Re: Swift Static Linux SDK

#178

Post by School-Cotton »

LtWorf wrote: post #166
kibwen wrote: post #127

Earlier quoted context omitted.

Rust supports dynamic linking, it's just not the default, so you need to configure a given crate to use it at build time.

Rust supports compiling each crate as a separate .so and then linking all of them? That's not at all how debian packages written in rust are linked. So the person I replied to is incorrect. I suspect you're incorrect as well and what you claim doesn't exist at all, but you're claiming a different thing.

> Rust supports compiling each crate as a separate .so and then linking all of them?

Yes, by passing crate-type=dylib to the compiler.

Re: Swift Static Linux SDK

#179

Post by boffinAudio »

josephg wrote: post #43
righthand wrote: post #12

Earlier quoted context omitted.

Not really no, there are far better languages with better cross platform support.

Which languages do you think are both better and have better cross platform support?

Lua, I would say. Far easier to get it everywhere, and a very nice language, also.

Re: Swift Static Linux SDK

#180

Post by [deleted] »

akira2501 wrote: post #47
palata wrote: post #27

Earlier quoted context omitted.

As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.

You're not forced to with Go. CGO exists and requires dynamic linking.

[deleted]
Post reply on HN