Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Top Programming Languages 2025

spectrum.ieee.org

Post reply on HN
Print view View original

361–370 of 467 posts

Re: Top Programming Languages 2025

#361

Post by zabzonk »

throwaway2037 wrote: post #259
zabzonk wrote: post #152

Earlier quoted context omitted.

In retail banking I'm sure that this could be true. Working in investment banking, I never saw a single COBOL application, or had to have my C++/Java/$MODERNLANGUAGE code interact with one.

> Working in investment banking, I never saw a single COBOL application What was the back office settlement or wire transfer system written in? There is a good chance that some part of them was written in COBOL. And while Bloomberg terminals are a vendor product, for a bloody long time, many of their screens had some COBOL. Also, lots of quantitative software at i-banks use LINPACK or BLAS, which use FORTRAN.

Well, I had a very badly specified project to write a library for our back office systems to do Swift payments from our C++ applications, via COM. There was no obvious COBOL involved, on either side, but it has to be said that the whole use case for the library was very murky. And it never worked, due to the lack of spec, not the languages.

Re: Top Programming Languages 2025

#362

Post by lo_zamoyski »

lief79 wrote: post #343
zabzonk wrote: post #320

Earlier quoted context omitted.

I think the issue here is that people working in fintech don't seem to come across these systems much, if at all - if you know one specifically, please tell us.

It's still there at the accounting/backend level. Automated Financial Systems Level 3 and it's replacement Vision are commercial loan systems. LVL3 is pure cobol. It has been recently deprecated but there are many banks who own the code and are still self hosting it, along with it's IBM green screen support. Vision is a java front end in front of an updated cobol backend. When your reputation is based on your reliabi…

Analogously, GDSes like SABRE still ran on mainframes until very recently (c. 2023) [0]. SABRE was written in some combination of assembly and some kind of in-house dialect of PL/I, if I recall.

[0] https://www.theregister.com/2022/04/11/gds_gets_over_histori...

Re: Top Programming Languages 2025

#363

Post by BobbyJo »

psychoslave wrote: post #197

> AI assistance means that programmers can concern themselves less and less with the particulars of any language. Sure. Until we need to. Then we face some apparently tiny concern, which is actually deeply intricated with the rest of this whole mess, and we are ready for a ride in the rabbit hole. > most developers today don’t pay much attention to the instruction sets and other hardware idiosyncrasies of the CPUs th…

> This can be very misguided from my part but I have the feeling they are two very different cases here

They are indeed very different. If your compiler doesn't emit the right output for your architecture, or the highly optimized library you imported breaks on your hardware, you file a bug and, depending on the third party, have help in fixing the issue. Additionally, those types of issues are rare in popular libraries and languages unless you're pushing boundaries, which likely means you are knowledgeable enough to handle those type of edge cases anyway.

If your AI gives you the wrong answer to a question, or outputs incorrect code, it's entirely on you to figure it out. You can't reach out to OpenAI or Anthropic to help you fix the issue.

The former allows you to pretty safely remain ignorant. The latter does not.

Re: Top Programming Languages 2025

#364

Post by ttfvjktesd »

forinti wrote: post #318
psychoslave wrote: post #197

> AI assistance means that programmers can concern themselves less and less with the particulars of any language. Sure. Until we need to. Then we face some apparently tiny concern, which is actually deeply intricated with the rest of this whole mess, and we are ready for a ride in the rabbit hole. > most developers today don’t pay much attention to the instruction sets and other hardware idiosyncrasies of the CPUs th…

Oh dear. Using AI for something you don't understand well is surely a recipe for disaster and should not be encouraged.

On the other hand, one can see it as another layer of abstraction. Most programmers are not aware of how the assembly code generated from their programming language actually plays out, so they rely on the high-level language as an abstraction of machine code.

Now we have an additional layer of abstraction, where we can instruct an LLM in natural language to write the high-level code for us.

natural language -> high level programming language -> assembly

I'm not arguing whether this is good or bad, but I can see the bigger picture here.

Re: Top Programming Languages 2025

#365

Post by andersmurphy »

rootlocus wrote: post #78
channel_t wrote: post #6

Earlier quoted context omitted.

I agree, I think it makes most sense to add them up to be the true #2.

Then you should probably add kotlin and java together as well. They share the same purpose, use the same VM, usually live in the same project, have native compatibility, are used with the same frameworks, etc.

And Clojure and Scala. So really Clojure is number 2. :-)

Re: Top Programming Languages 2025

#366

Post by andersmurphy »

xwowsersx wrote: post #360
rootlocus wrote: post #78

Earlier quoted context omitted.

Then you should probably add kotlin and java together as well. They share the same purpose, use the same VM, usually live in the same project, have native compatibility, are used with the same frameworks, etc.

Add Scala in there, while you're at it!

Don't forget Jruby and Groovy.

Re: Top Programming Languages 2025

#367

Post by [deleted] »

epolanski wrote: post #350
agentultra wrote: post #334

Earlier quoted context omitted.

Would you recognize a memory corruption bug when the LLM cheerfully reports that everything is perfect? Would you understand why some code is less performant than it could be if you've never written and learned any C yourself? How would you know if the LLM output is gibberish/wrong? They're not wrong ; it's just not black-and-white. LLMs happen to sometimes generate what you want. Often times, for experienced program…

Not sure how your comments relates to mine. The parent I answered said you shouldn't use LLMs for things you don't understand while I advocate you should use them to help you learn. You seem to describe very different use cases. In any case, just to answer your (unrelated to mine) comment, here[1] you can see a video of one of the most skilled C developers on the planet finding very hard to spot bugs in the Redis cod…

[deleted]

Re: Top Programming Languages 2025

#368

Post by __MatrixMan__ »

torben-friis wrote: post #22

As a backend dev (mostly working in fintech) I feel weirdly unable to find a target language to move to. After working with Node and Ruby for a while I really miss a static type system. - Typescript was limited by its option to allow non strictness. Nothing catches my eye, as it’s either Java/.Net and its enterprisey companies or Go, which might not be old but feels like it is, by design. Rust sounds fun, but its use…

Do you think those languages are scratching the itch? If not maybe we need to pick a suitable underdog and champion its use. Clojure comes to mind. Or Unison. Something where immutability shines.

Re: Top Programming Languages 2025

#369

Post by spicybbq »

8fingerlouie wrote: post #164
bberrry wrote: post #146

Those of you surprised to see Java so prominent, where have you been all your careers? 10 people startups with nodejs backends? You must have been entirely shielded from enterprise software companies.

Java is the new COBOL. The financial sector, insurance sector, healthcare sector all jumped on Java a couple of decades ago, and they have massive repositories of Java code, and are actively migrating their COBOL code to Java.

> Java is the new COBOL.

What do you mean by this? To me it sounds like people are saying they are both "old" languages, but I don't know what you mean.

I work in a shop that has lots of both Java and COBOL. We are not "actively migrating" COBOL code to Java. It looks like mainframes will continue to exist for decades to come (i.e. >20 more years). Obviously, brand new applications here are not written in COBOL.

Re: Top Programming Languages 2025

#370

Post by cies »

ModernMech wrote: post #322
cies wrote: post #242

Earlier quoted context omitted.

Okay, Rust is general purpose enough... But is it general audience? (can every Py/PHP/JS/TS/Java/C# dev become productive in it quickly?) Also: if you want quick (re)compiles on a larger codebase, Rust is not for you.

I would say yes. I have experience teaching Rust to ~20 yo students of Java, and they are able to be productive in Rust within a semester. Your median Java and C# dev should be able to use Rust. Dunno about Python devs.

Sure they can use it, and learn it in a semester.

Also: good you use Rust in teaching!

But I want a fast on-ramp, quick iterations and clean looking code. (and went with Kotlin because of that -- I like Rust more myself, but I have a business to run, so tradeoffs)

Post reply on HN