Hacker News Reader

Comment by styfle | Hacker News Reader

I'm curious, it looks like the screenshot shows the author is using a Mac. But Mac OS hasn't shipped with Java in several years. So why Java? Is it simply familiarity, or are there other reasons?

View on HN

A mix of both, actually. I've been using uTorrent for years until 2016, when I've decided to switch to some new OS X release. After installing the system update, the old, ad-free version of uTorrent has stopped working. The new version seemed a bloated mess to me, so I've tried a few other clients, but was left unsatisfied. Finally, in despair I've decided to write my own client with simplistic command-line UI, with emphasis on streaming movies. The sheer amount of new information in BEPs was enough for me to decide to take the easiest route and use the language, that I'm most familiar with.

Thanks for the reply (it seems my question caused an uproar here, oops).

I definitely like the idea. My question was more aimed to understand if Java has some desirable features for writing a torrent client maybe as part of the SDK or other 3rd party libs. I didn't even look at your source code yet :P

Java stood out to me because I don't think I've seen other CLIs written in Java.

Turns out that the gif was kind of misleading, it's just a demo application for the library. I'm trying to use as little 3rd party dependencies as possible (core only uses slf4j and Guice)

This is a library for development. If you wanted to ship a client based on this, you could do that and package it with the Java runtime.

Most OS's don't ship with a C compiler, go, python 3, rust, arc, etc, what does that have to do with anything?

Technically _most_ ship with a C compiler and a python compiler since pretty well every linux distribution & bsd distribution has those. But that really doesn't have anything to do with which language you should use.

Technically, that's not true.

You're conflating developer tools with a language runtime. Every popular OS ships with everything necessary to run a C, Go, or Rust binary. Python 3 and Java both require a separate runtime to be installed, but I will say that every Java CLI I've used has had terrible startup performance.

I'm using Lanterna, a Java library for creating text-based terminal GUIs (https://github.com/mabe02/lanterna), and the startup is 1-2 seconds. Can't recommend it enough

Good to know, but 1-2 seconds is still very slow compared to a native app. I have an 8MB Go CLI application that can startup and print its help in .05 seconds, and even that is probably slow compared to a C or Rust equivalent.

Well, printing stuff is easy. Just tried:

  $ time java HelloWorld 
  Hello, World

  real	0m0.088s
  user	0m0.088s
  sys	0m0.016s

That's presumably not loading any libraries at all though - the time to being interactive (or just doing something useful) will get worse as more bytecode has to be decompressed and loaded.

> That's presumably not loading any libraries at all though

Sure it is loading libraries, everything that System.out.println() depends on.

Any savy Java developer knows how to AOT compile to native code, if that really matters.

There are plenty of JDKs that support it, and even Oracle is finally adding support for it with Java 9, initially only for Linux x64.

By Java 10 timeframe no one that only knows about OpenJDK and not the several other JDKs can state that Java starts slow vs C, because both will be AOT compiled to native code, loading native .so files.

Good point, but I wonder what size will the final binaries have, given that bytecode inflates significantly when translated to the machine code (there was a good discussion on HN recently about app sizes)

In any case smaller than Electron apps.

Electron apps aren't really my standard for "reasonably sized CLI applications"...

From what I've seen Java/JVM AOT won't produce binary executables but shared libraries that will be loaded on startup by the JVM. When I first read about Java AOT-compilation I expected it to produce real executables that's why I think this is important to mention. But please correct me if I am wrong. So if this is true even with AOT compilation you still need the JVM as dependency (although I think you can get a minimal JVM in under 10MB). It also seems that the AOT compiled code needs to be recompiled on Java updates. Although I quite like Java and the JVM, I still wouldn't choose Java for writing simple command line tools.

Nevertheless it is quite useful for improving startup for tools like Gradle or server applications. But sure, I also don't expect Java startup performance to be a problem in the mid- to long-run.

Correct, but that is no different than having to ship glibc.so or MSVCRT.dll alongside your application, specially if you want to be certain which version gets used.

This is only relevant to Oracle's implementation though.

Other JDKs do support static linking, as long as you restrain yourself from features that could require dynamic compilation.

There was a talk at JVM Languages Summit about the current state of AOT compilation regarding Java 10.

https://www.youtube.com/watch?v=n5DCg6M2MDM&index=11&list=PL...

I would rather ship glibc (8MB) or musl (.5MB) than the JVM (100s of MBs?), but it's not necessary given that nearly every target already has a libc. Also, Go programs don't depend on libc, and C and Rust can probably statically link against some libc in a pinch.

Rust can use musl, yes.

opening and quiting vim for a file of 2500 lines of C++ (so with all the plugins and stuff) takes 0.030seconds. I don't see how you can be satisfied with 2 seconds startup for a terminal application

I completely agree that for a interactive tool like text editor startup time is crucial. But in my case being a bit on the slow side is probably fine, because the UI is for informational purposes only, and VLC takes around 5-10 seconds anyways to startup and begin playing the file, that is being downloaded.

Well the torrent download will take a lot more than 2 seconds so that time is totally amortized.

Besides this comparison looks like a total bikeshedding unless you plan on downloading torrents with vim.

By the way the project looks fantastic. I'll be giving it a try.

The alternative for just command line torrent on a *nix is aria2 [0]. Works exactly as advertised.

[0]: https://sourceforge.net/projects/aria2/

Well there is a truth to that. However this might be something symptomatic. As power consumption is getting more and more interesting nowadays, having a minimal impact on system resources overall might still be a sensible goal.

Some apps just include JRE into the app package (+100MB), and just use it if it's not provided by OS.

But then you need to provide different app packages for different OSes.

C, Go, and Rust would require different app packages for different OSes--that's not a problem. The problem is bundling a 100MB runtime for a CLI.

people bundle a browser for a tiny icon in your taskbar so 100MB for a runtime in a CLI isn't gonna prevent people from using it

Java 9 has a linker, you have remove everything that is not needed and have a application specific runtime.

On top of that, if lucky enough to be on an Linux x64 system, you can AOT compile to native code.

I'm not conflating them and it's still a silly way to frame the question. If you want to ask someone why they wrote something in language X, just ask them that.

You're being pedantic; natural language is contextual for better or worse. Anyway, asking "Why did you use Java", is likely to be interpreted as a slight against the language and thus be downvoted (indeed, his politely phrased question was even downvoted when I saw it!).

Reply on news.ycombinator.com