Hacker News Reader

Comment by loudmax | Hacker News Reader

Go was originally pitched as a better C, but it seems to be finding a niche as a better Python or possibly a better Java. Go binaries have built-in GC, and Go will probably never reach C levels of performance. There is a lot to like about Go and it is working out very well for a lot of people, but it isn't appropriate for every situation.

If you want a better C, better to look into Rust: http://www.rust-lang.org/

View on HN

When Google will completely deprecate Java for Go on Android (could be a number of years, if ever), then Java should imminently become irrelevant (over a number of years, maybe a decade, or maybe it will never disappear completely, but the point is it will rapidly decline with new and existing developers).

Given Android's core team statements at Google IO 2014 about Java being the only official language, with no plans to improve the NDK beyond the existing support, I find it very hard to ever happen.

Unless Management forces the team to change their mind, that is.

> no plans to improve the NDK beyond the existing support

:| really? Got a link to that?

I really thought that they'd finally gotten over themselves and realized that lots of people want and use the NDK.

Yes,

https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566

- Java is the official language, that is what the team has invested into

- You can use the NDK for your favorite language, but beware that you are required to use JNI anyway for Android APIs

- Not possible to do any comment regarding Java 8 support.

- Only use Scala for business logic, no tooling support plans

I don't see any reason why Java usage would rapidly decline. The only thing that's likely to replace Java is Java 8, since everyone wants lambdas and there's a clear upgrade path. Even that's a big change and migration will take a while on Android.

It's unclear what the big missing feature is after lambdas. I think there will be little incentive for further change, so large companies will keep on running it.

> It's unclear what the big missing feature is after lambdas.

I agree. I think Java pretty much is what it is by now. As someone said, "For those who like this kind of thing, this is the kind of thing they like."

Java-the-language is pretty complete. (Even though Haskell people complain about the lack of a decent type system, and Lisp users complain about the verbose syntax, and C++ folks wish they had destructors.) Java-the-platform is in fine shape (the library is Java's unsung best selling point.)

Java-the-enterprise-bloatware-behemoth... well, it really needs to be shot in the head and the body incinerated, but it may actually do the jobs it's given to do about as well as anything that might replace it.

In terms of language features, lack of properties are the thing that is keeping me from using java. I would love to be able to have public variables, with the understanding that I could just convert them to properties later on if I need to. Instead, java conventions suggest that I always make a getter and setter for every single variable that I want to expose.

Some Java conventions are unfortunate. Setters aren't a great idea, actually. The Guava team recently open-sourced AutoValue as a more modern approach:

https://github.com/google/auto/tree/master/value

Fixing this stupid issue seems like such an obvious thing to do I can't imagine why it wasn't addressed ages ago. Having property notation would immediately get rid of 30% of the code in the codebase I currently work with, and that seems incredibly valuable.

> It's unclear what the big missing feature is after lambdas.

- Value types, GPGPU, replacing JNI with an improved JNR, reified generics, making Unsafe an official package, modularity, AOT compilation, replacing Hotspot by Graal...

Some things discussed here,

http://www.oracle.com/technetwork/java/javase/community/jlss...

http://openjdk.java.net/projects/panama/

http://openjdk.java.net/projects/sumatra/

http://openjdk.java.net/projects/valhalla/

https://wiki.openjdk.java.net/display/Graal/Publications+and...

Yes, there are many more features to come, but they don't look like they will be as important as lambdas (and default methods) for everyday coding.

Thanks for the links.

I think you underestimate you important some of those are.

Specially for people doing big data analysis in JVM languages or jumping out of Java to languages like C and C++ for the last performance increase.

The Java community is so large that these are important communities in themselves. But they're still subsets. Someone writing a portable Java library isn't going to want to call into native code or rely on specific hardware. Changing the language itself affects everyone.

If you bothered to follow the links, they imply language changes.

I did, actually. Value types are nice but annotation processing can do pretty well:

https://github.com/google/auto/tree/master/value

I'm honestly not seeing as big as lambdas (or generics in Java 5). If you think they really are that big, perhaps you could explain why?

I really hope Google deprecates Java on Android, because Android is even having problems with the standard library in Java SE 6, let alone Java 7 or 8. I rooted for them in the Oracle lawsuit, but they are holding back progress on the Java platform, as now library authors have to worry about the "Android problem" - every other JVM vendor is able to keep up the pace of updates, but not Google, because hey, ART / Dalvik is not a JVM, haven't you heard? So they should either get their shit together and keep up with the latest standard library, class format and bytecode in their toolchain or drop it.

Rust???The language which is more complicated than C++??? I have learned Rust almostly, but it is too enormous to replaced the C/C++. If rust can't simplify its concepts and syntax, this language will turn to failure again like D...

Rust is not more complicated than C++; you actually have to be thinking about the concepts (ownership and lifetimes) in C++ too, there's just no compiler help, so it seems like you don't.

(Well, you get some help: the compiler inserts (arbitrarily expensive) copies of your data for you.)

There are languages for those who can and those who can't...

The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars".

I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.

And the problem with "languages for those who can't" is the rise in off-shoring and erosion of working conditions for everyone involved, in both sides.

Not targeting any specific language, as I imagine all of us that went through this, have own hard earned war scars.

Suggesting that offshoring is a result of languages that are "too easy" is both insulting to those who work offshore, and totally inaccurate.

There's plenty of off-shore C++ programmers, and I doubt anyone would say that's an easy language.

And yes, offshored work is almost always of poor quality, but I actually think this is due to the inherent problem with paying people to write a product that they are not fully invested in. The same thing happens with contract work done in your own country. If the developers don't work for your company, they don't have your culture and they don't know your business. This is compounded by the communication inefficiencies from being outside your trusted mediums.

I have seen pay-for-code (contracting, offshore or not) fail many times. The only times I have seen it succeed is when the contractors are hired to work for the company directly, are taken inside its boundaries, and given full access to the company communication facilities and culture. But then, they may as well be regular employees.

None of this has anything to do with the language being used. As they say, you can write bad code in any language, and even the best code doesn't help if it's not doing the right thing.

In my experience most people won't even learn the ins and outs of the "for those who can't" languages. Worst yet, it's not about the language: most people won't grasp more important concepts that maybe "for those who can" languages force them to know upfront. And clearly while not knowing upfront some things is easier in the short term, it is a recipe for disaster as problems get more complex. So maybe it's about problems "for those who can" and "for those who can't".

People can write bad code in any language. I don't know that "forcing" people to know about it will do anything other than force people to make a possibly bad decision... such as simply marking all values as mutable.

The nice thing about go is that there's just a lot less to know. You can learn everything in a weekend. There just aren't many dark corners in the language.

> The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars".

> I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.

Many of those real projects can't use anything easier than Rust. Sure, using a GC for everything is easier, allowing memory safety violations is easier, and allowing data races is easier (for some definition of "easy"). But for many projects, like browser engines, kernels, games, etc. neither of these are an option. In other words, avoiding new concepts comes at a price. The concepts in Rust aren't there for no reason; they're there because they're solving real problems.

(Incidentally, I don't think that "simpler" is the right term; I think there's a lot of confusion between "simple" and "easy".)

Rust looks a lot more like a slightly more sane C++, given the proliferation of Someclass::Somethingelse

Rust doesn't have classes.

Reply on news.ycombinator.com