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

61–70 of 80 posts

Re: Swift Algorithms

#61

Post by pjmlp »

Someone wrote: post #55
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 )

Just like you don't do ANSI C there, so a similar constrained version might be possible, not much different from Pascal.

https://www.mikroe.com/mikropascal-avr

Re: Swift Algorithms

#62

Post by the_dripper »

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'm watching the talk now, the way the speaker describes the things he does seems to me like hes making fun of the Silicon Valley type lifestyle. I think the talk is really great and funny, thank you for sharing !

Re: Swift Algorithms

#63

Post by pjmlp »

xmprt wrote: post #33
bee_rider wrote: post #14

Earlier quoted context omitted.

Googling about this (I assumed the actual 'solution' would be a to use C-style awful macro kludges) eventually lead me to: https://blog.golang.org/generate Now I'm wondering if you joke was not actually a joke.

We have a lot of codegen in our codebase right now and I can't wait for the day that generics are finally added.

As heavy critic, but also fan, I have been following up on it, and the last update on the document is from September, so I am positive they might make it, it just appears the proper implementation still has some engineering challenges.

https://go.googlesource.com/proposal/+/refs/heads/master/des...

Re: Swift Algorithms

#64

Post by pjmlp »

nicoburns wrote: post #60
hazz99 wrote: post #50

Earlier quoted context omitted.

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.

Go will eventually grew up to be like Java and Cä# in 2020.

Java was released in 1996, and only got enterprise-style C++ adoption around 2000.

Until then, the inheritance and enterprise-style programming was done in a mix of Smalltalk, Eiffel, C++ and C based OOP.

Julia is basically Dylan/Common Lisp at its kernel, Java and C# are getting all the ML like goodies to stay relevant, see C# vs F#.

Re: Swift Algorithms

#65

Post by pjmlp »

stephencanon wrote: post #51
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.

Swift blog also has enough of such examples right on the introduction.

Re: Swift Algorithms

#66

Post by Joker_vD »

bee_rider wrote: post #14
pmiller2 wrote: post #9

Earlier quoted context omitted.

Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in the code that humans actually write.

Googling about this (I assumed the actual 'solution' would be a to use C-style awful macro kludges) eventually lead me to: https://blog.golang.org/generate Now I'm wondering if you joke was not actually a joke.

Well, and there is also kinda sorta support foir generics on top of it:

https://github.com/vasilevp/aboriginal

There is no engineering challenge that can't be overcome by ingenious thought!

Re: Swift Algorithms

#67

Post by JamesSwift »

nicoburns wrote: post #57
dep_b wrote: post #52

Earlier quoted context omitted.

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.

I dont agree with "C# library ecosystem is lacking". The nuget ecosystem is massive, and the paid offerings side is much larger (owing to more of an enterprise audience generally). There arent a lot of well known projects that _run_ on the CLR like there are on the JVM, but the in-language ecosystem is just as robust as those other ecosystems if not more so.

Re: Swift Algorithms

#68

Post by bredren »

How much of this collection had decent open source packages already available?

How much more efficient are Apple’s algorithms over what was generally accepted as the best prior open source version?

Were these algos already a standard set for Apple engineers internally?

It seems like customers win if Swift apps are more efficient and less error prone.

Re: Swift Algorithms

#69

Post by nicoburns »

JamesSwift wrote: post #67
nicoburns wrote: post #57

Earlier quoted context omitted.

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.

I dont agree with "C# library ecosystem is lacking". The nuget ecosystem is massive, and the paid offerings side is much larger (owing to more of an enterprise audience generally). There arent a lot of well known projects that _run_ on the CLR like there are on the JVM, but the in-language ecosystem is just as robust as those other ecosystems if not more so.

> the paid offerings side is much larger

The fact that a lot of the offerings are paid is a massive negative to me. I don't know of any other language ecosystem that is like this.

Re: Swift Algorithms

#70

Post by objclxt »

hechang1997 wrote: post #58
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.

> only frustrated by Apple giving it Windows support a decade after it's creation.

Swift was only publicly announced six years ago.

Post reply on HN