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

Swift Algorithms

swift.org

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Swift Algorithms

#51

Post by stephencanon »

zapnuk wrote: post #49

Looks great. But I wonder why there are platform requirements for what seems to me like pretty basic functions. In RandomSample.swift: // For log(_:) and exp(_:) #if canImport(Glibc) @_implementationOnly import Glibc #elseif canImport(Darwin) @_implementationOnly import Darwin #endif 1. Why aren't those 'basic' functions already implemented in swift, and part of a math package (or in numerics)? 2. Why release a packa…

They _are_ in Numerics (including Windows support). I think Nate is just trying to keep dependencies to a minimum, but feel free to raise an issue.

Re: Swift Algorithms

#52

Post by dep_b »

Cthulhu_ wrote: post #43
mikkelam wrote: post #41

I would love to go and use swift at my work (working in robotics). But swift just doesn't feel mature enough for barely anything outside of iOS/macOS. I had a great time using it for that purpose. The community outside of that ecosystem is barely there. I've picked rust instead, it feels like the exact opposite of the single large actor supporting swift, instead it's a huge community effort with lots of use cases alr…

Yeah, back when we first started using it there was a lot of interest in using it to create back-ends as well, but there just wasn't a lot of support for it. For one, it needed to be developed and compiled on a not-Mac environment to be viable, and that has just never been much of a thing. Might be better now, it does just use LLVM in the back-end and IntelliJ has a good editor for it, but still. I think C# had that…

Still Mono, Xamarin and Unity preceded that decision.

Re: Swift Algorithms

#53

Post by hntestacc »

zapnuk wrote: post #49

Looks great. But I wonder why there are platform requirements for what seems to me like pretty basic functions. In RandomSample.swift: // For log(_:) and exp(_:) #if canImport(Glibc) @_implementationOnly import Glibc #elseif canImport(Darwin) @_implementationOnly import Darwin #endif 1. Why aren't those 'basic' functions already implemented in swift, and part of a math package (or in numerics)? 2. Why release a packa…

test

Re: Swift Algorithms

#54

Post by madeofpalk »

austinl wrote: post #25
typon wrote: post #19

Is Swift worth learning if you're not going to be doing Apple development?

As an iOS engineer, I'm a bit biased, but I'd still say it's currently not practical to learn it if you're not doing Apple development. That said, I love the language, and it's a big part of what motivates me to continue being an iOS engineer (I'm not sure I'd still be at if we had kept on with Objective-C). I would love to see server-side Swift take off, but the ecosystem is still fairly new, so any large project wo…

I can't really see a reason to use Swift if you're not targeting Apple platforms.

I think between Nodejs, Python, Go, (and maybe Rust), I can't really see much of a compelling usecase for Swift on the server. Even if you're developing a server component for an iOS app, I don't think it really is all that common to share a core between the two.

Re: Swift Algorithms

#55

Post by Someone »

mikkelam wrote: post #41

I would love to go and use swift at my work (working in robotics). But swift just doesn't feel mature enough for barely anything outside of iOS/macOS. I had a great time using it for that purpose. The community outside of that ecosystem is barely there. I've picked rust instead, it feels like the exact opposite of the single large actor supporting swift, instead it's a huge community effort with lots of use cases alr…

“rust just got AVR support which I suppose swift could get pretty quickly with llvm as well”

In theory, yes, but in practice I don’t see Swift going there comfortably. Its more dynamic runtime (compared to C or rust) needs more metadata, eating memory, which is precious on AVR (384 kilobytes, max, reading https://en.wikipedia.org/wiki/AVR_microcontrollers)

Re: Swift Algorithms

#56

Post by zapnuk »

rudedogg wrote: post #17

This looks great. I'm looking forward to this and swift-numerics maturing. If you haven't seen it, check out the 2018 WWDC session "Embracing Algorithms" ( https://developer.apple.com/videos/play/wwdc2018/223/ ). It's worth watching, even if you don't work with Swift.

I second that. So far every talk by Dave Abrahams has been entertaining and insightful to me.

Re: Swift Algorithms

#57

Post by nicoburns »

dep_b wrote: post #52
Cthulhu_ wrote: post #43

Earlier quoted context omitted.

Yeah, back when we first started using it there was a lot of interest in using it to create back-ends as well, but there just wasn't a lot of support for it. For one, it needed to be developed and compiled on a not-Mac environment to be viable, and that has just never been much of a thing. Might be better now, it does just use LLVM in the back-end and IntelliJ has a good editor for it, but still. I think C# had that…

Still Mono, Xamarin and Unity preceded that decision.

True, but even now the C# library ecosystem is lacking compared to e.g. JVM/JavaScript/Python ecosystems. And that's definitely because it was historically closed source and mostly (but not entirely) single-platform.

Re: Swift Algorithms

#58

Post by hechang1997 »

mikkelam wrote: post #41

I would love to go and use swift at my work (working in robotics). But swift just doesn't feel mature enough for barely anything outside of iOS/macOS. I had a great time using it for that purpose. The community outside of that ecosystem is barely there. I've picked rust instead, it feels like the exact opposite of the single large actor supporting swift, instead it's a huge community effort with lots of use cases alr…

I saw posts on r/rust talking about making a rust-like language for non system programming. I think Swift fits exactly that purpose, only frustrated by Apple giving it Windows support a decade after it's creation.

Re: Swift Algorithms

#59

Post by pjmlp »

dep_b wrote: post #52
Cthulhu_ wrote: post #43

Earlier quoted context omitted.

Yeah, back when we first started using it there was a lot of interest in using it to create back-ends as well, but there just wasn't a lot of support for it. For one, it needed to be developed and compiled on a not-Mac environment to be viable, and that has just never been much of a thing. Might be better now, it does just use LLVM in the back-end and IntelliJ has a good editor for it, but still. I think C# had that…

Still Mono, Xamarin and Unity preceded that decision.

.NET CLR + BCL was originally released as BSD code, Rotor project, but no one cared about it.

.NET was also available in other platforms where Microsoft saw commercial value, via partner agreements.

http://www.jot.fm/issues/issue_2006_04/article4.pdf

https://www.sidiary.org/press-Diabetes_Symbian-968.asp

Re: Swift Algorithms

#60

Post by nicoburns »

hazz99 wrote: post #50
vips7L wrote: post #48

Earlier quoted context omitted.

I think there is some measure of value to not having to use a whole different language to generate go because it's incapable of making maintainable code without it. This is stockholm syndrome.

Part of Go’s tradeoff is managing that extra effort (or delay in waiting for the features to hit the main branch) in return for an extremely stable, simple language. You might find that to be a terrible idea, but others ostensibly think differently (Go is quite popular) Personally, I prefer more advanced type systems. But I understand Go can be a good choice in other situations.

> Go is quite popular

Well sure, but inheritance and enterprise-style Java were all the rage in the 90s, but they largely haven't stood the test of time. I rather suspect Go will be similar. It has some good ideas, and it's compiler toolchain is top-quality. But I'd be willing to bet that the languages we're using in 20 years time look a lot more like Rust/Swift/Kotlin and TypeScript/Julia than Go.

Post reply on HN