Hacker News Reader

> it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger.

You underestimate the amount of COBOL code that is still out there running our daily lives:

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...

I've done work for a fair number of banks and insurance companies, and my anecdotal impression is that there is always a java system siphoning data from the cobol systems...

Both stay around for the same reason: backwards compatability and a stable api+abi.

If you find and old Java system it's often trivial to do changes and recompile. Even a few years old C program is often problematic due to changes in the OS or libraries.

I have no idea if it's possible to compile a couple of years old js code...

Js isn't usually compiled at all! And old sites using old js generally still work in modern browsers.

... but modern js almost always have a build step.

But yeah, the fair deal of time I have spent on fixing old web pages was more related to fixing the html and CSS and just minor problems related to js.

That is very true - there is a lot of cobol out there.

Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2F...

And .NET as well.

http://www.coss-solutions.nl/index.php/2013-11-18-13-59-23/n...

It can even target Azure deployments!

Wouldn't the JVM's warmup time make it untenable for most places COBOL is used?

What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.

Maybe I can better explain with an example, but it comes from the only time I've worked with Cobol professionally, and I have avoided it since. My experience is limited, and might not be the norm.

It was a bank, and transactions were processed through a pipeline.

Part of that pipeline was handing off transaction data from an always-active system, but then into many, many short-lived Cobol processes, and then into another always-active system.

The Cobol processes basically munged, pulled and pushed to database/s, and then killed itself.

In this case, I could see warm-up time being a huge issue, though a switch into another language might bring a change in architecture to threading and the like which would remove that problem, but I can't see a bank changing architectures easily.

From my limited exposure, several financial companies connected with the bank had similar processes. Something like Java or C running a server, Cobol when numbers need serious crunching, and then back into another server application.

(Incidentally, both the server processes were Fortran, if that's interesting to anybody).

I think I understand what you're saying but cobol runs in an environment that is optimised for cobol, and I'd expect where this were to be java you would have a similar arrangement in place. For a trivial example of what I'm talking about check out nailgun [0]

[0] http://www.martiansoftware.com/nailgun/

Yes, a change to Java would require a large architecture change. Notably from mainframes to something a little bit more familiar to most people.

But when Cobol works, is blisteringly fast, and they can afford to hire and train people to work with it, I don't see the benefits of Java, at all. Especially not at the enormous costs of a major architecture re-work in systems that are live 24/7, and downtime is counted in milliseconds.

Having to work around the JVM is just icing on the cake.

would require a large architecture change

No, it wouldn't. Java is already used on a broad scale for this kind of thing. The ways in which it needs to be tuned for this kind of thing are in widespread use.

While Kotlin may be fun to write in and have the potential to become mainstream in the industry, I think you underestimate how much Java is used outside of hobbyist and startup circles like HN.

The thing is that Java -> Kotlin is almost entirely frictionless while also adding a lot of value. I can see people preferring Kotlin to Java as a teaching tool if Kotlin gets a little more traction, because of its relative simplicity. (I say this as a long time Java programmer, now trying out Kotlin and enjoying it)

Kotlin can never replace Java as long as the JVM is relevant.

This is like trying to replace C on UNIX, C# on .NET, Erlang on BEAM, or JavaScript on the browser.

Kotlin is essentially Java with some sugar sprinkled on top. That's its strength: the semantics & the concepts are the same.

I also never said Kotlin will replace Java, but that it will gradually grow to the detriment of Java, which is still here to stay.

I don't believe Kotlin will get much strong outside Android.

In all these years of alternative languages customers still don't allow us to use anything other than plain Java.

I have to wonder what the distribution is of people using java is. You seem to be a freelancer or independent agency for contract. I can easily see a bunch of big corps moving from Java to Kotlin though. Especially with an in via android, why not using Kotlin across the board. It will definitely be a gradual thing, if it will be thing. Kotlin just seems to be a very, very pragmatic enhanced version of Java.

Yep, enterprise consulting for Fortune-500, DAX level companies.

I work for a Fortune 500 company and we've switched to Kotlin from Java a little over a year ago with great results. My perception might be a bit skewed in the opposite direction as yours, but I think Kotlin will catch on. The article really hit the nail on the head when it mentioned Kotlin's interop with Java being its killer feature.

Your customers can tell what programming language you're using?

Yes, it is usually defined in the project contract, and we usually have to use customer configured environments, including source code control systems and CI infrastructure.

Also there are acceptance reviews from customer teams.

>In all these years of alternative languages customers still don't allow us to use anything other than plain Java.

That's because all those years those alternative languages never got much traction except Scale.

Kotlin is already poised to reach hundreds of thousands through Android support.

With Kotlin it's possible to write a complete application without using a single class or even OO. I'd call that more than syntactic sugar.

But Erlang now has strong competition on BEAM. Sure, none of those languages will be replaced, but surely some will lose market share to up and coming languages.

Platform languages always get access to everything from the eco-system, while enjoying better tooling.

External languages always have to try to fit into the platform.

This is the main reason why as language geek, I always try to learn new languages and paradigms, but when it comes to production code I only use the platform languages.

No FFI headaches, no lack of tooling, first party support in the SDK, no messing around with alternative build systems, no issues hiring team members and so forth.

I agree on the first 3... and most probably that's why I very strongly disagree on the last part.

The way the languages "match" the environment in the first 3 examples is almost reciprocal to the way the language is a mismatch in the last one... "it just happened".

Also seeing those first 3 environments even listed with the last one somehow does not seem fitting... but is still a nice pictures of current "Zeitgeist" of computing and software development, imo.

Still, it is the only native option and remains to be seen how much WebAssembly will change that.

Although I think if WebAssembly becomes a success, we will get the revenge of plugins.

But it could play the same role for Java that C++ played to C.

what about

rust on unix (redoxos)

f# on .net (.net is supposed to support multiple languages)

elixir has successfully replaced erlang on BEAM for a lot of people.

webassembly is hot and you can always use js as a compiler target for some other language

Java will slowly absorb useful features from Kotlin until it's no longer necessary.

And eventually the C++ification of Java will scare away new developers who don't have years of context that explains the organic growth.

Languages encumbered by backwards compatability and bolt on new features will eventually collapse under their own weight.

Others decide to break compatibility, wait > 10 years and there are still debates which version to use (Python), or fade away (Perl 6).

Ah yes, it will die just like C++. Backwards compatibility focus languages are the only ones that live long enough to be old and encumbered.

Oh no, I'm not implying that Java or C++ will ever die, they'll probably outlive me. I'm only saying that by bolting on new features Java will get progressively harder to program in by anyone who doesn't already program in Java.

This is good for Java programmers because it means big bucks for being the only devs that can maintain huge legacy systems, but bad because fewer people will write new code in Java.

No. They will do too little, too late. Just like the lambda that were slated for Java 7 and came in Java 8. Now they're talking about value types, but it will be for Java 10 at the soonest (Kotlin doesn't have that either btw).

They're also wont to misdesign a lot of stuff. The generics implementation is mental, and the module stuff from Java 9 seems to be a debacle in the making. Lambdas are good though.

Java is too constrained by its OO straightjacket to be truly innovative. The brilliance of Jetbrains should not be underestimated. With Kotlin they've liberated Java development form its obsession with classes and produced a sufficiently FP alternative which yet retains full Java interop. No mean feat.

the best Java interop of all the JVM languages whilst

> Currently, there simply aren't any many contenders in Scala's niche (very powerful statically typed programming languages with a pragmatic bend, i.e. not Haskell). C++ could fit the bill but pushes memory management and Cthulhu on you.

That does sound like the niche that Rust is shooting for.

Isn't Rust niche safe low-level (mostly GC-less) programming?

I think it is, and the hoops you have to jump through to guarantee that safety are really at odds with what I would call "power".

It often feels high level (iterators and closures and all that), but yes, Rust is definitely designed to give you C++-like control over your memory.

The learning curve is fairly steep, and new Rustaceans do tend to go through a phase of "fighting the borrow checker". But once you get a handle on the ownership rules, I think you very rarely find them blocking you from doing something you actually should be able to do. For example, it is hard to get non-const pointers to two elements of a map at the same time, because the compiler can't prove they're not pointing to the same element, and that would let you violate all the safety rules. But I'm not sure I've heard of anyone running into that limitation in practice. And if you totally absolutely needed to, you could use unsafe code to do it.

The ownership system also gives you a different kind of power, to specify how your API's are supposed to be used, and to have the compiler enforce those rules. If a collection isn't threadsafe, for example, the compiler guarantees that you can't race on it from multiple threads. You can put the container inside a Mutex to let multiple threads use it, but then the Mutex will own the container, and callers can only access it by locking the Mutex. Those are powerful guarantees, and they solve problems that come up in managed/GC'd languages too.

Unless one is trying to do GUI related programming.

> But I'm not sure I've heard of anyone running into that limitation in practice.

Algorithms processing trees and graphs are everywhere, both in practice and in CS theory. Both are hard to implement in Rust and/or slow and/or require complex unsafe code. Here’s an example for trees, as you see all 3 approaches are far from ideal: https://github.com/SimonSapin/rust-forest

Another thing, because of that ownership thing, in Rust it’s harder to compose data structures. For example, here’s 1300 lines of code implementing hashmap + linked list combination: https://docs.rs/linked-hash-map/0.4.2/src/linked_hash_map/li... Sure, that particular collection is already in Rust’s standard library. However, quite often I need to compose standard library containers my own way. In Rust, that’s either a lot of complex unsafe code like that LinkedHashMap, or performance sacrifice (e.g. switching from pointers to index in a vector, or ref.counting).

I'd heard about the graph issue, but I don't know much about it. Is the main takeaway that GC makes managing trees/graphs a lot easier? If we were talking about C++ instead of Rust, what extra options would there be?

> Is the main takeaway that GC makes managing trees/graphs a lot easier?

It does indeed.

But raw pointers in C or C++ also make it easier than Rust.

Sure, it’s very easy to screw things up leaking and/or corrupting memory. But it still quite possible to implement correctly, I did that more than once.

Technically, you can usually do the same in Rust with unsafe pointers. Like the developers did to implement that LinkedHashMap for the Rust’s standard library. However, C++ is just better for writing unsafe code like this. After all, it evolved for decades being an unsafe language. Over that time, huge amount of stuff were implemented in the language (STL, esp. the checked version), runtime (debug heap), standalone tools (vtune, valgrind), and even OS (windbg) to help people implement e.g. graphs without leaking memory or exposing dangling pointers.

I love Ceylon - it is what Java should have evolved into (had it been managed better).

Java replacement would have to introduce something an order of magnitude better than Java, just like Java did, with respect to C/C++ (for business-level applications).

None of the existing solutions (Kotlin, Scala, etc) are at that level.

Actually Haskell can be a lot more practical depending on what one wishes to accomplish. I've seen many Haskell ideas encoded in Scala that then become a lot less practical (verbosity, stack space, efficiency).

>Scala's big trump card is the Java library ecosystem.

Much of which is awkward to operate with because of Scala's own collection library. One of the main reasons Kotlin is so much easier to use.

Most of the time you just need a single import and to call the 'asScala' function, I don't consider that too awkward.

It's very much possible to use the Java collections library in Scala, if that's what you want (I've done it in production before; I think the benefits of using a more functional-idiomatic and immutable-first collections API usually outweigh the costs, but the option is there).