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

[teldar]

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.

"The RTSJ addressed the critical issues by mandating a minimum specification for the threading model (and allowing other models to be plugged into the VM) and by providing for areas of memory that are not subject to garbage collection, along with threads that are not preemptable by the garbage collector. These areas are instead managed using region-based memory management." From wikipedia.

I didn't know about that, but it's really different than tradictional java.

[jacob]

... 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.

Oh and parallelism. And algebraic types. And memory safety. And (optional) functional syntax. And *real* generics.
Compilation is slower, indeed, and that's saying something compared to c++.

In my tests idiomatic rust code runs at a roughly comparable speed to clang c++. Sometimes slower (it seems that particularly the standard library's containers could do with some optimisation compared to stl's), sometimes faster (especially when c++ code needs to manually perform the same runtime checks than rust does or when error handling is involved). Of course it depends on the kind of program you are running.

Overall I think Rust is great language. There are some things I don't like about it, but from all the new languages that aim at replacing C/C++, e.g. D, go and swift, Rust is my personal pick.

[liam]

"The RTSJ addressed the critical issues by mandating a minimum specification for the threading model (and allowing other models to be plugged into the VM) and by providing for areas of memory that are not subject to garbage collection, along with threads that are not preemptable by the garbage collector. These areas are instead managed using region-based memory management." From wikipedia.

I didn't know about that, but it's really different than tradictional java.

Region based mm. I'd heard of it but didn't know what it was. It looks like they traded memory efficiency for time guarantees.
Still, no free lunch, apparently

[liam]

Oh and parallelism. And algebraic types. And memory safety. And (optional) functional syntax. And *real* generics.
Compilation is slower, indeed, and that's saying something compared to c++.

In my tests idiomatic rust code runs at a roughly comparable speed to clang c++. Sometimes slower (it seems that particularly the standard library's containers could do with some optimisation compared to stl's), sometimes faster (especially when c++ code needs to manually perform the same runtime checks than rust does or when error handling is involved). Of course it depends on the kind of program you are running.

Overall I think Rust is great language. There are some things I don't like about it, but from all the new languages that aim at replacing C/C++, e.g. D, go and swift, Rust is my personal pick.

One annoying thing is that it looks like HKTs are going to be a ways away. I was really hoping they'd start working on them as soon as rust go out the door, but it looks like that isn't to be the case. For me, it would greatly aid in readability of actual rust. Admittedly, I wouldn't consider myself literate yet so perhaps with more time it'll looks less eye-crossy than it does now.

[peppercats]

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.

they're written in C++ because legacy. Even carmack thinks C++ is a complete fucking mess, but you know more than Carmack right?

And it's funny you mention C++ considering C++ _by standard_ has an ABI for garbage collection.
(http://www.stroustrup.com/C++11FAQ.html#gc-abi)

The only people who hate garbage collectors are people who associate garbage collection with java. Boehm repeatedly proved over the last 25 years how much better GCs are than any other form of memory management, yet he was completely ignored.
(www.hboehm.info/gc/myths.ps)

Like typical, C++ programmers are always stuck 30 years in the past and refuse to pick up a research paper and learn something. Still no surprise that most C++ programmers think new/delete is a noop, have no idea what a cascading destructor is, or why reference counting would be dog slow(especially with the required atomic semantics the standard imposes.) This is why Linus ranted about C++ - it had nothing to do with the language, but the people who use it.

The real nail in the coffin though?
Go look at every single C++ implementation on the computer language benchmarks game. Go ahead, I'll wait. Every single one that is memory intensive implements a primitive garbage collector.

And now that we're in the multicore era, garbage collection has become more important than ever.

[jacob]

One annoying thing is that it looks like HKTs are going to be a ways away. I was really hoping they'd start working on them as soon as rust go out the door, but it looks like that isn't to be the case. For me, it would greatly aid in readability of actual rust. Admittedly, I wouldn't consider myself literate yet so perhaps with more time it'll looks less eye-crossy than it does now.

Well yes HKTs would be nice and I was also hoping Rust would get them, but let's face it, you don't really need them for 95% of real world applications and 99.99% of developers either don't understand them or misuse them. To push Rust as a mainstream language, virtual structs, stability, performance, good module management and "boring" real world APIs (e.g. sql, gui, web...) are much more important.

Personally I regret that Rust doesn't support currying. That would instantly improve the language's readability *a lot*.

[log0]

they're written in C++ because legacy. Even carmack thinks C++ is a complete fucking mess, but you know more than Carmack right?

And it's funny you mention C++ considering C++ _by standard_ has an ABI for garbage collection.
(http://www.stroustrup.com/C++11FAQ.html#gc-abi)

The only people who hate garbage collectors are people who associate garbage collection with java. Boehm repeatedly proved over the last 25 years how much better GCs are than any other form of memory management, yet he was completely ignored.
(www.hboehm.info/gc/myths.ps)

Like typical, C++ programmers are always stuck 30 years in the past and refuse to pick up a research paper and learn something. Still no surprise that most C++ programmers think new/delete is a noop, have no idea what a cascading destructor is, or why reference counting would be dog slow(especially with the required atomic semantics the standard imposes.) This is why Linus ranted about C++ - it had nothing to do with the language, but the people who use it.

The real nail in the coffin though?
Go look at every single C++ implementation on the computer language benchmarks game. Go ahead, I'll wait. Every single one that is memory intensive implements a primitive garbage collector.

And now that we're in the multicore era, garbage collection has become more important than ever.

Right... anyone using a language without GC is an idiot.

Please, tell us more! ROFL

[nadro]

they're written in C++ because legacy. Even carmack thinks C++ is a complete fucking mess, but you know more than Carmack right?

Carmack said that when he compared C++ to C, he didn't say that JAVA, C# or other lang with GC is better than C++. If you don't know how to write a fast code in C/C++ you're right that managed language is the best choice for peoples like you. C++ is much more complicated, but it's also much more powerfull than any other managed language.

[MacAndor]

they're written in C++ because legacy. Even carmack thinks C++ is a complete fucking mess, but you know more than Carmack right?

And it's funny you mention C++ considering C++ _by standard_ has an ABI for garbage collection.
(http://www.stroustrup.com/C++11FAQ.html#gc-abi)

The only people who hate garbage collectors are people who associate garbage collection with java. Boehm repeatedly proved over the last 25 years how much better GCs are than any other form of memory management, yet he was completely ignored.
(www.hboehm.info/gc/myths.ps)

Like typical, C++ programmers are always stuck 30 years in the past and refuse to pick up a research paper and learn something. Still no surprise that most C++ programmers think new/delete is a noop, have no idea what a cascading destructor is, or why reference counting would be dog slow(especially with the required atomic semantics the standard imposes.) This is why Linus ranted about C++ - it had nothing to do with the language, but the people who use it.

The real nail in the coffin though?
Go look at every single C++ implementation on the computer language benchmarks game. Go ahead, I'll wait. Every single one that is memory intensive implements a primitive garbage collector.

And now that we're in the multicore era, garbage collection has become more important than ever.

I'm sorry, but you clearly have very little knowledge about this topic. There some cases where GC can be very usefull, but with memory hungry applications where you have a very large number of allocations and deallocation, especially small ones, GC will usually not provide you a great solution. There are multiple memory management methods, and your app will perform the best when it uses the best for the situation.

For example:
If you have a large shared resource with multiple references to it, then reference counting is probably the best idea.
If you know exactly what the ownership of an object will be and want your app to have minimal memory footprint, then manual memory management is good.
If you have objects which you would like to free on demand (memory footprint will not be the best, but can delay computation required for freeing), then GC might be a good idea.

These are just some basic examples.

[ncopa]

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

GC is only fast if you have 6x needed memory available. If you have less than 4x needed memory you will have serious performance problems.

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Welcome to 2015, with tablets and smartphones.