5 ms·

The amount of contortions you need to do with your "adult" language arguably negates a lot of advantages of using it. Just because you don't have pointers doesn

The amount of contortions you need to do with your "adult" language arguably negates a lot of advantages of using it. Just because you don't have pointers doesn't mean that all bugs are now eliminated. Take Android for instance, getting solid performance out of the JVM there is a huge bear because the language is just not suited to low latency operations. I won't claim that C is a perfect language but I hate it when I see people throwing around that you're committing some sin for each line of C code you write. If you want cache friendly operations and predictable performance you're not going to find it in any JVM or language that has a GC.

chollida1 10y ago
> If you want cache friendly operations and predictable performance you're not going to find it in any JVM or language that has a GC. I don't know you and it's always dangerous to argue with people on HN due to who might be reading but I'd very strongly disagree with your above quote. Predictable performance can be obtained on a very low latency, I've seen it:) Cache friendly can be tougher and I won't argue the point as I think it will end up being a "no true Scotsman" argument where I claim Java can be cache efficient and you counter that C can do better so therefor Java isn't truly cache efficient
- vvanders 10y ago
  That's true, I'm very familiar with tuning Java to be cache aware. I've played around with FlatBuffers[1] in my spare time to good effect which seems to be the only sane way of doing cache aware layout in Java. That said the amount of restrictions you have makes it really painful(needing to use pre-allocated wrappers if you want to read more than intrinsic types, not being able to grow/shrink anything). There's sun.misc.Unsafe, but that isn't available on every JVM implementation. A GC is going to by nature introduce pauses if since at some point it's going to need to do work on the memory you hold. There's a set of tunable tradeoffs but it will impact latency. I guess my meta point is if throughput and latency are paramount to you then you should really consider a language suited for it. For me today that would be Rust or C++ depending on how risk-adverse the organization you're working with is. [1] https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/
  - desdiv 10y ago
    >There's sun.misc.Unsafe, but that isn't available on every JVM implementation. There's also talk about the possible removal of sun.misc.Unsafe in Java 9¹. ¹ http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disaster-in-the-making/ http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disast...
    - stickfigure 10y ago
      Jeeezus... I've been writing Java since before many HNers were born, and somehow I never noticed that class. The Oracle people are right about this one. Rip it out and sterilize the wound with fire.
    - needusername 10y ago
      Oracle backpedaled from that pretty quickly.
  - eggy 10y ago
    Personally, I am looking to Rust or Pony, but both are too young, and the tooling is quite there, not to mention recruitment potential. Erlang/LFE/Elixir are great for certain distributed HFT tasks, but not the core for speed and latency. The JVM is in HFT in because of sheer inertia; it has been worked on for so many years to shoehorn it in, and some smart people have made it work. The tooling is mature, and there are alternative syntaxes close to it like Kotlin that remove a lot of the noise for code review and maintenance. The JVM is the reason I stayed away from Clojure, even though I like Lisp/Scheme syntax and the semantics. Where is Clojure-clr nowadays?
  - Gibbon1 10y ago
    There was an article on HN talking about the improvements go has made to their gc over the last few releases. Umm... here https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7#.qssombjyp https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06... It sort of looks like language developers are finally getting the point that while you can easily deal with a throughput problem by just throwing faster processors, more processors, and or memory at at it, working around long gc pauses is just pain all around.
PaulHoule 10y ago
I just think the people who make Android are high on drugs or something. For instance the subjective experience of using Android is that you can never close any app that you've opened other than by uninstalling it. Even after you turn your machine off and turn it back on you still see windows for every f--king app. Then they run a bunch of articles about what an idiot you are if you try to close these because it won't save your phone's battery. Well I admit I do have some cognitive limitations and it is --hard-- to scroll through 30 apps just to switch from (say) the web browser to the PDF viewer, but I guess Google thinks it is great this way because you always have a Google Plus window open. Then there are all the articles about the fancy power management they are going to have someday that doesn't face up to the fact that an android device may or may not charge if you plug it into a charger, might turn itself off when it is running, and that the most reliable way to turn it on is to do a hard reset... And this isn't any old piece of junk, this is a nexus device.
- vvanders 10y ago
  Those are just screenshots captured from the app you're seeing. If you switch to any OpenGL based app you'll see it restart. FWIW Force Stop from the settings->app section will stop an app unless it's forced to be sticky because another service depends on it.
  - BinaryIdiot 10y ago
    > Those are just screenshots captured from the app you're seeing. That's not entirely accurate. Many of the apps can and will stay in memory (it doesn't suspend all of them). Not that that's necessarily a bad thing.
    - vvanders 10y ago
      If you want to get really pedantic those are screenshots in the app drawer that are swapped with an application's surface in SurfaceFlinger just as it comes fullscreen. But yeah, Android doesn't kill apps outright when you switch away, that would be a pretty poor experience to restart each time you opened a link in Twitter and came back from it for instance.
joncrocks 10y ago
Take Android for instance Android <> the JVM. There was a recent, fairly well publicised legal battle around this fact.

chollida1 10y ago

> If you want cache friendly operations and predictable performance you're not going to find it in any JVM or language that has a GC. I don't know you and it's always dangerous to argue with people on HN due to who might be reading but I'd very strongly disagree with your above quote. Predictable performance can be obtained on a very low latency, I've seen it:) Cache friendly can be tougher and I won't argue the point as I think it will end up being a "no true Scotsman" argument where I claim Java can be cache efficient and you counter that C can do better so therefor Java isn't truly cache efficient

vvanders 10y ago
That's true, I'm very familiar with tuning Java to be cache aware. I've played around with FlatBuffers[1] in my spare time to good effect which seems to be the only sane way of doing cache aware layout in Java. That said the amount of restrictions you have makes it really painful(needing to use pre-allocated wrappers if you want to read more than intrinsic types, not being able to grow/shrink anything). There's sun.misc.Unsafe, but that isn't available on every JVM implementation. A GC is going to by nature introduce pauses if since at some point it's going to need to do work on the memory you hold. There's a set of tunable tradeoffs but it will impact latency. I guess my meta point is if throughput and latency are paramount to you then you should really consider a language suited for it. For me today that would be Rust or C++ depending on how risk-adverse the organization you're working with is. [1] https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/
- desdiv 10y ago
  >There's sun.misc.Unsafe, but that isn't available on every JVM implementation. There's also talk about the possible removal of sun.misc.Unsafe in Java 9¹. ¹ http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disaster-in-the-making/ http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disast...
  - stickfigure 10y ago
    Jeeezus... I've been writing Java since before many HNers were born, and somehow I never noticed that class. The Oracle people are right about this one. Rip it out and sterilize the wound with fire.
  - needusername 10y ago
    Oracle backpedaled from that pretty quickly.
- eggy 10y ago
  Personally, I am looking to Rust or Pony, but both are too young, and the tooling is quite there, not to mention recruitment potential. Erlang/LFE/Elixir are great for certain distributed HFT tasks, but not the core for speed and latency. The JVM is in HFT in because of sheer inertia; it has been worked on for so many years to shoehorn it in, and some smart people have made it work. The tooling is mature, and there are alternative syntaxes close to it like Kotlin that remove a lot of the noise for code review and maintenance. The JVM is the reason I stayed away from Clojure, even though I like Lisp/Scheme syntax and the semantics. Where is Clojure-clr nowadays?
- Gibbon1 10y ago
  There was an article on HN talking about the improvements go has made to their gc over the last few releases. Umm... here https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7#.qssombjyp https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06... It sort of looks like language developers are finally getting the point that while you can easily deal with a throughput problem by just throwing faster processors, more processors, and or memory at at it, working around long gc pauses is just pain all around.

PaulHoule 10y ago

I just think the people who make Android are high on drugs or something. For instance the subjective experience of using Android is that you can never close any app that you've opened other than by uninstalling it. Even after you turn your machine off and turn it back on you still see windows for every f--king app. Then they run a bunch of articles about what an idiot you are if you try to close these because it won't save your phone's battery. Well I admit I do have some cognitive limitations and it is --hard-- to scroll through 30 apps just to switch from (say) the web browser to the PDF viewer, but I guess Google thinks it is great this way because you always have a Google Plus window open. Then there are all the articles about the fancy power management they are going to have someday that doesn't face up to the fact that an android device may or may not charge if you plug it into a charger, might turn itself off when it is running, and that the most reliable way to turn it on is to do a hard reset... And this isn't any old piece of junk, this is a nexus device.

vvanders 10y ago
Those are just screenshots captured from the app you're seeing. If you switch to any OpenGL based app you'll see it restart. FWIW Force Stop from the settings->app section will stop an app unless it's forced to be sticky because another service depends on it.
- BinaryIdiot 10y ago
  > Those are just screenshots captured from the app you're seeing. That's not entirely accurate. Many of the apps can and will stay in memory (it doesn't suspend all of them). Not that that's necessarily a bad thing.
  - vvanders 10y ago
    If you want to get really pedantic those are screenshots in the app drawer that are swapped with an application's surface in SurfaceFlinger just as it comes fullscreen. But yeah, Android doesn't kill apps outright when you switch away, that would be a pretty poor experience to restart each time you opened a link in Twitter and came back from it for instance.

joncrocks 10y ago

Take Android for instance Android <> the JVM. There was a recent, fairly well publicised legal battle around this fact.