Apple To Open-Source & Support Linux With Its Swift Programming Language

[mmstick]

I'm not kalin, but I think Rust is still a bit immature. Currently it has only one advantage over C++ and it's the safety. Oh, and its module system (Cargo). Overall it's (sometimes much) slower than C++ (assuming you try to avoid unsafe blocks) and compilation is slower too.
I've got excited about Rust not so long ago but after trying to write real code with it I faced the problems mentioned above AND found the code become more and more unreadable because of Rust's syntax. Yes, the example codes are pretty, but real code is much harder to read and understand than C++, at least for me (tons of apostrophes, underscores, unwrap()s, pubs, fns and impls, etc.)

C++ has nothing over D, so there's already something better than C++, but with the familiar C syntax. However, I don't think Rust is immature at all anymore. It might look a bit intimidating at first, but it's fairly simple once you've learned it. If your code is unreadable, you simply haven't learned enough Rust to write production-ready software with it yet. The verboseness exists to help create better programmers by enforcing safe coding practices, or otherwise making it harder to write unsafe code.

[snadrus]

Exactly what led me to Go.

Same for me. Much easier expressions of parallelism. The easy syntax lets tools (like "go race") handle problems instead of all that verbosity.

[jhasse]

C++ has nothing over D, so there's already something better than C++, but with the familiar C syntax.

Unfortunately D has a GC which is an instant no-go for many things.

[MartinN]

Those new languages look like garbage to me.I will stick with c/c++ until something better pop up

Look at Rust. It is basically a re-do of what C++ can do today w/all the Boost/STL/smart pointer stuff. It does memory management in a very powerful, 'unique' way (at compile time), which should, at least in theory, stave off most if not all memory leaks and provides thread safety guarantees. I love both C and C++, but Rust is a serious contender. and in my opinion addressed all of the pain points of C/C++ as a systems/low level language. It's basically a paradigm shift - it makes you think differently even as you program.

Best of all, the group that created it is quite pragmatic, the stuff is well documented... It's poised to take off, IMHO.

[Drago]

Unfortunately D has a GC which is an instant no-go for many things.

I thought D's GC is optional.

[ssokolow]

I thought D's GC is optional.

D's GC is optional in the same way C's standard library is.

(Massive swathes of the D standard library require the GC, so turning it off is only really feasible if you're doing something where you couldn't use the stdlib anyway, like writing an OS kernel.)

[wizard69]

I'm wondering what they're going to do about Cocoa. Big hole in the API there.

Apparently some of the runtime will be supplied. I don't believe that means Cocoa though.

Possibly one nice side effect is that somebody might decide to write a decent GUI subsystem for Linux in it. Not cocoa either which I've never been extremely comfortable with.

[peppercats]

Unfortunately D has a GC which is an instant no-go for many things.

Welcome to 2015, this isn't 1980 stop the world anymore. Modern GCs are concurrent, parallel, and much faster than manual memory management.

Then again, most C++ programmers think shared_ptr was a good idea and not a complete fucking joke from a performance perspective. For reference, Ocaml's GC is up to 1000% faster than libstdc++'s shared_ptr performance. Reference counting is slow, shared_ptr implemented as dictated by the C++ standard is ridiculously slow. Why? Because reference counting is just a primitive tracing garbage collector that destroys your L1 cache.

The same people who repeatedly parrot that GCs make programs unusable have no idea how an allocator works, and think that malloc and free are noops.

[teldar]

Welcome to 2015, this isn't 1980 stop the world anymore. Modern GCs are concurrent, parallel, and much faster than manual memory management.

Then again, most C++ programmers think shared_ptr was a good idea and not a complete fucking joke from a performance perspective. For reference, Ocaml's GC is up to 1000% faster than libstdc++'s shared_ptr performance. Reference counting is slow, shared_ptr implemented as dictated by the C++ standard is ridiculously slow.

The same people who repeatedly parrot that GCs make programs unusable have no idea how an allocator works, and think that malloc and free are noops.

When you write time sensitive code, like games, I can asssure that when the GC hit, you see your fps dropping. That's why all serious engine are written in C++, not for the sake of it, just because it's the best language for it. If you want to say their choice is bad go ahead.

[liam]

When you write time sensitive code, like games, I can asssure that when the GC hit, you see your fps dropping. That's why all serious engine are written in C++, not for the sake of it, just because it's the best language for it. If you want to say their choice is bad go ahead.

I've never used it but I know real time java is a thing. Perhaps rt java is different but the java I learned didn't allow the GC to be optional.