5 ms·

I find it suspicious that Java or Scala didn't make the list. Java may not be sexy but it checks many boxes... And I suspect that Scala would have been a seriou

by ssadler 13y ago

I find it suspicious that Java or Scala didn't make the list. Java may not be sexy but it checks many boxes... And I suspect that Scala would have been a serious contender in brevity too.

mercurial 13y ago
C# was excluded for being too slow to start. JVM-based languages would not fare any better.
- spongle 13y ago
  I can't say I've had that problem myself. They are quite startup heavy but typical c# console apps start up on an ssd based system in ~150ms and 700ms on rust disks. If you're calling something thousands of times, fast process startup times are good. This isn't the model windows uses though which is the primary target of c#.
  - steveklabnik 13y ago
    In the tests, his OCaML implementation takes 7ms, and his Python one takes 64 or 109 ms. So even on your SSD, that's 50% to an order of magnitude too slow, just for startup.
    - spongle 13y ago
      Do you really notice that though?
      - steveklabnik 13y ago
        I cannot remember exactly, but in the discussions about page load times translating into revenue, 100ms was the number being tossed around, IIRC. I certainly notice any time I boot something up that requires the JVM, I refuse to use the CLR, so I can't tell you much about my own experience with that.
        spongle 13y ago
        Once it gets going though it screams. Not sure I want to trade the miniscule difference in startup time for that. As for page load times, this is silly. There is no startup time on a page at all. Possibly the first hit but there are warm start options for that in CLR at least which make this a complete non issue. To give you an idea, 98% of our page hits are under 80ms processing time and we have big, heavy pages (we're old school asp.net mostly).
        steveklabnik 13y ago
        I'm not talking about page load times. A server side app is a great use-case for something that has slow startup. I was just using that as a citation for perceptions on speed and how it can negatively affect experience. I'm talking about command-line applications, like the one in the article and in your first post. Then you get the startup every single time you run the command.
      - gfxmonk 13y ago
        For stuff like tab completion and for launching small command-line apps (think "grep", "sed", etc), absolutely. A penalty of hundreds of milliseconds for the _launcher_ alone can double (or more) the total execution time. I use zeroinstall a lot (I'm a contributor), and I turned off tab completion because the lag (of the python implementation) made me wonder if my terminal had locked up, which was far more distracting than trying to remember the available arguments. I have re-enabled it in the ocaml port, because now it's effectively instant.
- pjmlp 13y ago
  > C# was excluded for being too slow to start. This is only the case if the code is JITed. With ngen and mono-aot it can be compiled to native code directly. > JVM-based languages would not fare any better. It is all a matter of which JVM is used. Some of them offer AOT compilation and on disk cache of JITted code from previous runs, thus matching the startup time of native binaries.
alextingle 13y ago
If I need to install the JVM just to try your software, then it's going to remain untried - however many design patterns you've managed to cram into it.
- RivieraKid 13y ago
  Why, because the JVM is too big?
  - mercurial 13y ago
    Sounds more like trolling than participating to a rational discussion
    - alextingle 13y ago
      Java aficionados don't seem to realise just how obnoxious many of us find the JVM. If you live with it, and do your work with it, I guess you come to accept it as a fact of life - always there in the background. If literally nothing that you do uses it, then it's a massive extra dependency to add to a simple desktop app - a dependency that is often quite difficult to manage and keep updated.
      - mercurial 13y ago
        Re dependency: you probably have a point on Windows, but it's your choice to use an OS without a package manager to keep things up to date. I don't know about Mac but on Linux it is a non issue. That said it does not do well for desktop apps due to slow startup, high memory use and lack of native toolkit. It does much better as a server side runtime.
        jamespo 13y ago
        Although one of the best desktop RSS readers (RSSOwl) and two of the best IDEs (Eclipse & IntelliJ) are written in Java.
virtualwhys 13y ago
Agreed, pretty large omission given that C# was included. Not such a big fan of Java, but Scala seems to be a strong contender for Java.Next* , and is certainly a viable dynamic-to-static transition language given its terse syntax, deliciously rich collections library, and implicits support (for the MOP fans). * Twitter being able to withstand spikes of 140K+ tweets per second without lagtime is impressive to say the least.
mynameisme 13y ago
Yeah, it's a joke that Rust (which I think will be a great language, but all of the syntax hasn't even been decided yet) is being considered, when Java and friends are not. Really, this article is about "I want to rewrite my program in the newest, coolest language", not about which is the best tool for the job. And that's fine, but the author should present it that way.
- mjhoy 13y ago
  > newest, coolest language I'm sure you meant "newest and/or coolest", or "recently become coolest", but it's worth noting that Haskell is about as old as Python, and OCaml is not much younger.
- steveklabnik 13y ago
  The syntax of Rust is 99.9% (approx) decided. There was only one (or maybe two?) syntactic change in 0.8, and it was trivial to fix: https://github.com/steveklabnik/rust_for_rubyists/commit/a1889b https://github.com/steveklabnik/rust_for_rubyists/commit/a18... It's the standard library and such that are moving fast still.
- dmytrish 13y ago
  It's already been said that Java is a very heavy dependency for a simple desktop application. Rust compiles to native code, that's the advantage over Java.

by ssadler 13y ago

I find it suspicious that Java or Scala didn't make the list. Java may not be sexy but it checks many boxes... And I suspect that Scala would have been a serious contender in brevity too.

mercurial 13y ago

C# was excluded for being too slow to start. JVM-based languages would not fare any better.

spongle 13y ago
I can't say I've had that problem myself. They are quite startup heavy but typical c# console apps start up on an ssd based system in ~150ms and 700ms on rust disks. If you're calling something thousands of times, fast process startup times are good. This isn't the model windows uses though which is the primary target of c#.
- steveklabnik 13y ago
  In the tests, his OCaML implementation takes 7ms, and his Python one takes 64 or 109 ms. So even on your SSD, that's 50% to an order of magnitude too slow, just for startup.
  - spongle 13y ago
    Do you really notice that though?
    - steveklabnik 13y ago
      I cannot remember exactly, but in the discussions about page load times translating into revenue, 100ms was the number being tossed around, IIRC. I certainly notice any time I boot something up that requires the JVM, I refuse to use the CLR, so I can't tell you much about my own experience with that.
      - spongle 13y ago
        Once it gets going though it screams. Not sure I want to trade the miniscule difference in startup time for that. As for page load times, this is silly. There is no startup time on a page at all. Possibly the first hit but there are warm start options for that in CLR at least which make this a complete non issue. To give you an idea, 98% of our page hits are under 80ms processing time and we have big, heavy pages (we're old school asp.net mostly).
        steveklabnik 13y ago
        I'm not talking about page load times. A server side app is a great use-case for something that has slow startup. I was just using that as a citation for perceptions on speed and how it can negatively affect experience. I'm talking about command-line applications, like the one in the article and in your first post. Then you get the startup every single time you run the command.
    - gfxmonk 13y ago
      For stuff like tab completion and for launching small command-line apps (think "grep", "sed", etc), absolutely. A penalty of hundreds of milliseconds for the _launcher_ alone can double (or more) the total execution time. I use zeroinstall a lot (I'm a contributor), and I turned off tab completion because the lag (of the python implementation) made me wonder if my terminal had locked up, which was far more distracting than trying to remember the available arguments. I have re-enabled it in the ocaml port, because now it's effectively instant.
pjmlp 13y ago
> C# was excluded for being too slow to start. This is only the case if the code is JITed. With ngen and mono-aot it can be compiled to native code directly. > JVM-based languages would not fare any better. It is all a matter of which JVM is used. Some of them offer AOT compilation and on disk cache of JITted code from previous runs, thus matching the startup time of native binaries.

alextingle 13y ago

If I need to install the JVM just to try your software, then it's going to remain untried - however many design patterns you've managed to cram into it.

RivieraKid 13y ago
Why, because the JVM is too big?
- mercurial 13y ago
  Sounds more like trolling than participating to a rational discussion
  - alextingle 13y ago
    Java aficionados don't seem to realise just how obnoxious many of us find the JVM. If you live with it, and do your work with it, I guess you come to accept it as a fact of life - always there in the background. If literally nothing that you do uses it, then it's a massive extra dependency to add to a simple desktop app - a dependency that is often quite difficult to manage and keep updated.
    - mercurial 13y ago
      Re dependency: you probably have a point on Windows, but it's your choice to use an OS without a package manager to keep things up to date. I don't know about Mac but on Linux it is a non issue. That said it does not do well for desktop apps due to slow startup, high memory use and lack of native toolkit. It does much better as a server side runtime.
      - jamespo 13y ago
        Although one of the best desktop RSS readers (RSSOwl) and two of the best IDEs (Eclipse & IntelliJ) are written in Java.

virtualwhys 13y ago

Agreed, pretty large omission given that C# was included. Not such a big fan of Java, but Scala seems to be a strong contender for Java.Next* , and is certainly a viable dynamic-to-static transition language given its terse syntax, deliciously rich collections library, and implicits support (for the MOP fans). * Twitter being able to withstand spikes of 140K+ tweets per second without lagtime is impressive to say the least.

mynameisme 13y ago

Yeah, it's a joke that Rust (which I think will be a great language, but all of the syntax hasn't even been decided yet) is being considered, when Java and friends are not. Really, this article is about "I want to rewrite my program in the newest, coolest language", not about which is the best tool for the job. And that's fine, but the author should present it that way.

mjhoy 13y ago
> newest, coolest language I'm sure you meant "newest and/or coolest", or "recently become coolest", but it's worth noting that Haskell is about as old as Python, and OCaml is not much younger.
steveklabnik 13y ago
The syntax of Rust is 99.9% (approx) decided. There was only one (or maybe two?) syntactic change in 0.8, and it was trivial to fix: https://github.com/steveklabnik/rust_for_rubyists/commit/a1889b https://github.com/steveklabnik/rust_for_rubyists/commit/a18... It's the standard library and such that are moving fast still.
dmytrish 13y ago
It's already been said that Java is a very heavy dependency for a simple desktop application. Rust compiles to native code, that's the advantage over Java.