5 ms·

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

by loudmax 12y ago

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/ http://www.rust-lang.org/

jff 12y ago
Rust looks a lot more like a slightly more sane C++, given the proliferation of Someclass::Somethingelse
- pcwalton 12y ago
  Rust doesn't have classes.
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
higherpurpose 12y ago
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).
- pjmlp 12y ago
  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.
  - shadowmint 12y ago
    > 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.
    - pjmlp 12y ago
      Yes, https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566 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
- skybrian 12y ago
  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.
  - AnimalMuppet 12y ago
    > 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.
    - MereInterest 12y ago
      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.
      - skybrian 12y ago
        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 https://github.com/google/auto/tree/master/value
      - pivo 12y ago
- bad_user 12y ago
  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.
BinaryHole 12y ago
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...
- dbaupp 12y ago
  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.)
- pjmlp 12y ago
  There are languages for those who can and those who can't...
  - NateDad 12y ago
    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.
    - pcwalton 12y ago
      > 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".)

by loudmax 12y ago

jff 12y ago

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

pcwalton 12y ago
Rust doesn't have classes.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]

higherpurpose 12y ago

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

pjmlp 12y ago
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.
- shadowmint 12y ago
  > 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.
  - pjmlp 12y ago
    Yes, https://www.youtube.com/watch?v=K3meJyiYWFw#t=1566 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
skybrian 12y ago
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.
- AnimalMuppet 12y ago
  > 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.
  - MereInterest 12y ago
    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.
    - skybrian 12y ago
      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 https://github.com/google/auto/tree/master/value
    - pivo 12y ago
bad_user 12y ago
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.

BinaryHole 12y ago

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

dbaupp 12y ago
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.)
pjmlp 12y ago
There are languages for those who can and those who can't...
- NateDad 12y ago
  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.
  - pcwalton 12y ago
    > 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".)