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

151–160 of 274 posts

Re: Swift Static Linux SDK

#151

Post by icedchai »

j1elo wrote: post #107
icedchai wrote: post #92

Earlier quoted context omitted.

Were you using a virtualenv? Or were you pip installing into your distro / system python, like a true savage?

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.

Re: Swift Static Linux SDK

#153

Post by pzo »

dzonga wrote: post #91

Swift could've easily replaced python. but the language got complex and is now a baby C++.

I think it's too late which is sad since Swift is not a bad language even though I agree it got complex since the last 5 years.

Python is mostly used not because of its language features but for cross-platform ecosystem. This is hard and slow to build especially these days (comparing to 10 years ago) since there are many languages and winner takes all or most of the cake.

The only way is

1) to provide something really groundbreaking at the time (e.g. ruby on rails)

2) piggyback on other ecosystem by providing great interop (e.g. maybe mojo in the future)

3) slowly grind and hustle until something eventually catchup (e.g. maybe rust in the future)

The problem with apple is they are too much focused to wall garden you instead of build ecosystem. Their IBM partnership failed to make something like Rails or Spring Framework for backend. Tensorflow for Swift failed even though it was google project. They don't have cross platform support in their DNA. You don't even get Xcode on Windows or iPad - this is dealbreaker for many people.

I would bet more on kotlin (native) / java even though I'm iOS dev myself. Embedded is the exception that they still might win the game since the only competition there is pretty much: C, C++, Rust and sometimes python, js more as a glue.

Re: Swift Static Linux SDK

#154

Post by amszmidt »

kibwen wrote: post #124
palata wrote: post #97

Earlier quoted context omitted.

> It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. You still fundamentally need to rebuild (or at least relink) and re-distribute all the packages, whereas with shared libraries... well you just update that one package.

I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.

Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found.

You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated…

Compare to upgrading a single shared library.

Re: Swift Static Linux SDK

#155

Post by pzo »

petereddy wrote: post #66
righthand wrote: post #12

Earlier quoted context omitted.

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

There are definitely languages with better cross platform support. But far better languages ? I think Swift is a pretty good language and I like to know what you think is far better than it.

maybe not far better as a language but on the same league but with far better cross-platform ecosystem that would be kotlin (native) or java (this days). You have great ecosystem for e.g. backend (Spring Boot) and modern java is also looking better every year.

Re: Swift Static Linux SDK

#156

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #116

This website is sending gzip _and_ ignoring the client Accept-Encoding header. Specifiying "identity" has no effect. Ignoring the Accept-Encoding header is common but sending gzip compressed response body and _also_ ignoring the header, thereby making it impossible for the client to disable compression using Accept-Encoding: identity, is relatively rare. Another example that comes to mind is www.amazon.com. However i…

They have now fixed it after I submitted this comment. No longer sending gzip by default. Thanks for that. Someone tell Amazon they should do the same.

Re: Swift Static Linux SDK

#157

Post by kibwen »

amszmidt wrote: post #154
kibwen wrote: post #124

Earlier quoted context omitted.

I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.

Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found. You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated… Compare to upgrading a single shared library.

The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. In the meantime, as far as I'm concerned dynamic linking is itself a security failure, because if I run a binary I want to know exactly what code is being run, without having to worry about dynamic linking and loading nonsense inserting itself into my process.

Re: Swift Static Linux SDK

#158

Post by JackYoustra »

akdor1154 wrote: post #126
JackYoustra wrote: post #90

Swift tooling has some really! Sharp! Edges!!! If you need something quick and easier than rust or have some reason to want to take your swift code and run it elsewhere I guess this is good but I don't see why you'd use it besides that.

It does, but it's also a really, really nice language. I'm excited to see Apple work to file those edges down. (and i say this as someone who is a Golang and Linux fan and owns zero iThings)

Completely. The language philosophy is much easier than rust imo

Re: Swift Static Linux SDK

#159

Post by glhaynes »

dzonga wrote: post #91

Swift could've easily replaced python. but the language got complex and is now a baby C++.

"Swift is too complex now" has seemed to have achieved meme status of late but I don't see it.

For the average developer, writing modern Swift is generally not any more difficult than it was several years ago (much more often it's easier), it's just that the language can do a lot more now. But you only need to learn those new parts if you're using them. If you're not writing low-level or special-purpose code, you don't need to learn about more recently added things like move-only types, the embedded subset, varadic generics, or macros, etc, etc. And if you are writing things that require those features, you often couldn't have even considered Swift for that purpose before they were added.

Re: Swift Static Linux SDK

#160

Post by comex »

kibwen wrote: post #157
amszmidt wrote: post #154

Earlier quoted context omitted.

Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found. You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated… Compare to upgrading a single shared library.

The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. In the meantime, as far as I'm concerned dynamic linking is itself a security failure, because if I run a binary I want to know exactly what code is being run, without having to worry about dynamic linking and loading nonsense inserting itself into my process.

> The distro repositories are being continuously rebuilt, because packages are receiving continuous updates.

At large timescales, yes. But not at timescales relevant for rapid security updates.

Post reply on HN