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

Swift is Open Source

swift.org

Post reply on HN
Print view View original

391–400 of 458 posts

Re: Swift is Open Source

#391

Post by masukomi »

iso8859-1 wrote: post #388
dangjc wrote: post #386

Super excited! I will totally be exploring Swift for quantitative work. Julia has been great so far, but a lack of good IDE tooling is making a large codebase difficult to navigate and keep clean. Python has even less type safety than Julia. Swift has a REPL! Go doesn't, and its lack of generics makes writing most algorithms very limited (there isn't even a matrix 32 library, just 64 bit). Java has horrible native in…

You don't need an ecosystem? Swift does not have this, not for Linux at least.

some of us get by just fine in happy ecosystems that exist outside of linux.

Re: Swift is Open Source

#393

Post by niutech »

dangjc wrote: post #386

Super excited! I will totally be exploring Swift for quantitative work. Julia has been great so far, but a lack of good IDE tooling is making a large codebase difficult to navigate and keep clean. Python has even less type safety than Julia. Swift has a REPL! Go doesn't, and its lack of generics makes writing most algorithms very limited (there isn't even a matrix 32 library, just 64 bit). Java has horrible native in…

It is a huge step for Swift. Finally it is no longer the Apple walled garden and it will become a popular universal platform like Python or JavaScript, for sure. If you want to learn Swift, it is high time. Start with the huge collection of 300+ video tutorials at https://www.youtube.com/user/TheSwiftLanguage

Side note: Julia is great. Very easy to learn, blazing fast, powerful, general-purpose, works everywhere and even integrates well with C/Python/Fortran. As for the IDE, there is Juno based on LightTable, there is Sublime-Julia for Sublime Text, as well as Julia support for Atom.

Re: Swift is Open Source

#394

Post by copperx »

dangjc wrote: post #386

Super excited! I will totally be exploring Swift for quantitative work. Julia has been great so far, but a lack of good IDE tooling is making a large codebase difficult to navigate and keep clean. Python has even less type safety than Julia. Swift has a REPL! Go doesn't, and its lack of generics makes writing most algorithms very limited (there isn't even a matrix 32 library, just 64 bit). Java has horrible native in…

> C++ has too many gotchas, slow compile, to feel productive.

Which raises the question: Why was the compiler for Swift written in C++? I know writing a compiler in C/C++ is probably an instinctual reaction at this point, but um ... what's the advantage of C++? especially if the language will become self-hosting?

Re: Swift is Open Source

#395

Post by niutech »

SureshG wrote: post #385
justinhj wrote: post #269

Earlier quoted context omitted.

"learning/mastering both Go and Swift is the best decision you can make" is a very bold claim. In my area we use Go for some systems but found it scales badly from an engineering point of view to larger more complicated systems, compared to languages like Java and Scala. The JVM has much more mature tooling and libraries too. For mobile applications it will be a while until Swift is stable on Android, so some of the…

For android, we already have kotlin ( https://kotlinlang.org/ ), which is very similar to Swift and has 100% interoperability with java.

Better alternative is Groovy: https://jaxenter.com/groovy-is-the-swift-alternative-for-and...

Re: Swift is Open Source

#397

Post by DasIch »

copperx wrote: post #394
dangjc wrote: post #386

Super excited! I will totally be exploring Swift for quantitative work. Julia has been great so far, but a lack of good IDE tooling is making a large codebase difficult to navigate and keep clean. Python has even less type safety than Julia. Swift has a REPL! Go doesn't, and its lack of generics makes writing most algorithms very limited (there isn't even a matrix 32 library, just 64 bit). Java has horrible native in…

> C++ has too many gotchas, slow compile, to feel productive. Which raises the question: Why was the compiler for Swift written in C++? I know writing a compiler in C/C++ is probably an instinctual reaction at this point, but um ... what's the advantage of C++? especially if the language will become self-hosting?

LLVM is written in C++ and I'm assuming that the Swift compiler developers are also very familiar with C++. It's also fairly straight forward to write binding for any language to things written in C/C++. The latter makes it at least theoretically possible to build tools on top of the compiler. C++ is really the obvious and simple choice, that you can get away with without large discussion.

Also if it's actually planned to make Swift self-hosting, the language you write the initial compiler in matters even less. If you're throwing it away anyway at the first opportunity, who cares about a few imperfections?

Re: Swift is Open Source

#398

Post by DasIch »

darkarmani wrote: post #286
carussell wrote: post #149

Earlier quoted context omitted.

What it means from a legal standpoint is that Apple is bound by the same terms as everybody else. The way it works is this: Apple is making Swift available to you (and others) under Apache 2.0. You send in some changes, which you make available to Apple (and others) under Apache 2.0. Everyone is on equal footing, and Apple can't relicense it to someone else on terms of their choosing that involve, for example, neuter…

That ridiculous: "started cargo-culting the(totally unnecessary) CLA process" It's so they can re-license in the future. There are some projects with so many authors that it is impossible to re-license because you need sign-off by every single person, even if it makes sense to re-license.

That's a feature. What is the point of contributing to a project, if someone else can effectively destroy all your work at their discretion?

Re: Swift is Open Source

#399

Post by swhipple »

rcthompson wrote: post #377
scolson wrote: post #317

Earlier quoted context omitted.

You can retroactively make a license more open, but you cannot retroactively make it more closed.

If I am the sole owner of a work, I can change the license of newly distributed copies from any previous license to any new license that I want to, even if the new license is more restrictive. The new license doesn't retroactively apply to copies that were distributed under the old license, only new copies distributed under the new license. However, my original question still stands. If I hack privately on a git repo…

It depends on how the license was intended to be applied.

If you're the sole owner and declare the entire repository contents under XYZ, the previous commits would be available under the license, regardless of the actual commit that adds the license file. If you declare a specific revision under XYZ, then only that revision is under the license.

A different example is the case of a repository with many copyright holders changing the license, and not being able to drag all the previous code into the newly licensed version. You wouldn't be able to take all the commits in history under the terms of the new license.

Re: Swift is Open Source

#400

Post by nikdaheratik »

Alex3917 wrote: post #354
athenot wrote: post #65

I wonder if Apple is positionning it as a competitor to Google's Go? They are hinting at a usage beyond just iOS and OS X.

> I wonder if Apple is positionning it as a competitor to Google's Go? They're giving themselves the option to get out of the computer hardware business if the car takes off without killing their phone business. Think about it. Right now if they killed off the MBP then most devs would switch to Android and they'd lose their iPhone monopoly. But if Swift gains traction as an open platform, they have the option to stop…

I don't see that happening ever. It's not just that computers are the core of their business identity/culture, but there is too much cross culture of hardware ideas for them to want to ditch it. They're free to try some new widget idea in a MacBook then refine it if it works before adding it to the phone or scrap it if it's flawed without having millions of iPhone users get upset about it. Most of the other handset makers don't have this to test with.
Post reply on HN