Swift Programming Language

Why is nobody discussing Swift here?
Isn't there a need for a modern and programmer friendly C++ replacement?

It's open source, available for Linux and Apple platforms, and even a unofficial port to Windows exists.

Attached: swift_sq.png (400x400, 41K)

Other urls found in this thread:

gchandbook.org/contents.html
mono-project.com/docs/advanced/aot/
github.com/dotnet/llilc
github.com/dotnet/corert
github.com/def-/nimes
en.wikipedia.org/wiki/Sequence_point
twitter.com/AnonBabble

>betting on Apple's ecosystem for longterm
>using Swift without for anything not Apple-centric
no sorry
But I like the idea of developing standard high-level language for a platform. Windows has C#, Applel has Swift, Linux has flamewars

I mean there is also rust, but judging from the short look I had at it, it's not a very well designed language.

There are a few different string types that one has to use, different kinds of pointers, etc, making it even worse than C++ in some sense.

But its Objective-C replacement or companion

Attached: 1473904892658.jpg (1106x1012, 362K)

You also have to consider that the C standard library contains next to nothing, and still it got big on all platforms.

Honestly there seems to be a lack of native, modern languages with potential.

Swift is a language you use to get work done.
Jow Forums prefers language that make the act of writing a fizzbuzz program unreadable, unmaintainable and slow.

So what? It's still a general purpose language.

Not really. Even C++ has more kinds of pointers and there are worse designed than Rust's.
Different strings come from the need to distinguish between allocation handler and view on array. This is same for vectors/arrays. C++ has that as well. All of the avoiding unnecessary allocations by sharing data are much cleaner and transparent in Rust than in C++.

>Isn't there a need for a modern and programmer friendly C++ replacement?
That's Go.

Attached: gopher_monitor.png (398x460, 82K)

it's useless legacy anyway

It's from times when compilers were retarded enough to actually use add instruction on n += 1 instead of inc. There is no need for them except for oneliners and they overcomplicate expressions evaluation by a lot.

It is a very well designed language and still actually much simpler than c++.
The multiple string types are there to be able to handle basic cases that c++ can't (or couldn't before c++17 when they actually added more string types).

coding on aplel platforms is bliss
>tfw mixing C, C++, Swift and Objective C effortlessly

if err != nil

Attached: retarded gopher.png (300x441, 20K)

garbage collection is worse than RAII and ownership

Attached: rustlogo.png (512x512, 84K)

>SJWift
Not even once.

Attached: 1514286773039.jpg (2016x1210, 285K)

Swift uses automatic reference counting

Somebody need blinding and maintain GUI,OS,compute,graphics libraries to swift if no is dead, today swift non-Apple had less libraries that Haskell,lisp or Ocaml.

Swift is great for iOS and Mac development because the alternative is Objective-C/C++ which is slower and bad. If you are not doing iOS or Mac development then don't use swift because C++ is better. You can also use C and C++ with Swift except you can't really use Apple APIs from there so you still have to use Swift in an iOS or Mac program.

>ARC is bad GC
Read a book please.

gchandbook.org/contents.html

>applel

Attached: 1508616377954.png (1008x872, 428K)

What's wrong with a compiler and editor having unicode support?

yes cause managing your errors is sooooooo bad. just ignore them if they piss you off

How else you gonna make fart apps without the poo emoji?

Attached: 1517026014636.png (704x817, 309K)

App Store submissions for fart apps have been permanently set to being declined way before Swift ever got introduced.

>what is panic

>no support for generics
>modern and programmer friendly

I prefer no generics over no decent standard build system.

C# has true coroutines and TPL. Everything else is shit garbage for multithreaded code.

that's C++

>C#
>doesn't produce native code
>no up to date Linux support
It's not really a C++ replacement

>

mono-project.com/docs/advanced/aot/
github.com/dotnet/llilc
github.com/dotnet/corert

>pic related
rust users will defend this

Attached: rust_convert_command_line_argument_to_int.png (801x321, 21K)

>C
>>signed long long short short int

>rust
>i64
>u64
>f64

Attached: 1502875481695.jpg (419x500, 32K)

>Isn't there a need for a modern and programmer friendly C++ replacement?
Yes, and the name is Nim github.com/def-/nimes

Attached: 39615311-627cbc2a-4fb0-11e8-8ecc-9f76430cab97.png (728x484, 31K)

Not judging the language itself, but isn't this like a one-man project with no chance for wide adoption?

That's the beauty of the language. It even has its own scripting language and package manager.

>>rust
>>i64
>>u64
>>f64
>the difference between a int and a float is just one character
>the bitwidth is more prominent than of what the type the varibale is
>it will nearly always be 64

that's actually horrible language design

what is typedef
kys noob

nice strawman retard
atol/atoi are broken shits that do zero checking/error handling, the correct way to do this in C is:
[pic related because Jow Forums thinks it's spam]
Rust has more elegant way then presented
let a1 = os::args().nth(1).unwrap();
let n: u64 = a1.parse().unwrap();

Attached: Screenshot from 2018-06-10 21-48-39.png (540x228, 18K)

>defending Perl^H^H^H^HCisms

Attached: tumblr_omz0wlDc6I1s667kio4_1280.png (800x1055, 172K)

>goto
Fkn dropped m8

>tumblr
go back

that's because you suck at C practices

>elegant
topkek. the Go way is still the best, just add chk(err) afterwards.

How else do you do error handling without exceptions?

What?

Who has ever thought writing unsigned long long long long int a = 0; is in any way a good idea.

>go back
I am "back".

Attached: 1283884057639.jpg (261x243, 23K)

It's slower than C, do not want.

post the benchmark

>having to make things up to make your 8 year old language look competitive with a 46 year old language

Rust is a terrible language don't listen to its apologists like this The syntax is fucking retarded "Arc" "Box". Seriously fuck off with that shit.

raw pointer
unique_ptr
weak_ptr
shared_ptr

Is all you really need

>Rust faggot comes in thinking Swift uses GC
This is why no one takes you seriously.

It's kind of sad that rustaceans defend this sort of performance...

Attached: benchmark.jpg (643x29, 16K)

What's c#?

unique_ptr is literally Box
shared_ptr is literally Rc
weak_ptr is literally rc::Weak

fake, I can see the echo and same string above that

What's even the supposed advantage of Rust compared to C++11 (and above)?

Not having header files?
(which is admittedly a notable difference in convenience, but nothing that makes it stand out among other modern languages).

Having to deal with pointers and even different kinds of them is annoying and unnecessary.
It makes the code look ugly.

>Isn't there a need for a modern and programmer friendly C++ replacement?
No.

>Isn't there a need for a modern and programmer friendly C++ replacement?
Yes. Which is why we're not discussing Swift.

>2018
>still using header files
>having to write shared_pointer when you could just write Foobar in other languages.

Then make a better proposal.

What's wrong with this?

>What's wrong with this?
Header files are redundant and mean lots of needlessly wasted work hours.
>shared_pointer
No imagine you have to return a pair of them.
pair p{shared_pointer{new FooBar{"hello"}, shared_pointer{new FooBar{"world"}}

>Header files are redundant and mean lots of needlessly wasted work hours.
Use your ide.
>No imagine you have to return a pair of them.
Won't happen in real life.

>Won't happen in real life.
How would you then return a pair of objects?

>It makes the code look ugly.
>argues for C++
are you fucking kidding me

the problem for C++ is when you want to avoid using smart pointers because you want to avoid allocations
imagine data structure, e.g. classic hashmap that has pointer types on owned allocation as values, is you want to get the value from hashmap
- do you get ownership of the value thus removing it from hashmap?
- do you make copy thus making another allocation?
- do you get shared reference (in C++ case it would raw pointer, not shared pointer) thus both collection and procedure have access to the value data? how do you ensure the pointer is valid for its full lifetime?
Rust makes these easy and transparent with lifetimes, C++ not so much.
Muh modern C++ shills argue that C++ as all the features Rust has (not just smart pointers but also tuples, variants, optional, ...). Except lifetimes they are right. They are ugly named and the code looks ugly and unreadable but they are there. But they are nowhere in standard library, that one is stucked in 90s.
Not sure if C++ has any thread-safe smart pointer types/containers.

I am not arguing in favor of C++, I am questioning whether Rust really has considerable advantages.
And actually, I don't want to care about this pointer shit.

Good book.

Attached: reference-counting.png (1668x394, 81K)

I don't use Rust either, some concepts are nice and C++ is massive clusterfuck. But I don't like Rust's codebase and their lack of attention for simple solutions, the whole compiler is unnecessarily big, the surrounding tools have too big interfaces and do too many things in monolithic manner. The borrow/lifetime checker could easily be external static analysis tool if the compiler had bindings made for that. The compile times are slow and they are trying to do state of the art functional-language type system for it. Plus I don't trust Mozilla in anything. But there is no perfect language, I don't know what's less evil.

Why would that complicate anything?

Which is garbage collection.

int64_t
uint64_t

I wish Swift was less of a pain on Linux. It would be nice if it too a bit out of Java's enterprise market share, as IBM hopes.

>dude, let's do it this way!
>oh wait, actually no, let's do it that way
>nevermind, final version now, let's do it this way
>what do you mean you don't want to beta test a programming language?

en.wikipedia.org/wiki/Sequence_point
it's also source of undefined behavior in C/C++
Technically they are not expressions but statements. Go did it correctly and allowed the on separate like and not in other expression. It keeps the familiar nice-looking way without all the caveats and complications of using statements and assignments as expressions C-style.

I suspect Kotlin has the best chance of that just because of its great Java interop. Embrace and extend is still the best way to exinguish.

the worst kind of garbage collection

In rust you always you have reference counting, too. You just always have to specify which kind of reference counting pointer to use, which just makes everything more pain in the ass.

I don't want to think about pointers and the memory model, I want to deal with the problem domain.

A huge part of Swift's to me is the unboxed data structures and value types. Alas, the JVM is still far behind on this. Even when these features arrive it will take a lot time before libraries switch to them because of backwards compatibility.

don't lie, the default way is automatically adding destructor to the end of owning scope, there is no reference counting happening unless you use reference-counting container
>I don't want to think about pointers and the memory model
and apparently you don't
just use garbage collected language please

>the default way is automatically adding destructor to the end of owning scope
But don't you always have to deal with it if you want to return an object from a function?

>just use garbage collected language please
Yes, that's what I am arguing for.

>But don't you always have to deal with it if you want to return an object from a function?
no, you can return it by value or write into passed pointer with stack-allocation from outer scope

Go is literally useless. I can't find a single use case for it that makes it preferable to any other language.

Yeah this is sort of lame. Who does it confuse?

Kotlin is the best language right now, Swift is second.

>Ctrl + F "garbage"
>6 hits
go figure

5/6 was for "garbage collection"

Attached: 1510651368240.jpg (1000x857, 107K)

>The borrow/lifetime checker could easily be external static analysis tool if the compiler had bindings made for that.
That's like saying you should just be able to write "assert" and have an analyzer guess what your invariants are

assert doesn't work with AST and interface exposed by compiler

>Isn't there a need for a modern and programmer friendly C++ replacement?
D

Honestly, if you're reaching as far as Nim, you should just bit the bullet about learn Haskell or (easy mode) OCaml.

You are genuinely retarded then.

Nothing I suppose, but an emoji language?

What are the similarities between Nim and Haskell? I don't know much about either language. I could probably just google it but I thought I'd ask a human directly first.

kek enjoy undeterministic halts in multiprocess

Swift is just another way for Apple to create a closed ecosystem on their devices, under the guise of it being open.

But swift is supported by ibm

That's another reason not to use it...

Yet no one uses C# or any of this garbage in code that requires ACTUAL shittons of parallelism such as computational fluid dynamics/finite element solvers. Everyone still uses C/C++/Fortran with MPI. Servers (i.e. spark/hadoop shit) typically run Linux so no one uses C# there either.