Apache resigns from the Java Community Process executive committee [LWN.net]

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 21:51 UTC (Sat) by cmccabe (guest, #60281)
In reply to: Apache resigns from the Java Community Process executive committee by RogerOdle
Parent article: Apache resigns from the Java Community Process executive committee

> If Apache leaves Java behind then it should find or sponsor a patent free
> alternative language. An interpreted version of C++ would probably be
> least painful. I am not a C++ fan but what is closer to Java? Java has a
> huge memory foot print, I would welcome a reimagined alternative that is
> leaner, meaner, and faster.

Google Go?

It has a static type system, garbage collection, and a sane approach to concurrency.

to post comments

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 23:09 UTC (Sat) by kripkenstein (guest, #43281) [Link] (2 responses)

> Google Go?

> It has a static type system, garbage collection, and a sane approach to concurrency.

Go is interesting, but among the emerging languages in that area, I would suggest Rust. It has more emphasis on safety and given it's explicit mutability, should be more optimizable.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 3:44 UTC (Mon) by cmccabe (guest, #60281) [Link] (1 responses)

Rust sounds interesting, I'll have to check it out.

From everything I've read about Google Go, it really seems like a very practical language designed by people who have a huge amount of experience building actual systems. While reading through the examples, I had to smile, because they fixed a lot of my biggest gripes with C and C++. These are the language features that every practical programmer has stubbed his toe on, and hated ever after.

> It has more emphasis on safety and given it's explicit mutability, should
> be more optimizable

Speaking as someone who wrote a (toy) compiler once, the big problem in optimizing C/C++ is the "aliasing problem"-- the difficulty of determining if a location in memory has been modified since it was last fetched from memory.

From what I've read, the general idea in Go (and presumably Rust as well) is "don't communicate by sharing memory, share memory by communicating." If you're just passing objects by value on channels, I don't think that presents the same difficulties to the optimizer. Go does have pointers, of course, but I don't think that they get used nearly as much as in C/C++. Anyway, I'm still learning about this!

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 4:51 UTC (Mon) by kripkenstein (guest, #43281) [Link]

> Speaking as someone who wrote a (toy) compiler once, the big problem in optimizing C/C++ is the "aliasing problem"-- the difficulty of determining if a location in memory has been modified since it was last fetched from memory.

> From what I've read, the general idea in Go (and presumably Rust as well) is "don't communicate by sharing memory, share memory by communicating."

That's true, but the aliasing problem is only the big problem since a lot of other stuff isn't possible. Rust, for example, makes everything immutable by default, which opens up entirely new avenues for optimization that aren't available in C/C++, Java, Go, C#, etc. Whereas functional languages like Haskell make very good use of immutability in their optimizations.