Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has.

I was pretty much exclusively a Java programmer for the first decade and a half of my career, before moving to Node and TypeScript. I don't think I could ever go back at the point. Most importantly, this is my first time where the entire code base (front end and back end) is in the same language and toolchain, and I think it is the single most important thing I've seen in years for improved team productivity. The ease with which engineers can go between front end and backend is an incredible boon that shouldn't be underestimated.

View on HN

I use typescript a lot. It's way better than JS but the type erasure problem is far worse than Java. Essentially all types are erased, so bugs where typings don't match what you expect and everything blows up are common. This isn't possible in Java because it's statically typed at runtime.

JS also uses several times more memory, is slower, and has a terrible (non existing) threading model. Yes you can run multiple instance of node or whatever, but sharing objects between them requires message passing which is orders of magnitude slower.

Until JS has a good threading model I'm never using it for backend. It's too expensive to use a bunch of single core machines to make up for it.

All of our devs use Typescript and Java daily for front and backend, the only overhead is making sure objects were passing around match on both ends. The only advantage to using the same language for everything is hiring inexperienced devs that don't know both IMO

> bugs where typings don't match what you expect and everything blows up are common

> the only overhead is making sure objects were passing around match on both ends

Seem like is it a big deal based on the first sentence.

I've never been convinced of the single language argument. Sharing code between frontend and backend sounds good but as in practice there's little overlap... models have subtle differences, there's extra logic server side... All in all it's not very practical.

To me the most awesome part of a fully TS project is that you can use the same interfaces everywhere. If you take the time to define them for any input / output, everything is pretty much guaranteed to be sound.

> the type erasure problem is far worse than Java

Check out RunTypes [1], amazing to guard any incoming data.

1. https://github.com/pelotom/runtypes

This library looks great! For cross language comms you can also use gRPC to avoid writing objects for both sides. We're not using it company wide but so far it works as advertised, minus the annoyance of having to use gRPC proxy to web endpoints

It's more about the ability to share programmers than the literally code, in my opinion.

Sharing same stack is more important when team / project is small.

> Seem like is it a big deal based on the first sentence.

There is big difference between "this API can blow" and "it can blow everywhere".

If erasure is bothering you so much, it means you are heavily relying on reflection / runtime type information retrieving.

Which means you are second guessing the compiler, which provided you with such great guarantees.

You should do your best to minimize this kind of code.

> has a terrible (non existing) threading model. Yes you can run multiple instance of node or whatever, but sharing objects between them requires message passing

Don’t Node.js worker threads solve exactly this?

> Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has.

It completely succeeded in that!

Java (well JVM) developers today can

- Write code on any of Windows/Linux/macOS

- Deploy that code on any of Windows/Linux/macOS

Not a lot of language/platforms can claim to this amount of success, let alone with such an amazing set of tools and ecosystem.

C# (largely inspired by Java) run on even more platforms, because there is compiler/runtimes for mobile platform. It’s also the second biggest "entreprise" language, which fix a lot of Java pain points.

Technically, maybe.

In practice, how many developers write C# on a non Windows platform? I'd say a very, very tiny minority.

On the other hand, Java is being written on all platforms and being deployed on many as well.

> In practice, how many developers write C# on a non Windows platform? I'd say a very, very tiny minority.

Plenty do - think of deploying c# web services on Linux servers / containers.

GP said "write", not "deploy".

I write C# on Linux and I am basically the only person I know who does that.

Microsoft is pushing hard with it's .Net Core offerings and that effort is designed to make C# a more universal language.

Whether that effort pays off, only time will tell.

Actually C# runs on less platforms than Java, because it doesn't run on embedded devices, M2M, bluray players, military deployments, mainframes, Xerox and Ricoh copiers, SIM and chip based credit cards, and plenty of others devices, like even having a mobile OS based on an Java dialect.

There are for Java too. You can - obviously - run Java on Android, using either the native runtime or, less obviously, OpenJDK with JavaFX.

You can also compile JavaFX apps AOT for iOS! It's called Gluon Substrate, check it out.

Java really does run on a lot of stuff, even if OpenJDK itself may not.

>Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard

That's what people say, but I don't see that.

The same Java code is extremely portable, from Windows, MacOS, Linux, etc, on both the server, cli, and GUI app side.

It's just that its UI libs have historically been over-engineered shit like Swing.

I'm not saying Java code isn't very portable, and there are some notable exceptions (the IntelliJ/JetBrains products always are first to come to mind) of successful cross platform Java client apps.

But much of the original late 90s hype about Java was its cross platform nature, especially in the browser, but Java applets and other in-browser Java technologies were never popular (consider GMail and other GWT apps were written in Java but compiled down to Javascript).

Java owes 90%+ of its ubiquity and longevity to its success on the server.

Ironically if Java developers had used the built in DOM APIs instead of the Applet canvas crap, we probably would have had great SPAs a lot earlier.

True, and if gui libraries stuck with common widgets that were cross platform, we would already have a long term native cross platform GUI toolkit.

> DOM APIs instead of the Applet canvas crap

i wonder if it was because at the time, the different DOM api in each browser was so immature, that to unify it into a single api is too big a task. The applet+blackbox region for rendering is the easiest MVP. Of course, with hindsight, that turned out to be a piece of crap.

Isn’t that jquery? Seems surmounted by a few very talented people

The successful cross platform apps usually are in a space where having a non-native GUI is accepted.

They were pretty popular actually. The problem was that browser makers started trying to kill applets off very early. Netscape supported them, but Microsoft / Sun had a huge falling out and they ended up pushing ActiveX very hard as a replacement. The dominance of IE assured that ActiveX replaced Java applets for a while, and then MS fell out of love with ActiveX too, so HTML+JS was all that was left.

Applets were very much a victim of various power struggles within the browser industry, combined with Sun's general lack of competence on the desktop - for instance, their online upgrade engines have always sucked. Though in fairness, nobody got that right until Chrome.

> Java was the original "write once, run anywhere" language

That crown properly belongs to the UCSD P-System, which was the Java of the 1980's. It was the same idea as Java - compilation to a bytecode which an interpreter ran. It failed because the interpreter performance penalty was too high.

Java also started out as an interpreter, which made it too slow. Steve Russell of Symantec invented a JIT for it, and like the lumbering Allison-engined P-51 getting a supercharged Merlin, it brought Java to life.

I don't know about that.

I coded in UCSD-P quite a bit (and played a few games written in it, Wizardry on the Apple 2 anyone?).

But UCSD-Pascal never reached a tiny fraction of the audience that Turbo Pascal did.

Turbo Pascal certainly had more users, but it was never "run anywhere".

Not sure what you mean by that.

Are you talking about the host OS and the fact that Turbo Pascal was Windows only, as opposed to Pascal UCSD which was a VM?

I meant that the UCSD system ran on many diverse platforms, and TP did not.

I also wonder how much the difficulty of sharing files between different systems due to different disk formats played a role in its failure.

You could run p-system on a lot of machines - Apple II, IBM PC, TI-99/4A, PDP11... but how would you (and why would you) distribute your code across machines with such different storage media?

Oh, people found ways to transfer files. BBSs were one way, the Kermit program another, NNTP newsgroups, etc.

I transferred files from my PDP-11 (8" floppies) to my PC (5.25" floppies) using Kermit.

Maybe it was more of a problem of not being able to think of a use case for running a pCode program meant for a 512K PDP11 on a 48K Apple II+. A bit ahead of its time.

It was definitely ahead of its time, but I and others tried to use it. It was just too slow, and you couldn't make competitive products with it.

Though it’s technically _not_ Java, Kotlin has been a breath of fresh air for us in the last year. We tried it on a few smaller projects and it took off like wildfire throughout our team.

I write a lot of JavaScript (typescript included) and I have found it to be a very nice combination of things I like from both Java/JavaScript.

Admittedly I have been primarily writing Java for the last 15 years and consider JavaScript a second language for me, you may find Kotlin gives you a good reason to come back to the JVM (where it makes sense to of course).

It succeeded. Early 2000's I converted my company's "document server" from _heavily_ ifdef'd C to Java. It ran on Windows, Linux, AIX, Solaris, HP-UX, and Linux on IBM mainframes. Having EBCDIC as the default encoding for strings really made you pay attention to encoding in and out of Unicode.

How come?

I do it daily during most of those 25 years, developing on Windows, deploying across multiple flavours of UNIX.

"Write Once,Run Anywhere" (WORA) is not the same thing as using the same language on the frontend and backend. Java has quite good success with WORA as explained by hota_mazi in the sibling comment. Aplets failing to catch on does not take anything from WORA success story of Java.

Is there any major player or project doing backends in JS?

As far as I know, all major players care about performance and scalability, which JS cannot afford on a single-threaded runtimes.

Uber: https://eng.uber.com/uber-tech-stack-part-two/

There's a lot of Java in that article: Hive, Hadoop, Spark, Elasticsearch, Kafka, Cassandra...

> The ease with which engineers can go between front end and backend is an incredible boon that shouldn't be underestimated.

In my experience, the engineers that can do that and still produce solid code are very, very rare.

Reply on news.ycombinator.com