The Swift Programming Language

File: 1473377038233.jpg (287KB, 2016x1210px) Image search: [Google]

287KB, 2016x1210px

>>60936694
>t. mactoddler

>>60936694
>Has both ownership model and Garbage collection
TOP FUCKING KEK, IT'S LIKE BEING BLIND AND DEAF AT THE SAME FUCKING TIME

File: 1490213164540.png (154KB, 1186x954px) Image search: [Google]

154KB, 1186x954px

>>60936694

>>60936829
Swift does not have garbage collection.

>>60937528
Swift IS garbage.

>>60936829
Swift uses reference counting, not garbage collection for memory management. And the reference counting overhead would drop to zero with the ownership model.

>>60936694
Rust never had a chance. Why? Because no major OS or platform supports it.

Rust is a colossal waste of time and effort. If you're learning Rust, you're a fucking idiot because your skill will be useless. No one is hiring for Rust development.

>>60937534
you're a brainlet if that's what you really think. you're probably some dumb pajeet who uses winshit.

>>60937569
>reference counting
what's that? that any good?

>>60937022
Yeah, guess how that chart will look when they implement the borrow checker.

>>60937616
http://lmgtfy.com/?q=reference+counting

>>60936694
That's pretty great. I like swift's syntax much better than rust's. If they use borrow checking instead of ARC, that should close the performance gap between the languages, since they both use LLVM.

>>60936694
The borrow checker in Rust also ensures deadlock safety afaik. Can Swift 4 guarantee that as well?

>>60937791
I have to second this. Working a year with Swift now and everything is so... sane. I don't really have anything to complain about it. /g/ will hate it forever, because it's from Apple, but I really enjoy it.

>>60936694
Didn't swift pre and post incrementation

>>60937941
Remove*

>>60936741
>>60937941
>>60937952
If you write code that increments a variable, your code is shit be default in 2017. In C yes, you need that for retarded pointer arithmetic, but in swift for example you use for-in loops or .enumerate(). If you use ++, --, += 1 etc. in a modern language you are doing it wrong.

File: 1497243612893.jpg (380KB, 1600x1329px) Image search: [Google]

380KB, 1600x1329px

>>60938021
This is some high quality bait.

>>60937569
>reference counting,
>Implying that shit is any better

>>60937632
Same?

>>60938035
Proof me wrong then. I use +=1 in swift maybe once in two months. In C I would have to use it everyday multiple times.

>>60938039
>Implying you know what you are talking about.

>>60937022
/thread

>>60937022
Checked

File: 1496070285575.jpg (374KB, 1280x720px) Image search: [Google]

374KB, 1280x720px

>>60938092
++ and -- (as well as += 1 and -= 1, when optimized) provide a direct abstraction for the INC and DEC instructions. There's no fucking reason to not have them, case closed.

>>60937616
It's slower than GC in most cases, particularly with a lot of small allocations.

>>60938104
Nice deflection.

>>60936694
Who gives a shit about this language? No one uses this shit except mactoddlers.

>>60938152
Your compiler is smarter than you and doesn't need special syntax to notice when you're incrementing something by 1. LIke everything else in C, all it grants you is some false sense of empowerment like you're programming to the metal when you really have no idea what's going on.

>>60938152
int i = 1
printf("%d%d%d%d", i++, ++i, i++, i+++++i);
If you know without compiling what this shits prints in C, you are allowed to have them. Also if you imply you can't map +=1 to INC and need ++ for that, you are retarded and deserve to die together with your deprecated pointer arithmetic feature.

>>60938192
In 5 years you will.

>>60938240
In 5 years it will die

>>60938152
Actually if you love them so much, you can overload the ++ and -- operators in swift to get the previous behavior.

>>60938249
>laughing whores

Is there anywhere to read about this? All I'm finding on the subject is some year-old mailing list post from chris lattner floating the idea

>>60938340
Its somewhere in the last 20 minutes of this talk:
https://developer.apple.com/videos/play/wwdc2017/402/

File: Screenshot from 2017-06-17 02-39-50.png (203KB, 1920x1080px) Image search: [Google]

203KB, 1920x1080px

>>60938424
well fuck this

So is Swift the language I have to learn in order to make apps and make some serious dosh?

>>60938465
Swift and Obj-C are used in the apple ecosystem, so if you want in on that: yes, basically

File: autism.jpg (13KB, 238x279px) Image search: [Google]

13KB, 238x279px

>>60938459
>tabs on the side

>>60938424
>>60938459
this?
https://www.youtube.com/watch?v=3y42Qg6MTvk

File: 1493464273832.png (90KB, 1920x1055px) Image search: [Google]

90KB, 1920x1055px

Rust is one of the big boys, you do know that right? And let's see some proper source.

>>60938231
it's undefined by standard in which order they will execute

>>60937592
possible bait but

>Rust never had a chance. Why? Because no major OS or platform supports it.

Rust runs on all major platforms and OSs while Swift is crippled outside of macOS/iOS

>>60937791
>That's pretty great. I like swift's syntax much better than rust's

They look pretty similar to me

>>60937592
>Because no major OS or platform supports it.
So this is the power of /g/, a bunch of dumb mactoddlers

File: 1487463346404.png (295KB, 1772x830px) Image search: [Google]

295KB, 1772x830px

>>60938505
Heh, that shit actually crashes because of an overflow. Nice try

>>60938536
It's wrapping up the overflow

>>60938536
Panics are not crashes.

Also release build won't check for overflows.

>>60938571
>Also release build won't check for overflows.
no shit

>>60938483
Thanks. The video doesn't actually have much to say about it but they reference this:

https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md

I'll probably never use Swift but it's cool to see compiler-supported ownership semantics become popular in newer languages.

>>60938505
Can you explain to a retard what is this code doing?

>>60938604
It's basically iterating through some numbers and when the numbers get to a certain number it's starting from zero, and then adding them up

>>60938604
Overflowing memory

>>60938511
>possible bait but
it's not.

>Rust runs on all major platforms and OSs while Swift is crippled outside of macOS/iOS
who gives a shit what Rust runs on? You misunderstood my point completely. Rust is doomed for failure because no OS or PLATFORM requires is and NOTHING is built with it. There's no MS, Apple, Google that's created something huge that will make all developers use it.

Rust is fucking dead and that "MUH SYSTEMS PROG LANG" meme doesn't have any legs.

>>60938639
1. Claim Rust doesn't run on all platforms
2. Get BTFO
3. "Just because I said so doesn't imply I meant it"
Fuck off idiot mactoddler

>>60938639
Is that why Objective-C/C++ died?

>>60938595
Swift seems like a cool language but it's probably not worth learning unless you work on Apple platforms and don't care about portability.

>>60938639
Nothing "requires" Swift either. AFAIK most Apple software still uses Objective C.

>>60938716
>it's probably not worth learning unless you work on Apple platforms
Yeah, it's (current) uses outside of the Apple ecosystem is rather limited.

>>60938699
Rust is not C++. C++ has huge momentum and was the prog lang of choice for many platforms (including WIndows). Windows itself has tons of C++ code and whole of MS Office is written in C++. C++ will endure forever. Obj-C was the only way to program Macs and iOS and iOS is huge. Obj-C will live on for a very long time.

Rust is fuckign dead. Only retards don't see how pointless it is.

>>60938716
>Swift seems like a cool language but it's probably not worth learning unless you work on Apple platforms and don't care about portability.
IBM is pushing it heavily for enterprises.

>>60938716
>Nothing "requires" Swift either. AFAIK most Apple software still uses Objective C.
Retard, iOS supports it. It's the recommended language for iOS development.

What platform requires or recommends Rust? Which billion dollar company is pushing Rust and is releasing tons of code and examples for their platforms in Rust? That's right: NONE!

RUST IS DEAD.

File: 1488243967606.jpg (405KB, 900x1200px) Image search: [Google]

405KB, 900x1200px

>>60936694
>killed the Rust language
lol these script kiddies

>>60938741
>Rust is fuckign dead
It's more alive than your git activities

>>60938639
I used Rust for a small side project and the borrow checker is an outstanding feature that guaranties security. I would say Rust is directly responsible that this feature was added to Swift 4. So Rust served it's purpose well and can now go down the same rode as the D programming language.

>>60938741
Are you upset right now?

$ rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: checking for self-updates

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.18.0 (03fc9d622 2017-06-06)

>>60938741
>Rust is dead
>C++ rushes to add a half assed borrow checker into the langauge
>Swift rushes to add another implementation of half assed borrow checker to them
>random basement dweller of /g/ gets autistic meltdown

It's all happening guys!

>>60938249
>in 5 years the richest tech company in the world's programming language will die
do you people even try

>>60938756
Servo is a fantastic example of Rust's production usage. Servo is much more GPU aware and uses way more GPU resources unlike other web rendering engines. Samsung is actually sponsoring servo

>>60938789
Yes, learn from Obj-C/C++.

>>60938752
>It's more alive than your git activities
haha... I see you've run out of arguments and now you're resorted to personal insults. we're done arguing kiddo.

>>60938756
sure. and Rust took some stuff from Swift too (C# is similar and ideas went both ways too). but that doesn't really change the fact that Rust will go nowhere. it's just another of the multitude of dead languages that people still hack with. Lisp, Scheme, etc etc... Rust will join that group.

>>60938760
Not at all. There was some guy who did conversions of piece of kernel into Rust. Who cares. Linus won't support that shit.

>>60938781
Well, it is dead. If other languages keep on improving, you'll have ZERO incentives to move over to Rust.

>>60938801
>Servo is a fantastic example of Rust's production usage
Hahahah... WHAT THE FUCK ARE YOU SMOKING? Servo won't replace FF engine for a year. And by that time, FF will be down to 8% and will be dead as well.

>>60938815
>actually being this mad

>>60938815
Linus won't support it because it's philosophically a C only project, you underage toddler

>>60938815
>haha
Did that strike your nerves?

File: 1473308622600.jpg (20KB, 200x200px) Image search: [Google]

20KB, 200x200px

>>60938819
>no arguments
>personal insults
>thinks I'm mad when I'm laughing at his face at how stupid he is
I'm sure you'll land that 6 figure salary programming Rust eventually.

>>60938511
>>60938639
>>60938741
>>60938815
>>60938836
All it takes is one (ONE) clueless shit poster to derail the thread.

>>60938815
Chillax, son

>If other languages keep on improving, you'll have ZERO incentives to move over to Rust.

Swift won't ever be as fast as Rust.

C++ won't ever be as safe as Rust.

Rust is as fast as C++.

Rust is safer than Swift

File: 1470971856248.jpg (88KB, 1024x1152px) Image search: [Google]

88KB, 1024x1152px

>>60938856
None of those matter. No manager will pick Rust for some big project based on the bullet points you indicated.

Rust's biggest barrier is that no multinational, billion dollar company that has a computing platform supports it and pushes it. Rust is basically a Mozilla project and Mozilla's extremely weak, cannot offer support to other companies and is pretty much dead. Rust has no future.

C++ is good enough.
C# is good enough.
Swift is good enough.
Rust is dead.

>>60938944
This

Nobody uses Rust for enterprise level applications

>>60938956
>Nobody uses Rust for enterprise level applications

Dropbox, npm, Samsung to name a few are listed on the official website
https://www.rust-lang.org/en-US/friends.html

Visual Studio Code uses ripgrep for searches
https://code.visualstudio.com/updates/v1_11

even Facebook uses it, it seems
https://www.theregister.co.uk/2016/10/18/facebook_mercurial_devs_forget_git/

>>60938856
First what >>60938944 and >>60938956 said

>Swift won't ever be as fast as Rust.
Swift is already very close and it has no limitations that would prevent that gap from shrinking further. I would be careful with that assumption.

>>60939043
>it has no limitations that would prevent that gap from shrinking further

It has garbage collection you retard

>>60939075
For the 100th time now, SWIFT DOES NO USE GARBAGE COLLECTION! Swift uses reference counting which overhead will be reduced to literally nothing when the ownership model gets implemented.

>>60939124
ARC is a form of garbage collection

>overhead will be reduced to literally nothing when the ownership model gets implemented.

That does not come for free. You need Rust's semantics. Either they keep ARC around and add some form of ownership for certain things or they drop ARC altogether and all Swift devs start "fighting the borrow checker" like in Rust.

>>60939198
>ARC is a form of garbage collection
Ahaha

>>60939271
No matter what you call it or don't call it, it is automatic memory management. It can't magically from a language and converted to manual memory management with backwards compatibility.

>>60938536
then just use 64-bit ints, retard.

>>60939340
> It can't magically from a language and converted to manual memory management with backwards compatibility.

fuck my typing:

It can't magically BE REMOVED from a language and converted to manual memory management with backwards compatibility.

>>60939340
>Implying arc is the same as literally stopping all threads of the program, going trough all allocation tables of all threads and check what is not needed anymore every x milliseconds.
>Implying you can't call malloc and free in swift if you want manual memory management.

>>60939340
Imagine being this retarded.

>>60939441
>>Implying you can't call malloc and free in swift if you want manual memory management.

Then it's not the same language anymore. You reinvented C. Good job.

>>60938152
>++ and -- (as well as += 1 and -= 1, when optimized) provide a direct abstraction for the INC and DEC instructions

No. Only whne you use it to increment numbers. In most cases, you use them to increment pointers and there it doesn't map to inc or dec anymore.

There's no need to have dedicated syntax for this in Rust at all.

>>60938944
>C++ is good enough.
>C# is good enough.
Spotted the fizzbuzz artist

File: 1488728022762.jpg (63KB, 960x651px) Image search: [Google]

63KB, 960x651px

>>60938219
>when you really have no idea what's going on

>>60939075
>It has garbage collection you retard
>I have no clue but I'll still give my input
Garbage collection doesn't affect overall performance, only pauses. If anything icaching the cleanup code makes it more efficient than RAII.

>>60936694

Swift is more beautiful.

I was learning chapel, the only language that is bringing something new to the board with it's locality-oriented features for distributed systems and parallelism.
But currently it can't use libraries compiled with it, should be fixed in the future but idea when.

Swift seems to be decent alternative for chapel for the moment.
How good is the platform support and operating system support? Kind of afraid because it's apple's product and I doubt they give shit about supporting windows for example.
It's new language so there's not many libraries. How easy is the foreing function interface?

>>60939518
Any systems language can do that, retard

>>60936694
lel, you are free to try, Rust will still be at least twice as fast than s*ift. Fuck off, mac toddler

>>60941048
>Garbage collection doesn't affect overall performance, only pauses.
Garbage collection isn't a magic pause. Tracking the memory has a cost. It doesn't come out of thin air.

Swift has ARC that doesn't pause. Still it adds runtime costs.

> If anything icaching the cleanup code makes it more efficient than RAII.
Nice meme. Show me an example where the same implementation of an algorithm is faster on a language with automatic memory management is faster than the C++/Rust implementations

Recently I often see people claim that garbage collection is now faster then reference counting. They then continue linking +100 page scientific papers which I have to admit I'm too lazy to read. But seriously how can that be true? The overhead from +1 and -1 for the reference counter can't be that much. I assume it can be heavily optimized by the compiler as well, even without borrow checking.

File: skeptical smug.jpg (60KB, 600x582px) Image search: [Google]

60KB, 600x582px

>>60936694
>>60936741
>removing ++ and -- operators because mac users are too retarded to commit it to memory

>>60943835
>Recently I often see people claim that garbage collection is now faster then reference counting
Whoever says that is retarded. It's the same type of JavaShit retards who claim that NodeJS is on par with C++.

>>60943877
You know it's not true but at the same time you are too dumb to know the language paradgims.

>tfw java is shit
>tfw c is shit
>tfw c++ is shit
>tfw f is shit
>tfw java is shit
>tfw javascript is shit
>tfw swift is shit
>tfw pearl is shit
>tfw C# is shit
>tfw F# is shit
>tfw cobal is shit
>tfw rust is shit
>tfw golang is shit
>tfw pascal is shit
>tfw python is shit
only haskell and erlang remains

>>60944017
>only haskell and erlang remains
Those are shit too. D is the only godly language.

>>60938152
Not every architecture has inc and dec instructions, and even on the ones that do (i.e x86) you probably don't want to use them unless you're optimizing for size because they cause stalls via partial flags updates - inc doesn't set carry flag, while add reg, 1 does, which is bad for parallell execution.

>>60943835
>The overhead from +1 and -1 for the reference counter can't be that much.
It's an atomic increment/decrement, which does have large overhead, and typically prohibits lots of optimizations like code movement due to the syncronization barriers inherent in atomic ops.

>>60944290
>D is the only godly language.
I crave the D, I lust after the D. I work with D all day. At night, I dream about D.

>>60943967
Really makes you think.

>>60944017
Your a shit and your waifu is a shit.

>>60945237
>>60944290
I hate you all, I am going to destroy the internet tomorrow, just watch me

File: 794.png (77KB, 500x500px) Image search: [Google]

77KB, 500x500px

>>60938021
>current year

File: 1496772320297.jpg (542KB, 960x1280px) Image search: [Google]

542KB, 960x1280px

>>60944017

Assembly is the only GOD TIER language!

>>60936694
Friendly reminder that Swift can't even be compiled without a poor port of the poor Linux libs on Windows. Whereas Rust just werks on Windows.
>inb4 install gentoo
Basically, it will never grow outside of MacOSX, because it's just a layer of paint above ObjectiveC.


>>60936741
They did good, x += 1 is way more readable.

>>60937528
Reference counting is a form of garbage collection.
Garbage collection is divided into tracing garbage collection and reference counting garbage collection, it's just plebs who refer to them as reference counting and garbage collection.

>>60936829
That actually sounds useful for otherwise cabbage collected language if it was implicit. Could be the same as escape analysis, though.

Why should I care about memory management, retards? It's 2017 and I don't program like we're still in the 1950s. No wonder most of you are NEETs.

>>60944017
All C-inspired language are shit and cause burnout. Switch to Visual Basic, the only good language.

>>60946287
>visual basic

>>60943835
Reference counting as a uniform memory management strategy was never faster than tracing GC; this isn't something that changed recently. You might be thinking of people suggesting GC is now faster than manual memory management, which is more contentious.

Ref counting is fine when used measuredly, but the overhead is high when it's the default and you're constantly updating the count of every single heap allocated value in the program. Running a periodic GC pass has less overhead, usually at the cost of less predicatable performance.

The reason Swift uses reference counting has less to do with technical concerns than it does with legacy of Objective-C and OSX's developer APIs. Offering a way to partially opt out of this system is sensible.

>>60948140
underrated post