>>14333>There's little reason to use Java over Kotlin. Kotlin is simply a better Java. And why not go a tiny step forward with Scala.<it's, why don't people switch to my niche functional language post #102983021312I swear you people don't listen. Writing small programs like chans or toy hackerrank/LC solutions is NOT THE SAME as writing enterprise grade software. There are other considerations. The only major company which has successfully used Scala, AFAIK is twitter. Other, non tech companies are way more conservative in language choice for reasons which are rational and apparent if anyone even stops to think about it for a second. My company is currently doing a rewrite in Scala from Java that has lasted like 7 years and they still aren't even
close to being done - ill let you know if it changes. Software in the real is not just solving cute little maths problems in N lines of code, it usually involves a ton of messy IO, use of third party libraries, and all kinds of untold levels of unforeseen little things that pop up that have nothing to do with whether you can implement a dynamic programming graph algorithm in a few less lines of code.
1. Scala is too complicated for most bean counting corporate engineers to understand, plus you can easily find an engineer with 20+ years of java experience meanwhile Scala wasn't even invented till 2004 and not common until the 2010s. So they command a wage premium that corpos aren't willing to pay when you can find a OOAD/design pattern expert java engineer for 100k$ less a year, meanwhile you'd have to pay an experienced scala/clojure/haskell engineer 170/180k$+ a year even in buttfuck nowhere, Indiana, where the average worker makes 40k, let alone Silicon Valley.
2. Java has a major silicon valley player backing it (Oracle), meanwhile Scala is only back by small companies like lightbend so there are less people to yell at when something goes wrong, higher chance of finding some reason to fire the manager if thing go south. Its too edgy as a choice, meanwhile no one gets fired for using Java/C#. Kotlin is backed by Intellij but the only reason its getting bigger is because google is hyping it to own oracle. Functional languages are often seen as academic and not for industry (other than edgy startups and twitter).
3. Java has a standardized libraries for distributed computing, web services, message queues, and other enterprise needs (JEE/Jakarta EE). Java has hooks in nearly every popular library/tool written, plus documentation and tutorials covering every possible aspect of it. These other languages have nothing comparable to this and often make you write shit yourself. Think of how much work goes to make a golang or scala/akka app do shit like user authentication.
4. inb4 "JEE is outdated because muh microservices", there are modern microservices frameworks like eclipse microprofile, which leverage huge parts of JEE with standardized tools like API documentation and even better (imo) distributed fault tolerance than spring cloud, ever since Netflix officially deprecated Hystrix and forced spring users to switch to Resilience4j.
4. Java is frequently taught to undergraduate CS majors, often as the primary language, or something extremely similar (C++/C#). Functional and object-functional languages like Scala/Haskell/Lisp, etc. are either briefly taught in a programming language theory or functional programming course, or sometimes not at all. As a result the average CS grad comes out of school with a ton of experience writing OOP programs and thinking in that paradigm and less than a few months as a FP programmer.
5. Most older engineers and even newer grads are more familiar with OOP/OOAD and usually Java/C# than FP and therefore leveraging their existing knowledge and skillbase is more useful than forcing them to start from scratch in a whole new language & paradigm.
6. Companies build systems that last years and sometimes decades. Given that they go with the safe choice of an officially Oracle supported-language as they think Oracle will be around in 15 years and xyz language corp. may or may not. FFS Martin Odersky is 63, even HE may not be alive in 15/20 years, let alone his language. Most professional developers have had an experience where they show up to a job as a junior and are assigned to work on code thats 5, 10, or even 20+ years old, sometimes even integrated with legacy mainframes from the 70s/80s and before.
7. “Verbosity” - Common sense tells you that verbosity is bad because it slows you down from writing code. This is actually wrong, first of all this is not like the keyboard in movies where some hacker or Gilfoyle from "silicon valley" type furiously on their keyboard to show how much more productive they're being. Even if FP languages technically take less keystrokes they also have more mental overhead and abstraction where the programmer has to think longer about what they’re going to write, before they write it. The productivity is probably a wash. Quoting from the imageboard thread (emphasis mine):
>There's also the readability argument. The fact is that people esp. hobbyist coders love to bring up terseness as an advantage (ohh, look at le quicksort in 3 lines of code in haskell or whatever) and verboseness as a disadvantage (muh boilerplate). The truth is that verboseness is a feature not a bug, the question of whether a language is good is not whether its easier to write but whether its easier to READ, and can be read and easily understood by a large team of people with varying levels of skill, ability, and experience. That's the difference between coding as an engineer/architect and coding as a hacker. The point is the vast majority of time spent on a program will be =READING the code not writing it and verboseness to a certain extent makes it more self documenting. If terseness was the end all be all then obsurantist Perl one liners with long ass regexps written by a sysadmin 10 years ago and never understood by anyone since would be the height of programming.There's usually no rational business case for abandoning that intellectual capital, experiences, organizational learning, and built code just because you learned you can do a cute trick in xyz lang about implementing quicksort in 5 lines.
Functional languages make bigbrain people more productive, but they bring average and mediocre devs to a standstill since it's incomprehensible to them and their productivity goes way down. Java/C# make it possible for a manager and some senior devs/architects to wrangle a horde of mediocre engineers to make decent software. Personally, I'd take a team player who follows best practices and good processes over le hacker/rockstar any day. In a startup the calculus may be slightly different and there may be a case to be edgy with tech stack choice including languages. But in enterprise, there really is no reason to when Java/C# already works. P.S. both languages have the same capabilities, they're both turing complete and any opinion about Kotlin/Scala being better than java is therefore just subjective. There's nothing Kotlin does better other than eliminate some boilerplate which only makes sense when you compare the base languages but most modern java frameworks like Spring have a bunch of annotations and codegen-like shit (ex: lombok) and heavy use of lambdas to where it's no longer boilerplatey.
the only reason Google is even hyping kotlin is to get out of their legal issues with Oracle over Android development. Oh, and null pointers, because checking if object==null is so hard now.
Look, I get it guys: Java/C# are BORING AS FUCK. They aren't a joy to write, and for most of us, they're WORK. Which I suspect is the main beef against it, no one wants to bring their day job home, the rest of this bullshit is nothing but puffery and rationalizations. But they are workhorses getting the job done and since Java's popularity isn't waning anytime soon, you can expect that it will be here for years to come.
Java is the Cobol of the 21st century and it ain’t goin anywhere. So all of the shit of Kotlin replacing java or whatever, let alone Scala (or Clojure, or Haskell), is coping and seething.