[HN Gopher] Java Is Underhyped
___________________________________________________________________
Java Is Underhyped
Author : Jaxkr
Score : 297 points
Date : 2021-04-16 00:13 UTC (21 hours ago)
(HTM) web link (jackson.sh)
(TXT) w3m dump (jackson.sh)
| slt2021 wrote:
| there are couple real reasons why managers/executives should
| choose Java over the other language:
|
| 1. it is battle tested, stable, and its strong and weak sides
| have been pretty much studies and internalized by developers
|
| 2. Java devs are like sand on the beach. They can be found
| everywhere at a cheap price. Develop something, then slowly
| outsource/offshore dev to cut costs and continue milking sales
| contracts.
| freedomben wrote:
| I've never heard someone with experience in npm say they _love_
| maven. Interesting. Regardless, I actually agree Java is a fine
| language. I 'm still surprisingly productive in it despite 10
| years of time away.
|
| However, it's the _culture_ around Java that I hate, and that 's
| the reason I avoid Java. The amount of low quality Java code out
| there is staggering. The culture around Java is one of extreme
| levels of abstraction and encapsulation, and it makes reasoning
| about Java code really painful some times. If you have worked in
| a Java shop, check out the Enterprise edition of FizzBuzz:
| https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
| kaba0 wrote:
| There are as many Java developers as people in a smaller
| country. FizzBuzzEnterprise is just a big subset of them, but
| there are so so many other interesting niches, like robotics,
| hell real time usage, everything.
| kryptiskt wrote:
| No other language has ever been hyped to the degree that Java was
| back in the day. The marketing was relentless and every month
| some new Java-related thing was going to change the world: thin
| clients, Java Cards, Java browsers, Java office suites...
|
| We will never see its like. There's no money in programming
| languages anymore, no one would drop the kind of cash on pushing
| their pet language that Sun did back in the day.
|
| What I'm saying is: Java have had its hype and should settle in
| for a dignified middle age rather than try to hang with the cool
| kids.
| ElectricMind wrote:
| I am creature of habits. I like consistency in my world. I hate
| chaos. Java is not perfect language. But with Java I feel
| peaceful. At least I am not surprised by my own code. Underhyped
| or overhyped - I am with Java :)
| hn_throwaway_99 wrote:
| I was a Java developer for about 15 years, then switched to Node
| and Typescript about 4 years ago.
|
| I think this author is going to be up for a rude awakening when
| it comes to the benefits of nominal typing, as this is the area
| that I couldn't disagree with more. I've commented about this
| before, but structural typing in Typescript makes it _so_ much
| easier to refactor and to get one existing piece of code to
| confirm to another existing piece of code. Refactor projects in
| Java could sometimes literally take months when you had a major
| version upgrade from some important dependency and now you had to
| replace all your Foo1 objects with Foo2 objects, even though the
| interfaces themselves were largely the same.
|
| I just find myself sooooo much more productive in the
| Node/Typescript ecosystem than I ever felt in Java.
| Jaxkr wrote:
| Fair point.
| RivieraKid wrote:
| Java is a good language for many use cases. What are the
| alternatives when I'm looking for a language that is at least as
| fast, statically-typed, garbage-collected, multi-platform, has
| good IDE support and similar amount of libraries? There are not
| many.
|
| There's Kotlin (better than Java but not by a big margin),
| Typescript, anything else?
| The_rationalist wrote:
| Kotlin is better by a large margin.
| theamk wrote:
| There are a few reasons to avoid Java today.
|
| - The programs are very verbose for the functionality they
| provide. There are countless lines of getters, setters, and
| trivial constructors. While IDE helps to write them, it makes
| reading existing programs slow and frustrating. Lombok helps, but
| very few programs use it.
|
| - If you do want to use Java ecosystem, there is Scala. It also
| has strong type system, nice IDE support and big ecosystem of
| third-party libraries, but is much more expressive and easier to
| read and write that Java.
|
| - Finally, if you have to run medium to large java programs, you
| need to constantly tune the JVM. Unfortunately, you can't
| "confidently trust the JVM to do what's best" -- you need to get
| familiar with GC algorithms, manual heap sizing, GC tracing
| options and so on.
|
| Java still has plenty of uses because it has so much code written
| in it, but luckily, the new projects are using it less and less.
| I really look forward to the day when I can stop tuning -Xmx
| option in start.sh files!
| dbt00 wrote:
| Is the Scala language finally stable? I looked at it and
| discarded it multiple times over the last decade because every
| significant language revision required changing source code.
| MrPowers wrote:
| It's more unstable that ever with Scala 3 around the corner
| (which is basically a new language) and the May 1st Bintray
| shutdown that'll be massively breaking for the ecosystem. SBT
| builds were failing the other day from the Bintray brown-out
| cause all SBT plugins are still in Bintray: https://www.reddi
| t.com/r/scala/comments/mph43t/sbt_build_fai...
| Jaxkr wrote:
| I like Scala but that Bintray situation sounds like a
| nightmare.
| MrPowers wrote:
| Yea, JFrog announced the May 1st shutdown of Bintray on
| Feb 3rd: https://jfrog.com/blog/into-the-sunset-bintray-
| jcenter-gocen...
|
| 3 month warning that they'd blow up the ecosystem. I have
| no idea why a company that builds products for devs would
| take such an aggressively anti-dev approach to shutting
| down a core service.
| esarbe wrote:
| I've been working with Scala professionally for the last 8
| years and I consider it pretty stable. Code I've written for
| Scala 2.10/2.11 still compiles with 2.13.
|
| I think the biggest change for me was the redesigned
| collections-library, but that was rather simple migration.
|
| That said; there are a few breaking changes with the
| migration to 3.0 - especially if you rely on unsupported
| features of the compiler, namely macros. Macros have been
| widely used in the past and will not be supported anymore.
| twic wrote:
| > Scala [is] easier to read and write that Java
|
| You either haven't used Scala, or you haven't used Java.
| hocuspocus wrote:
| Plenty of things are simpler and easier to read in Scala
| really: lambdas, constructors, case classes, named and
| default arguments, for comprehensions, collections, operators
| on non-primitive types, ...
|
| Sure, you can find libraries using complex type-level
| machinery, macros and so on. But wading through complex Java
| libraries that overuse OO design patterns isn't particularly
| approachable either.
| [deleted]
| cies wrote:
| > If you do want to use Java ecosystem, there is Scala.
|
| Scala has a whole slew of problems of it's own. IMHO, Kotlin is
| where all the Java refugees on the JVM continent are at.
| travisgriggs wrote:
| I use Kotlin so that I don't have to use Java. But it's still
| far from the "This is the Language I want to commit the rest
| of my career to."
|
| Language development looks a lot like the startup path
| anymore. Claim you fill a need. Focus on growth growth growth
| by adopting features from as many communities as possible as
| fast as possible. If it's trendy, add it! Have a flashy web
| page. Find some venture capital by getting a big org to
| underwrite/champion you. Figure out how to really solve
| problems and fix everything once you've got critical
| community.
| chriswarbo wrote:
| I think of Java as hitting an 'anti-sweet-spot':
|
| - It forces us to go through the ceremony and verbosity of
| static typing, yet blows away lots of the benefit by pervasive
| use of `null` and `Object`. Compare this to ML or Haskell,
| where there's _less_ ceremony (Hindley-Milner type inference)
| yet _more_ safety (no `null` or down-casting)
|
| - Checked exceptions have a similar ceremony and verbosity
| problem, yet the pervasiveness of unchecked exceptions prevents
| us actually having much confidence that calls will succeed.
| Compare this to effect systems, even rudimentary ones like
| Haskell's (`Maybe`, `Either`, `IO`, etc.): if a function _doesn
| 't_ return one of these 'effect actions', we can be pretty sure
| that it will succeed (the only unchecked exceptions I've
| encountered in Haskell are pretty catastrophic things like
| OutOfMemory).
|
| - It needs to be compiled ahead-of-time, which requires more
| tooling, makes automated testing more annoying (we have three
| different failure-reporting mechanisms: app compile error, test
| compile error, test failure), tools like REPLs are second-class
| afterthoughts, etc. Yet the resulting bytecode still requires
| an interpreter (JVM), which takes a while to spin up, and makes
| deployment and packaging harder (we don't have a self-contained
| binary).
|
| - It pushes an OOP style, but requires that we keep subverting
| it; e.g. pervasive use of using structured-programming
| constructs like `for` (which other OO languages like Smalltalk
| avoid in favour of method calls), which requires we break
| encapsulation/implementation-hiding (e.g. if we loop with an
| 'Iterator', we need to know whether anything we call will use
| that same Iterator).
|
| - It _seemingly_ pushes a high-level, highly-abstracted design
| (methods calling other methods, classes maintaining their
| invariants, etc.); but then throws threading into the mix,
| which breaks things into such low-level pieces that even 'i++'
| needs to be thought of in terms of constituent parts (read,
| increment, write, return).
|
| I agree that Scala's better (e.g. reducing a lot of the typing
| ceremony; making it easier to remain high-level/abstracted
| (e.g. encouraging 'map' and friends rather than effectful
| loops), etc.); it inherits some of Java's problems (and doesn't
| even flag _checked_ exceptions!), but it 's _nice enough_ to
| tilt the balance in many cases.
| twic wrote:
| > pervasive use of `null` and `Object`
|
| Who is pervasively using Object? You are talking about a
| language that hasn't existed for a decade.
| chriswarbo wrote:
| As a simple example, `x.equals(y)` accepts an arbitrary
| Object y. This one example has ramifications all over the
| place, e.g. I had a bug recently where I was checking if an
| element was in a collection, using `x.contains(y)`. That
| .contains method seems to use .equals, since it allows y to
| be any Object. In my case x was a collection of MyType
| values whilst y was a MyWrapper<MyType> which I forgot to
| unwrap. Rather than giving a type error, this check was
| always returning false.
|
| Since then I've defined a .has method which requires the
| argument to have the same type as the collection, which
| completely avoids such problems.
| kaba0 wrote:
| Alt insert generate equals method, select fields, ready.
| Or use a record. It is such a minuscule part of the
| language, that it simply doesn't matter compared to every
| other line of code, lib, ecosystem. You may imagine how
| much more productive you are that this language has sane
| equals, but it is not even a reasonable constant factor.
| twic wrote:
| Excellent example, thank you.
| sixbrx wrote:
| Yes and also Map's "get(Object key)" and "remove(Object
| key)". Those are the bane of refactorings, for me.
| blandflakes wrote:
| Fun fact, this also happens in Scala - try to
| List.contains an object from a type different than that
| stored in the list. Compiles, returns false always.
| chriswarbo wrote:
| I actually encountered this in Scala (my example
| originally had [square brackets] rather than <pointy
| ones>).
|
| My `.has` method uses cats.Eq and is monkey-patched on to
| the Iterable interface: implicit final
| class IOps[A: cats.Eq](val i: Iterable[A]) {
| def has(x: A): Boolean = i.exists(_.eqv(x)) }
| blandflakes wrote:
| Ha, yup. We use the .contains_ method with cats eq on the
| objects, but this is clever.
| oftenwrong wrote:
| Those are ancient warts that can never be changed. Almost
| any static analysis suite will warn you about using
| equals and contains with incorrect types.
| wing-_-nuts wrote:
| And yet golang passes empty interfaces everywhere and
| generics is still a _proposal_. /salt
| Yeroc wrote:
| Not really following or agreeing with most of your arguments
| here but on the subject of Checked/UnChecked exception I
| agree. Java would have been better off with simply Checked
| exceptions and errors and no RuntimeExceptions. The current
| lovefest for unchecked exceptions in Java is very
| unfortunate. New features like lambdas don't work well with
| checked exceptions and there seems to be little urgency in
| rectifying those shortcomings either. Instead everyone is
| just switching things to use unchecked exceptions. For people
| running stuff in web containers I suppose it hardly matters,
| a single request fails, no big deal but for other types of
| programs having checked exceptions is invaluable.
| coldtea wrote:
| > _- The programs are very verbose for the functionality they
| provide._
|
| That's true for 2005, not 2021, with var, type inference,
| closures, streams, and other such features. And since forever
| getters/setters are auto-generated by the IDE (including Emaca
| and Vim) and can just be ignored, and Java today has Records
| which don't need them.
|
| > _- If you do want to use Java ecosystem, there is Scala._
|
| Now you have exponential problems. Scala has less support,
| slower builds, and features Scala-devs are eager to abuse to
| make the code unreadable.
|
| > _- Finally, if you have to run medium to large java programs,
| you need to constantly tune the JVM._
|
| No, you really don't.
| twic wrote:
| > No, you really don't.
|
| Production algorithmic trading app, 100k LOC, 8 GB heap, 258
| threads, right now only using 105% CPU; Java 11, and this is
| the complete extent of JVM tuning we have done:
|
| -Xmx8g -XX:+ExplicitGCInvokesConcurrent
|
| Back in the Java 1.x days, you often did need to do careful
| JVM tuning. But for the past few years, you haven't. The
| ergonomics are enough for a very broad range of workloads.
| coldtea wrote:
| Yep.
|
| And to add to what you wrote for those that are not
| familiar with those types of apps: "Production algorithmic
| trading apps" is among the worst case regarding to
| peformances / pauses / and tuning needs.
| blandflakes wrote:
| Yeah G1GC has been a marvel for us as well (high traffic
| streaming video)
| esarbe wrote:
| > Now you have exponential problems. Scala has less support,
| slower builds, and features Scala-devs are eager to abuse to
| make the code unreadable.
|
| Unfortunately, the Scala compiler is quite a bit slower than
| javac. In practice this doesn't hurt quite so much anymore;
| incremental builds make working even with large code bases
| quite snappy. Full-rebuild; get a coffee.
|
| The build tools for Scala have _massively_ improved in the
| last 5 years. IntelliJ support is superb and VS Code with
| metals is shaping up very nicely.
|
| I agree that since Scala is a unopinionated language, you
| need to be strict in what you allow your devs to do. Code
| reviews and agreements on levels of abstraction and concepts
| used is mandatory.
|
| I've worked with multiple teams in the last 8 years and this
| discipline is important when working with Scala. Doing so
| will give you the opportunity to write clean, maintainable
| and readable code in a very powerful language.
| blandflakes wrote:
| The compile time is horrible, but improving, agreed. SBT is
| a serious travesty and I don't blame anybody who skips the
| entire language to avoid it.
| KptMarchewa wrote:
| Does scala compiler still does 25 or something like that
| passes? It won't ever be fast when doing this.
| esarbe wrote:
| It's still too many passes.
|
| https://scala-ci.typesafe.com/grafana/dashboard/db/scala-
| ben...
|
| The Scala 3 compiler has much fewer passes though.
| mjevans wrote:
| Another reason to avoid:
|
| Oracle owns Java.
|
| This automatically puts Java on my list of tools I'd prefer to
| avoid for new serious projects. (Legacy projects; if it's
| working and it isn't an issue yet, maintenance.)
| eitland wrote:
| Use OpenJDK!
|
| Never touch anything from Oracle.
|
| Then you will be fine.
|
| Oracle is the company that wants you to buy a license for
| your MariaDB(!) instance running on a small AWS instance!
| Yep, that happened.
|
| Source: have worked with Java for years, three of those
| around Oracle products.
| severino wrote:
| > Use OpenJDK! Never touch anything from Oracle.
|
| But OpenJDK is Oracle's. They are the primary contributors
| to the project, and they really made it 100% open-source.
| skeeks wrote:
| Despite Oracle being the primary contributors, there are
| other big companies (IBM, Apple, Microsoft, etc.) [1]
| supporting OpenJDK. And this are only the big companies,
| there are so much medium/little companies just using Java
| as a language without actively sponsoring/supporting the
| OpenJDK project. IMHO, there is no possible way that the
| OpenJDK (and Java) arent going to be enhanced further for
| many many years.
|
| [1] https://en.wikipedia.org/wiki/OpenJDK#Collaboration_w
| ith_IBM...
| severino wrote:
| I know, I just wanted to point out that you cannot use
| OpenJDK and at the same time not use anything from
| Oracle.
| pulse7 wrote:
| You can use any other fork/build like AdoptOpenJDK or any
| other. It is open-source like Linux Kernel...
| severino wrote:
| You can use AdoptOpenJDK or Azul or whatever, but you
| will be using code largely from Oracle. I don't think
| there is any problem with that, but the OP said "never
| touch anything from Oracle".
| ivan_gammel wrote:
| It is not a big deal as long as it's still run as
| independent project. There are plenty of other big
| players interested in keeping reference implementation
| vendor-neutral.
| [deleted]
| skeeks wrote:
| Java is not only driven by Oracle, there are even independent
| JVMs. And then, there is OpenJDK, which is supported by many
| different big companies (Oracle, IBM, Apple, Microsoft, etc.)
| [1] As long as you are just _using_ the JDK, I see no problem
| regarding that Oracle may sue you. And besides that, I see no
| problems about Oracle _owning_ Java (idk if you really can
| say that Oracle _owns_ Java, I mean OpenJDK is open-source
| and free).
| cosmotic wrote:
| As a Java developer: - I have no trouble reading java and have
| a hard time reading the 'less verbose' languages. There's way
| too much implied meaning and information only gleamed through
| tooling or backtracing, like determining the type of a variable
| that is declared with var
|
| - IDE support for Scala is half as good as Java and I suspect a
| good reason is the language. The auotcomplete in intelliJ is
| almost as bad as it is for python and the IDE really struggles
| to understand the code; CPU usage when scala is open is MUCH
| higher than Java.
|
| - On all the Java apps I've worked on, I've never tuned the
| JVM. Tuning the VM sounds like focusing on the wrong part of a
| bottlenecked system. I've never tuned Python or PHP either but
| they aren't as performant. Regardless, GC gets better every
| release.
|
| It sounds like your negative views are more about the
| applications you've worked on than the language or technology.
| esarbe wrote:
| > IDE support for Scala is half as good as Java and I suspect
| a good reason is the language. The auotcomplete in intelliJ
| is almost as bad as it is for python and the IDE really
| struggles to understand the code;
|
| This is not my experience. I found the IntelliJ
| autocompletion to work very well with Scala. There are nice
| code-suggestions, highlights for implicit parameters,
| refactoring works as a breeze. What exactly are you missing?
|
| > CPU usage when scala is open is MUCH higher than Java.
|
| That is true. MUCH higher.
| mypalmike wrote:
| Yup. As a C++ developer back in the day, I had no trouble
| reading Java when I first started using it. Indeed it was
| immediately easier to read than the language I'd spent around
| a decade with.
| [deleted]
| thu2111 wrote:
| The GC comment was true of older versions of the JVM but newer
| versions are much better. And by newer I mean versions released
| in the last 5 years or so. So not that new.
|
| There are one or two knobs left but those are fundamental to GC
| technology and it's not even obvious they're bad to have. GC
| lets you trade off memory against CPU time in ways manual
| memory allocation does not. You can throw memory at your
| program and it'll run faster, or you can constrain it and it'll
| run slower, but that's not a decision the _developer_ can
| always reasonably make. It 's in some ways inherently an
| ops/deployment/end user thing.
|
| Other GCd languages either:
|
| 1. Have knobs too (Go/.NET both have knobs), just usually not
| very good ones.
|
| or
|
| 2. Are so slow (Ruby, Python) that GC tuning is really the
| least of your worries and they just don't expose it at all.
|
| or
|
| 3. Are JavaScript, in which case everyone pretends that running
| a VM designed exclusively for laptops and mobile phones on the
| server isn't a giant waste of resources. V8 doesn't do GC
| tuning because its only real customer is web browsers where
| users can't do that, and heaps are small anyway.
|
| Java ended up getting a totally unfair rap about GC because it
| actually was fast enough that GC performance mattered, and was
| interested in power users on the server where exposing knobs
| can make sense. Other competitors don't even try, but this
| doesn't make them better. After all, nothing stops you just
| ignoring the knobs and plenty of users do exactly that.
| offtop5 wrote:
| Java is under hyped in the same way Toyota Corollas are under
| hyped.
|
| Nothing is exciting about it since it's so common. I personally
| dislike Java since I just find it hard , you'll never want for
| work as a skilled Java developer
| Jaxkr wrote:
| Good analogy.
| Koiwai wrote:
| That's a great analogy, but I'm a bit confused about the later
| part, is it "you'll never be wanted for work as ..." or "you'll
| never want to work as ..."?
| Brian_K_White wrote:
| "You'll never want for X" means you'll never need X, you'll
| always have all of the X you could want.
| Koiwai wrote:
| I'm not good at English but shouldn't that be just "You'll
| never want X"?, "for" seems redundant to me.
|
| Anyway I looked it up, seems it's a legit usage, my bad.
| Brian_K_White wrote:
| That is not wrong, but "want for" is also a common and
| old idiom.
|
| Akin to "for want of a horse"
|
| Another way to think of it is simply another slightly
| different meaning for the word "want". Just like in "for
| want of a horse", or "was found wanting", you can replace
| the word "want" with the word "lack" in all these
| examples.
|
| "You'll never lack for work", "the project stalled for
| lack of engineers", "the code was found lacking"
|
| "Want" may be used as a drop-in for "lack" in each of
| those.
|
| You could also just say "lack work" instead of "lack for
| work". But that doesn't really make the "for" redundant.
| Though I can't explain the reason why not.
|
| Maybe the "for" in "lack for X" or "want for X" is like
| the "for" in "look for X" or "wish for X"
| pessimizer wrote:
| "Want" is a synonym for "lack." "Want" to mean "desire"
| is a euphemistic usage that doesn't have a citation until
| over 500 years after the original usage.
|
| > You could also just say "lack work" instead of "lack
| for work". But that doesn't really make the "for"
| redundant. Though I can't explain the reason why not.
|
| I think it's just that "want" in its original usage is a
| noun. "Wanting" in "found wanting" is really a gerund of
| "have a want," not a gerunding of "want." "Wanting" as a
| gerunding of the verb "want" doesn't necessarily imply a
| lack. "Wanting to go to the park on Wednesday" doesn't
| mean you lack anything.
| rbancroft wrote:
| noun: want; plural noun: wants 1. a lack or
| deficiency of something. "Victorian houses which are
| in want of repair"
|
| In this case it's a double negative, OP means you'll always
| be able to find work as a skilled java developer.
| rbancroft wrote:
| ok I'm wrong on the grammatical analysis, it's not a noun
| but rather an idiom meaning to lack or need something.
| [deleted]
| [deleted]
| frugalmail wrote:
| I think the problem is the cohorts your talking about. There is
| the dimension of how long you've been programming and how large
| your software projects are. The folks that gravitate to
| environments like Java are usually in the high experience large
| software environment. The other quadrants typically gravitate
| towards the terse and rapid development platforms.
| dalleh wrote:
| I have never done anything professional in Java but I used Maven
| and Gradle build systems enough to make me hate everything about
| Java.
|
| I don't know about the language itself but as an ecosystem Java
| failed spectacularly. Why is there a strong relationship between
| an application developed in Java and lack/horrible setup of
| documentation for this app? I just find it everytime I use
| something developed in Java.
| de6u99er wrote:
| Java is boring because its mature and just works. Plus many have
| a problem understanding how to do proper OOP.
| ch_123 wrote:
| Reading between the lines, I feel like the author (who admits
| that they are new to the industry) is placing too much emphasis
| and value on certain technologies having "hype". This is
| reasonable - I also was a bit like this when I was starting out
| in my career.
|
| I feel like the takeaway the author should have arrived at is
| that hype comes and goes, and doesn't really correlate with
| whether a piece of technology is valuable or not.
| gorjusborg wrote:
| Exactly my thought as well.
|
| It's following the hype that steered him wrong in the first
| place.
|
| Over time, I've found myself more interested in tech that
| sticks around. There's usually something to learn from it.
| spacemanmatt wrote:
| Perhaps Java isn't the most popular tool in the shed but its LTS
| story is unstoppable. I rank Java with Apple/Microsoft, in terms
| of respecting developers' investments in their APIs.
| ascagnel_ wrote:
| I think it's interesting that you're lumping Apple in there.
| Their iOS stuff has been fairly stable, but they've been fairly
| aggressive in chopping off support for legacy tech (32-bit apps
| was a big one, especially in the macOS world).
| spacemanmatt wrote:
| I have followed Apple architecture since the 128k Mac and the
| Lisa. They have studiously avoided breaking all apps at the
| same time. To wit, the 68k to Intel migration for many was
| recompiling with Xcode, and some code review per Apple
| guidelines. They actually went to great lengths to give you
| tools to ensure your migration went as smoothly as possible,
| where the OS interface was concerned. ARM: Lather, rinse,
| repeat, or not, if you are satisfied with emulated
| performance.
| [deleted]
| rektide wrote:
| the verbosity complainers have no idea. they're just way off
| base. writing some jax-rs or what not is so compact, so simple,
| so easy. I can't begin to understand these complaints given the
| get started cost of any alternative, all the js frameworks, elm,
| swift, whatever. java's magic annotation systems are wonderful &
| concise.
| baby wrote:
| Oh man, if you like Java power to you, but I refuse to work with
| that language.
| hankchinaski wrote:
| can you actually write/compile/run/debug a "modern" java project
| without using a bloated IDE and waste half your morning tinkering
| with XML configs? my current setup with Go is amazing, I can use
| a minimal vim/tmux setup to work on just almost anything and it's
| great. my experience contributing to big java projects has been
| enough to make me dislike it and never look at it again
| aprinsen wrote:
| I didn't care for Java when I learned with it in school, found it
| verbose.
|
| Working with it as a dev, my opinion improved. A lot of the new
| FP inspired APIs make logic much terser, and the OOP stuff can
| make implementing certain architectural patterns very clean.
|
| The other great thing about Java is that nearly every conceivable
| question has been answered, as far as day to day development. Not
| so for newer languages.
|
| My biggest pain point with java is the type system. Like, you
| basically need to write or consume a library to work with tuples.
| fomine3 wrote:
| Stream API allows you to write fluent codes until you met
| checked exceptions. I wish they had solved this.
| erik_seaberg wrote:
| Java generics just aren't powerful enough to express that a
| higher order function's exceptions depend on its args, so
| pretty much everyone has given up on specific checked
| exceptions.
| twic wrote:
| Yes, they are: @FunctionalInterface
| public interface ThrowingConsumer<T, E extends Throwable> {
| void accept(T value) throws E; }
| public static <T, E extends Throwable> void
| forEach(Collection<T> elements, ThrowingConsumer<T, E>
| consumer) throws E { for (T element : elements)
| { consumer.accept(element); }
| }
|
| There is a significant shortcoming, which is that you can't
| catch exceptions using the type parameter - this does not
| compile: public static <T, E extends
| Throwable> Optional<E> forEach(Collection<T> elements,
| ThrowingConsumer<T, E> consumer) { for (T
| element : elements) { try {
| consumer.accept(element); } catch (E e) {
| // <-- not allowed! return
| Optional.of(e); } }
| return Optional.empty(); }
|
| You can kludge your way around that in various ways, but
| none of them are pretty.
| erik_seaberg wrote:
| Yeah, that sort of works, though I'm not sure a function
| that throws two distinct exception could be compatible
| with a generic method that takes functions throwing three
| distinct exceptions (that may sound crazy but some
| java.security crypto stuff does it).
| twic wrote:
| You can bind unused parameters to RuntimeException! I'm
| not telling you you should enjoy doing this, mind, just
| that it's possible.
| Yeroc wrote:
| Looking back on it now I think our revulsion to simply
| using "throws Exception" ought to be re-examined. In
| practice, while it's nice to know exactly what kinds of
| exceptions are being thrown it could be the emphasis on
| this actually holds us back. What's more important is
| whether an Exception could be thrown at all versus none.
| nickelcitymario wrote:
| Lost me at "This cannot be understated: Java simply feels good to
| write."
| legulere wrote:
| C# is a better Java and nowadays is cross platform and open
| source.
| rock_artist wrote:
| Language opinions are fun :)
|
| I'm actually old enough that Java was my main language during CS.
| No Python...
|
| Before that when I during my teenage years I got to lecture by
| some senior in IBM that showed how amazing is Java and it's the
| future. (That was 10! Years before I've attended)
|
| And that's that's the thing... Hype is all about "new" things.
| And after a while it dusts off.
|
| HN had a lot of posts about good developers. usually it sums up
| as problem solving and human relationship. Never I saw a good
| developer of language N.
| sodality2 wrote:
| >I'm actually old enough that Java was my main language during
| CS. No Python...
|
| Is java considered old or outdated for today in CS? I'm
| learning Java in my AP computer science class to this day.
| js8 wrote:
| The ultimate problem with Java (and OOP too, even in the Kay's
| sense) is that its philosophy represents a very paternalistic
| approach to software development. The idea is here are these
| things called objects, you can't look into them, and you only
| have to use them the way they are designed; under no
| circumstances you can break them down into internal components
| and remix those freely.
|
| In Java, this overall approach manifests in myriad of different
| ways:
|
| - Functions and data are tied together. It's difficult to create
| new functions (methods) that operate on existing data, you have
| to inherit, and even that avenue can be closed, even indirectly
| because you find that you cannot actually get to some internals.
|
| - Interfaces are tied to objects. You cannot explain to the
| compiler that a given class actually supports a certain other
| interface in the way YOU define it.
|
| - Everything is a reference, no value types. No need to worry
| about the intricacies of cache management, we will handle that
| for you.
|
| - No need to worry about CPU optimizations or memory management
| either - we will do that for you, without an escape hatch.
|
| - You cannot change the existing operators to introduce more
| convenient syntax, because I said so. Any kind of "macro" - code
| generators, compile-time checks, conditional compilation, DSLs -
| forbidden.
|
| - The class and package hierarchy determines the access to its
| components. No way to override this from the outside, no way to
| expose things that are hidden. Worse, this is implicit, for
| example, class method accesses an object attribute, where taking
| a parameter would be more convenient; this hurts reusability
| pretty badly.
|
| Some of these shortcoming are only now being addressed, because
| people actually need to do these things anyway, in certain
| situations, which leads to proliferation of patterns and magical
| code generators.
| fsociety wrote:
| This so hard. I'm fearful when I hear things like Java being
| under hyped. Do people think this is the pinnacle of what
| software development is today?
|
| I think it's made worse by the fact that you can program in
| another language, in a shitty codebase, and walk away saying
| "wow that language is very painful".
|
| When in reality, it could've been the codebase and not the
| language.
|
| I see a lot of "but look at this successful project in language
| X". Okay sure it was successful despite the language.
| Programmers are smart, we can make things work.
|
| Philosophically forcing developers into having to program in an
| OOP style, as opposed to having it as one of many tools, is a
| cardinal sin in my eyes. Same for forcing reference types.
|
| I'll argue garbage collectors are bad too, but tbh that is more
| of a debatable topic.
| kaba0 wrote:
| I think you mistake general Objects, and their sub"class" data
| objects. Data oriented design is popular now, but it is just a
| subcategory. As a base, OOP is really great, class invariants
| and encapsulation is the only effective weapon against
| complexity (and software engineering is largely about managing
| complexity).
|
| Data classes that expose their internals are a great way for
| some program logic, but let's say a database connection is very
| much not a simple data class. It does have some static data,
| but it should not be accessible to the outside, because then it
| is not safe to close/use/whatever.
| kodeninja wrote:
| Sorry, but _nobody_ Maven.
| habosa wrote:
| I haven't been coding as long as most (about 10 years) but I've
| had phases of Java, Ruby, Python, JS, TS, ObjC, etc.
|
| If I go onto my GitHub and try to get any of my old projects
| running I am extremely confident that the non-Android Java ones
| will still work. All of the other ones will probably have
| "rotted" over the years and send me down a day-long rabbit hole
| looking for old dependencies or build systems.
|
| There's something to be said for that amazing stability. I can't
| think of another language where you can find some .edu page from
| 2001 with a link to a library (.jar) that does what you need and
| you can actually use it in a modern application.
| jerven wrote:
| This, so much this. The value of code just working and staying
| working is humongous. Having code that is unchanged from Java
| 1.3 doing it's thing and delivering value 21 years later
| without needing to be touched and revisited allows us to focus
| on improving the code that needs to be improved.
|
| Doesn't mean we don't touch old code (change idioms, generic
| safe, build process etc). It means we do it when there is value
| to us for updating it. Not because we are forced to due to an
| infra change.
|
| At the same time code that ran on a PA-RISC machine now happily
| runs on a mac arm (even then it was great because the same code
| ran on PA-RISC, powerpc, x86 and X86-64).
|
| If that code was written in python it would have likely gone
| through two breaking cycles at least. C sure that would have
| worked but the cost of having it working such a variety of
| systems would have been humongous for a small group like us.
| What real alternatives have this claim? C++ chances that I can
| compile code from 2000 without issues is minuscule.
|
| Sure I had my EJB "fun", and when I look at some of the micro-
| services being deployed I see the same problems. Because they
| are reflections of organizations. (i.e. sometimes have the
| feeling that changing language in an org is like switching your
| in-office communication to Italian, because it so fast and
| romantic.).
|
| Just because there was "bad" code written in the past doesn't
| mean new code is done that way. Yes it exists, yes it needs to
| be poked once in a while, but that is a lot cheaper than
| rewriting in a modern style.
| qayxc wrote:
| > C++ chances that I can compile code from 2000 without
| issues is minuscule.
|
| Really? I have code from the late 90ies and it compiles just
| fine. Do you perhaps mean dependencies? Because the issue
| there is the completeness of the framework and libraries
| around Java rather than the language itself.
| jerven wrote:
| Yes, the C++ dependencies are unlikely to be available.
| Specifically dependencies on OS libraries that are just not
| available on current common systems.
|
| So you need to get them but they are not available anymore
| and may depend on code that doesn't compile anymore. Due to
| e.g. 32bit assumptions, changes in what a 'long long' means
| and small hiccups like that.
|
| Or the fact that C++ code was "almost" C++ code and not
| actually C++ code. Just a variant that was supported by an
| "almost" C++ compiler.
|
| Not really the case for smaller utilities but larger
| projects originating on what is now rare equipment suffered
| from this.
|
| So maybe not "miniscule" but not rare in my experience
| either.
| qayxc wrote:
| > Specifically dependencies on OS libraries that are just
| not available on current common systems.
|
| But again, that's a problem with the OS, not a problem
| with C++. POSIX compliant code still compiles just fine
| on POSIX-compliant platforms and 32-bit code compiles
| just fine with 32-bit compilers as well - nothing changed
| in that regard. It's a similar story with other APIs such
| as Win32.
|
| > Due to e.g. 32bit assumptions, changes in what a 'long
| long' means and small hiccups like that.
|
| If you try to compile 32-bit code as 64-bit code you're
| porting, not recompiling. You can also just specify
| -std=c++98 (with g++) or just use an old compiler.
|
| In my experience the problems with Java code are just as
| annoying, but those problems don't come from within the
| language itself either.
|
| Things that weren't natively available had to be added
| via external scripts, application servers, native
| libraries, etc. And getting a fragile jumbled mess to
| work that relied on a specific Tomcat server version,
| command line scripts, external libraries or - god forbid!
| - certificates, was a major PITA as well.
|
| Even today trying to get something as simple as SSL
| certificates working with Java can be frustrating. Why?
| Because for some reason Java insists on keeping its own
| keystore because it's the JDK that decides which
| authorities are to be trusted - not the user, not the OS,
| only the JDK.
|
| Well, one of the installed versions, which gets to be
| real fun if you're working with containers, but I
| digress...
| fma wrote:
| I've been mainly a Java developer for almost 15 years, but
| was working with Python the last few months.
|
| I LMAO when Python changed (or broke...depending how you look
| at it) the basic print functionality between version 2 and 3.
| Meanwhile I can use the latest and greatest JDK to compile
| old java code.
|
| Don't get me wrong, I think Python is awesome for what I
| needed to do (data manipulation) and would likely be my
| language of choice for such tasks in the future.
|
| Also, the best way to get a highly commented article on HN is
| to write one on why you love, or hate Java.
| jiggawatts wrote:
| My experience with C# is similar. It was always designed to be
| a Java clone, and Microsoft is well-known for their backwards
| compatibility.
|
| I once wrote an application in 2005 that kept running with
| unmodified source code up until 2017 in production across
| multiple operating system upgrades, database upgrades, and a
| transition from 32-bit to 64-bit runtimes.
| linknoid wrote:
| And then they decided to end that line of succession. .NET
| Framework 4.8 is the last version of the framework. I've
| started experimenting with converting code to .NET 5, but
| it's a rather large jump compared to any previous upgrade.
| Going from 2.0 to 4.0 had a few minor hiccups, but going to
| .NET 5 is basically a rewrite of the framework and runtime,
| and I'm not sure how old and new assemblies will co-exist. It
| feels like a fragmenting of the ecosystem, where a bunch of
| code will be stuck on .NET 4 forever, and other code will
| move to the .NET 5 and later.
|
| I'm almost expecting a few years down the road, Microsoft
| will go back on 4.8 being end-of-the-line for .NET 4 and
| start releasing new minor versions of it because of all the
| customer code that can't be ported to .NET 5. Or maybe it
| will just end up like VB6. Stuff written in it still works,
| and will continue to work, but it's considered a dead
| language.
| V-2 wrote:
| _" [C#] was always designed to be a Java clone"_
|
| "Initially" would be somewhat closer to the truth than
| "always".
| tmccrary55 wrote:
| It's still pretty damn similar and they continually add new
| features to match the other, keeping up with the joneses.
| V-2 wrote:
| It's mostly Java that's playing catch-up, so arguably
| it's Java "cloning" C# rather than the other way round,
| and it's been that way for years now.
| dcchambers wrote:
| I do think Java has a bad rep as a "dry, corporate, enterprise"
| language, but I think there is an ecosystem around Java that is
| pretty awesome and you can build incredible applications with
| Java if you want to.
|
| Java has a branding problem. Java (and Oracle) missed the wave of
| the last 15 years when tech became "cool." If you were new to
| tech/programming and wanted to pick up a language, which of these
| three would you pick, based on the website?
|
| - Java: https://www.java.com/en/
|
| - Kotlin: https://kotlinlang.org/
|
| - Scala: https://www.scala-lang.org/
|
| Java just doesn't have the cool factor that other languages have.
| A little rebranding could go a long way to reinvigorating the
| language in the eyes of newcomers. And I say that because the
| author of this blog post is a newcomer. Experiened developers
| know that, despite the ugly Oracle branding, Java is a good
| language with a sophisticated ecosystem of tools surrounding it.
| He seems to be mostly enamored with the developer experience of
| IntelliJ + Java + Maven. And while it is great, that experience
| is possible with most programming languages.
|
| Disclaimer: I haven't used Java since my early University classes
| 10+ years ago.
| Jaxkr wrote:
| I actually laughed out loud at the Java.com homepage. I was so
| surprised, I expected a sleek, modern homepage but instead I
| got a portal to 2010.
| toyg wrote:
| That's more like 2000-2005. By 2010 we had GMail and clumsy
| 3d gradients were on their way out.
| systemvoltage wrote:
| To be fair, lots of websites were far better in 2010 than
| today's white space filled, massive typography, bright
| colored potpourri of rounded corners, scroll jacked bullshit.
| Full screen, infinite scroll, hamburger menus. So many awful
| contemporary design choices.
|
| Don't pool it all together with this Java website - which
| sucks but not because it was from 2010.
|
| I abhor and loathe modern web design.
| Jaxkr wrote:
| I love old web design too. Sometimes I go look at 2007
| WorldOfWarcraft.com on Archive.org to enjoy old design.
|
| I just remember the Java.com homepage from visiting it in
| computer lab in 2011 so I could play Minecraft.
| tmerr wrote:
| You weren't kidding. The page has barely been tweaked since
| 2008 https://web.archive.org/web/20080701171554/http://java.c
| om/e...
| kasperni wrote:
| The website is a leftover from when you had to download Java
| to run programs. Microsoft Silverlight homepage have a
| similar simplistic feel[1]. I expect it to be updated at some
| point once there is no need for people to download a JRE.
|
| [1] https://www.microsoft.com/silverlight/
| thrower123 wrote:
| I maintain that that lull between 1.6 (2006) and 1.7 (2011) did
| a large amount of harm to Java. Changing too fast is bad;
| stasis is also bad. They've played catch up pretty well with
| features that proved themselves useful in other languages quite
| well in recent years, but it really fell behind over that five
| year stretch.
| twic wrote:
| This is a funny comparison, for sure.
|
| What is really going on here is that there isn't a " _the_ Java
| website ". There is no single organisation or project behind
| Java which could put such up a website. Similarly, where is the
| C++ website? The C website?
|
| java.com was originally the website aimed at end-users who need
| to install Java to use desktop applications written in Java. It
| looks like it's from 2010 because that's when the last of those
| went extinct.
| dcchambers wrote:
| That's a good point, but the various Java JDK websites,
| intended for developers, really aren't any better.
|
| - https://www.oracle.com/java/technologies/javase-
| downloads.ht...
|
| - https://jdk.java.net/
|
| - https://openjdk.java.net/
| jopsen wrote:
| Is javadoc any better these days?
| veltas wrote:
| C++ website: https://isocpp.org/
|
| C website: http://www.open-std.org/jtc1/sc22/wg14/
| oftenwrong wrote:
| This is both hilarious and a great point. Java has no "cool
| factor". HN headlines will add "written in
| Rust/Go/Julia/Elixir" for coolness points. If you put "written
| in Java", it would actually make it seem less cool.
| joshxyz wrote:
| When I tried android dev I jumped to Kotlin because it's well
| presented Lol
| philonoist wrote:
| Off tangent: Is C# hated for the same reasons people here dislike
| Java for?
| pjmlp wrote:
| Kind of, never touch anything made by M$. /s
| BiteCode_dev wrote:
| For my use cases, Java has all the wrong compromises:
|
| - not high level enough to compete with Python/Ruby/JS/PHP, etc
|
| - not low level enough to compete with Rust/D/Nim/Zig
|
| - not specialized enough to compete with Erlang/R/Go/Julia
|
| - not opinionated enough to compete with Lisp/Haskell
|
| So why use Java ? It's good, it's fast, it's productive, it's
| well supported, battle tested and documented for decades with a
| huge pool of devs. And many companies already use it and the
| tooling is excellent.
|
| But those are not sufficient reasons for me.
|
| Python is older than Java, well supported, battle tested,
| documented with a huge pool of devs. But it's way better for high
| level stuff, data mangling, scripting, gluing, and for most web
| dev stuff.
|
| If I want a distributed system or something with a lot of I/O,
| Erlang and Go will always be better than Java. Sure, they are
| less widespread, with all the stuff it implies, but for such a
| nice need, I will pay the price hapily: my goal is optimization
| for the use case. Same for stuff that needs to go fast or have a
| small footprint, I'm not going Java if I can go Rust.
|
| If I want to have fun, Java is out of the loop. Better sharpen my
| inner weirdness by fighting with some exotic lisp. Why try
| productive ? I wanna enjoy myself, not run a business.
|
| So Java is not a bad choice. It's an excellent tech. I just don't
| have a use case for it.
| chasd00 wrote:
| To me Java is like a garbage truck. You get to work, start it
| up, do a nearly invisible but absolutely essential duty, then,
| at the end of the day, you turn it off and go home.
|
| No one dreams about garbage trucks or puts one in a car show
| but they're there and ready to go right back to work when you
| are.
| goto11 wrote:
| Your premise is that you are able to chose a language based on
| how appropriate it is for a specific use case. This alone shows
| you are not the typical user of Java!
|
| Java is typically used in larger or long-lived organizations.
| It is rare to start new projects from scratch. Most development
| is maintenance and extension of existing systems. Even if you
| start a greenfield project, it would be most prudent to chose
| the same platform and language which is already used in the
| organization. An alternative language would not only have to be
| better, it would have to be _very significantly_ better to make
| up for the overhead and headache in maintaining code in
| multiple languages - never mind the increased difficulty in
| hiring and training developers.
|
| Geeks tend to evaluate language based on how appropriate they
| would be for a greenfield project with no organizational
| baggage. But this is an extremely rare use case for most
| business.
|
| HN often has reports about startups rewriting everything from
| scratch every four months, when a new language or platform
| becomes fashionable. But this is not the world where most
| developers live.
| BiteCode_dev wrote:
| Yes of course, don't fix what's not broken.
|
| It's orthogonal to my point though.
| ascagnel_ wrote:
| > Even if you start a greenfield project, it would be most
| prudent to chose the same platform and language which is
| already used in the organization.
|
| Anecdotally, I see a trend of greenfield projects moving from
| Java to NodeJS. I can't think of too many organizations that
| have zero web presence, and basically any modern web presence
| requires the use of JS, so there's almost always some JS
| expertise built into the organization.
| Pet_Ant wrote:
| > there's almost always some JS expertise built into the
| organization.
|
| That is usually part of the front-end team that don't do
| the backend SQL work. Tho team that would get assigned the
| work for a backend greenfield would be versed in Java.
| Retric wrote:
| It's surprisingly rare for things to split like that. At
| most companies people will be more skilled at front end
| or back end work, but it's rarely a clean separation with
| front end vs back end teams.
|
| That's an outgrowth of most projects being quite small.
| Paying a team or 20+ people to work on one thing is
| freaking expensive to the point where it needs major
| benefit or huge company to be worth it. On the other hand
| maintaining lots of little projects that all automated
| something can easily pay for a single developer at even
| fairly small companies. Across tends of thousands of
| small and midsized companies you get a lot of such teams
| which grow and shrink, split off and merge over time.
| spacemanmatt wrote:
| > It's surprisingly rare for things to split like that.
|
| THIS. The product is blended and so must the teams be.
| Among all the full-stack developers I've worked with, the
| "frontend" or "backend" designators tended to describe
| preference or strength, rather than limitation.
| relaxing wrote:
| Those are pretty strong assertions with no statistics to
| back them up. It doesn't reflect the ecosystem I work in.
|
| I think you underestimate the number of huge companies
| that see major benefit from large teams working large
| development efforts.
| Retric wrote:
| I don't know where you would even look for that kind of
| statistics for companies that might use Java. That said,
| America has:
|
| 1,829,875 companies with 5-9 employees 779,922 companies
| with 10-19 employees 467,634 companies with 20 - 49
| employees 170,749 companies with 50 - 99 employees
|
| Of that a few are pure software companies, but it's far
| more common to want to automate something. Which often
| means outsourcing it, but then they simply can't afford
| these kinds of large projects.
|
| At the other end only 23,553 companies have 1,000+
| employees. Yet even at that scale it's not guaranteed to
| have large development teams in house, a single hospital
| can have 1000+ employees and use mostly 3rd party
| software with a few generalists to stitch everything
| together.
| throwaway189262 wrote:
| Development is going the other way at my org. Our JS
| services quickly became "out of date", and nobody wants to
| put in the massive effort required to bring them up to
| modern JS language features, build tools, and libraries.
|
| In contrast, our Java upgrades remain painless. Many of our
| JS services have been merged back into older Java back ends
| dunefox wrote:
| > So Java is not a bad choice. It's an excellent tech. I just
| don't have a use case for it.
|
| The language is underwhelming, the JVM is great.
| hannasanarion wrote:
| It is, but if all you want is a JVM, Java is still probably
| the worse choice over Scala or Kotlin
| dunefox wrote:
| Yeah, absolutely. It's objectively worse than most
| languages.
| bitcharmer wrote:
| The exact opposite is true. Scala's and Kotlin's syntactic
| sugar comes with tonnes of overhead and additional
| allocation. Java is pretty raw compared to them and allows
| you to stay closer to the C-spirit and thus retain more
| control over the side effects of the code you write.
| smabie wrote:
| You can write Scala to pretty much just look and run like
| old school Java if you want.
|
| I haven't seen any benchmarks, but I doubt a Scala app
| written idiomatic style would be any slower than the Java
| version written in idiomatic style.
|
| Also, what is this C spirit we are trying to stay close
| to? I'm certainly not interested in any "C spirit"
| bitcharmer wrote:
| The C spirit I'm referring to is the raw, verbose and
| low-level-ish nature of writing code in C. For high-
| performance/low-latency Java apps it is absolutely
| crucial to have this level of control over code and
| resulting instructions emitted by the compiler. On the
| other hand - if you don't care about it and want to focus
| on domain-level stuff you absolutely can. This is what I
| find the most appealing about Java.
| christkv wrote:
| Kotlin solves most of the problems for us while leveraging the
| benefits of the JVM.
| BiteCode_dev wrote:
| JVM != Java.
|
| We are talking about Java as a language, not the JVM as a
| platform.
|
| You can also run Python on the JVM.
|
| Although, some Java compromises are definitely linked to the
| JVM.
| KptMarchewa wrote:
| >You can also run Python on the JVM.
|
| Jython is stuck on 2.7 and unmaintained.
| vips7L wrote:
| Graal's implementation of python is maintained and up to
| date with python 3.
| dagw wrote:
| Are there many companies seriously using Kotlin for large
| projects outside of the Android space?
| hagy wrote:
| Cash App uses Kotlin Multiplatform, including server-side
| code, https://kotlinlang.org/lp/mobile/case-studies/cash-
| app
| jicea wrote:
| Yes, our stack is Spring Boot + Kotlin on the back side,
| TypeScript + Vuejs on the front. We've millions of unique
| visitors each month, and we're pretty satisfied with the
| stack.
| RhodesianHunter wrote:
| Google, Amazon, hundreds of F 500's
| throwaway10110 wrote:
| Yes
| LennyWhiteJr wrote:
| Absolutely. Kotlin is *widely* used for backend code at
| Amazon.
| pjmlp wrote:
| Long term, Kotlin will only stay relevant on Android.
|
| They cannot fully embrace the JVM while targeting ART, JS and
| native at the same time.
| RhodesianHunter wrote:
| With respect, you're wrong. I say this because we're now
| seeing widespread adoption of serverside Kotlin at places
| like Google and Amazon. With the support of Google and
| Jetbrains they can target whatever they want.
| pjmlp wrote:
| With respect, welcome to the Kotlin version of #ifdef,
| where language features depend on the underlying runtime.
|
| That 3D graphics library using SIMD and value types from
| JVM on ART or JS?
|
| Good luck achieving the same perfomance and memory
| semantics.
|
| Kotlin/Native has already been rebooted as its memory
| model was incompatbile with JVM libraries.
| dropofwill wrote:
| It's worked out ok for scala (though i don't think anyone
| cares about it for android). Obviously a lot of code that
| only works on the JVM, because a lot of people just don't
| care about native/js. But most core libraries will have
| 'shared' pure scala code and then have the platform
| specific implementations in separate folders. This is all
| fairly standardized with sbt plugins to do all the heavy
| lifting.
|
| From the app side you just don't use classes that you
| can't use?
|
| It will be interesting to see how things like Valhalla
| and Loom will pan out.
| johnnycerberus wrote:
| How is Kotlin going to support the SIMD interface? It
| really sounds like #ifdef for every platform,
| unfortunately.
| sarsway wrote:
| What's the state of server-side Kotlin now, is it usable and
| what kind of JVM are cloud hosts running it on? Kotlin seems
| like one of the best languages out there.
| jcadam wrote:
| We're using Kotlin with Spring at the moment and everyone
| on the team prefers it over Java. I suggested Kotlin when
| they laughed at my suggestion of using Clojure. Ah well.
| christkv wrote:
| We use it in production with spring boot and deploy a
| single jar file on azure. Works pretty well
| RhodesianHunter wrote:
| Not only usable, but becoming very widely used. It's no
| different from Java for deployment.
| LennyWhiteJr wrote:
| Kotlin is _widely_ used internally at Amazon. In both AWS
| and retail.
| wwn_se wrote:
| Python projects that start to grow has a tendency to become
| hard to manage in a way that I have not seen in Java at all.
|
| Java is like you say not the greatest at anything but it is
| also not the worst at anything. Its great for projects where
| the you don't know what you should optimize for or don't care.
|
| If java is to boring maybe kotlin is the way to go. I really
| like kotlin and in my personal experience the only downside is
| that the IDEs is not as good as the java counterparts yet.
| andrepd wrote:
| Python is good for quick projects, but if you're writing a
| project with more than 2000 lines of python something's going
| wrong. The apparent ease of python becomes an unmanageable
| web of complexity. In the end you woukd have less headaches
| if you just used a proper statically typed language.
| BiteCode_dev wrote:
| Dropbox, Youtube, Google, Instagram and NASA tell a
| different story.
|
| And me too.
|
| Scaling a Python project complexity is not harder than
| scaling Java, the things you have to be careful about are
| just different.
| cs-szazz wrote:
| I used Kotlin in a large codebase, and one of my only
| complaints is the compile times. We use Gradle for our build
| system, and relative to Java it is slooowwww. But we like the
| other benefits of Kotlin, so it's worth it in the end. But if
| they could get compile times down, it'd be the perfect
| language imo.
| stepbeek wrote:
| How large is the codebase? I moved to kotlin from scala and
| find the compilation to be rapid in comparison.
|
| Fwiw, I'm normally on a beefy desktop so I might just be
| brute forcing this issue.
| cs-szazz wrote:
| 11,503 files, 1,431,195 lines of code. (spread out over
| <50 Gradle modules).
|
| I think the main problem is that Gradle doesn't have the
| same support as Java for ABI compatible changes, so
| invalidation of modules are more common.
| mnw21cam wrote:
| I write software in Java. I can't _stand_ python - too wishy-
| washy.
|
| But my main complaint about Python is trying to use someone
| else's software. Then it degenerates into a maze of twisty
| little passages of trying to install the correct set of
| dependencies, not knowing where those files are installed
| (which makes it difficult on a cluster, as you may need to do
| the install on every node separately). Then you try using pip
| and it fails because some element of what it is trying to
| install isn't compatible with your operating system for
| reason 1. So you try anaconda instead, and that fails in a
| different way, like it runs a C compiler on some file (!?)
| which fails because $REASON. I have numerous examples of
| Python software where I have followed the (detailed, precise)
| installation instructions, and it doesn't work.
|
| Whereas with Java, you just dump the necessary jars into a
| directory, include them in the classpath, and it works.
|
| Don't get me started on R.
| jitix wrote:
| Most python software use the standard venev setup with pip
| and requirements.txt, and most java software are
| distributed as fat jars. Nobody manually sets up
| dependencies anymore.
|
| As a Java/Python/Go developer I can say that packaging is a
| solved problem as of 2021.
| MrPowers wrote:
| Python's packaging is a lot better with Poetry. Use Poetry
| and build the wheel with poetry build. The lockfile lets
| you create an exact virtual environment.
|
| Like you mentioned, wheel files are not nearly as
| customizable as JARs. You can easily pick & choose the
| dependencies to include in JARs (fat JARs) and change
| namespaces of dependencies via shading to prevent
| collisions.
|
| I've generally found it easier to add JARs to Spark
| clusters compared to attaching wheel files to PySpark
| clusters.
| dunefox wrote:
| I'm all for a good project-based package manager for
| Python, but I have tried Poetry several times over the
| last years and not once has it worked as intended. It
| always failed to install packages for some reason.
| the_gipsy wrote:
| Java is so much worse on this front.
|
| > with Java, you just dump the necessary jars into a
| directory, include them in the classpath, and it works.
|
| Ant, maven, or gradle, and then some jars, somewhere?
| What's the classpath and whats $JAVA_HOME for this project?
|
| Oh and now I have to make it work in the IDE too, click
| through a billion menus and dialogs, sync the build system,
| sync the dependencies, configure runtimes and classpaths,
| try to rebuild for the 10th time, pray.
| ivan_gammel wrote:
| Well, this could be true for some legacy projects with
| old tooling, but this is not how things work today. You
| install the IDE, checkout the code from Git and let IDE
| get a proper version of JDK for you and fetch
| dependencies from Maven central to local repo. You really
| should not copy jars anywhere or set environment
| variables.
| bengalister wrote:
| I have done 10+ years of Java development and 1 year of
| Python. And I disagree, Java packaging is better. You can
| package all your dependencies in a fat jar like Spring
| boot does and you only need to run it with java -jar
| lib.jar and you are good to go.
|
| Dependency management is a mess in the Python world and
| my number 1 complaint. You have pip, pipenv, poetry,
| anaconda, to manage your 3rd parties. And if you want to
| avoid conflicts and have consistent runtime you need to
| create a virtual environment to install these libraries
| and redownload everything.
|
| Otherwise libraries are installed user or system wide, in
| a directory that depends on the Python version that you
| use but they are not versioned there.
|
| With Maven you don't have the issue. Your 3rd parties are
| downloaded in a global cache directory (the Maven repo)
| and are all versioned. For the delivery you can either
| provide them all and have the runner set the CLASSPATH or
| have them packaged into a single jar.
| the_gipsy wrote:
| Great, but you will actually want to write some code, so
| you have to do this insane IDE setup clickfest.
|
| I am not saying Python's packaging is any good, it sucks.
| But you can't realistically ignore Java's IDE shitshow.
| kaba0 wrote:
| It's pretty much an import project and done. If not, then
| someone really fcked up that build file.
| watwut wrote:
| > Oh and now I have to make it work in the IDE too, click
| through a billion menus and dialogs, sync the build
| system, sync the dependencies, configure runtimes and
| classpaths, try to rebuild for the 10th time, pray.
|
| That is not my experience at all. I dont have to rebuild
| work project many times. Creating new scratch project for
| playing in is easy and fast. Dependencies are managed by
| maven and I rarely have to deal with that beyond added
| dependency tag.
| matsemann wrote:
| Huh, as a consultant having touched many java code bases,
| they are all basically the same. Import the maven pom
| into intellij and run the main class. The folder
| structure, the code conventions etc are basically the
| same at every client and every project I've ever seen in
| java.
|
| All needed is having the correct version of Java, and
| maybe give maven a password so it can access private
| libraries. It's dead simple.
|
| And more importantly: it's the same everywhere.
| oblio wrote:
| Yeah, people under-estimate badly how useful the Maven
| conventions are, because they've never seen them in the
| C/Python/whatever world.
|
| I haven't used Maven in a bunch of years.
|
| But source code goes in src/main/java. Test code goes in
| src/test/java, resources (images, files, whatever) go in
| src/main/resources, test resources go in
| src/test/resources. There is a pom.xml file that contains
| dependencies, and if it doesn't, it points to a parent
| which <<does>> contain them.
|
| There might be submodules and they all are folders
| containing another pom.xml. That pom.xml generally points
| to the main pom.xml.
|
| Etc. There's a bit of tedium in there, but <<it's always
| the same>>!
|
| The level of consistency is something most ecosystems
| dream about.
|
| And you know what? That means that you can use your spare
| brain cells for actual creativity or hard work.
| jsiepkes wrote:
| Nobody has started a project with Ant in the last decade.
| Of all the Java projects on Github Ant is probably not
| even 1%.
|
| > Oh and now I have to make it work in the IDE too, click
| through a billion menus and dialogs,
|
| You click "Project from existing sources" in IntellIJ and
| it will recognize both Maven and Gradle projects and just
| work?
|
| Sync the dependencies? configure runtimes and classpaths?
| What? With Maven and Gradle? Your talking Ant here.
| the_gipsy wrote:
| I'm talking about a maven project I have to use sometimes
| at work. Let me walk you through all the shit I had to
| do: - Install and set the right java
| version system-wide - Copy some config files for
| the project system-wide (granted, this is not java
| specific, but still) - Click in some IDE menu to
| enable some build settings - Click in some IDE menu
| to install some "Lombok" plugin - Click in some IDE
| menu to select the right jdk - Click in some IDE
| menu to edit the run configuration: - select main
| class - paste program args - paste env
| vars - select right "Use classpath of module:"
| option - Click in some IDE menu to fiddle with
| "Spring Loader path": modules, dependencies, reorder the
| dependencies (!) - Click in some IDE menu to
| configure getting the actual logs - Click maven-
| sync, rebuild-project multiple times, restart IDE until
| it suddenly works
|
| The first guy who got it to work had to write a guide
| with screenshots!
|
| I know you will say, this is all fault of whoever made
| this crap project, or my fault for not fixing it. However
| this was my experience, and it has been similar every
| time in my life that I had to touch some java project
| (although this last one is the worst).
| ivan_gammel wrote:
| I can find maybe only one or two things from this list
| related to Java, both not reflecting current state of
| affairs. You do not make the need to have a run
| configuration a language or platform fault, do you?
| dunefox wrote:
| This is one of the main reasons why I won't work with
| Java. Everything is much more complex and unnecessarily
| arcane compared to other languages.
| KronisLV wrote:
| If you're using IntelliJ from JetBrains, there should be
| an option to store the run profiles for the project in
| the version control system.
|
| Even if your project is so messy, then you should be able
| to just to version a working setup (maybe needing to
| figure out how to make the correct JDK version be used
| across different machines) and after that it'd become a
| question of just having to check out the project from the
| version control system and click a green button in
| IntelliJ.
|
| This most likely wouldn't solve all of your issues, but
| at least would help make onboarding slightly less painful
| and slow.
| Nursie wrote:
| > I know you will say, this is all fault of whoever made
| this crap project
|
| It is. There's really no excuse for that. If it's been
| similar every time then you've worked on crap every time.
|
| Building a java project should be (and is on projects I
| work on) as easy as installing a jvm and running either
| maven or gradle to build it. End of story.
|
| "Install some lombok plugin" is only necessary if you
| want the IDE to understand lombok, IntelliJ will just pop
| up a box saying "Want this?" and you click "Yes". I don't
| see what's so onerous about that.
|
| The rest you describe is really down to poor developers.
| shoemakersteve wrote:
| No offense, but regardless of how right you might be, you
| come off as a bit of a condescending asshole. Like "Oh,
| you don't know that there's a more efficient way to do
| things? There can't possibly be any explanation other
| than you're literal human garbage and presumably have
| brain damage!". Come on, get off your high horse.
| Nursie wrote:
| I'm really not on my high horse here, if you have a team
| working on a java project that's that hard to build,
| they're doing it wrong. Doesn't even matter what the
| language is really.
|
| So "no offense", but shove it.
| liveoneggs wrote:
| You say this as if python could do any better
| towndrunk wrote:
| I think you work at the same company as me!
| kaba0 wrote:
| > I know you will say, this is all fault of whoever made
| this crap project, or my fault for not fixing it. However
| this was my experience, and it has been similar every
| time in my life that I had to touch some java project
|
| Yeah that's a crap project. My experience was always that
| mvn install / ./gradlew run will just work. On all three
| OSs. And if I happen upon a decade old random jar file,
| and run java -jar something.jar, it will just work in the
| great majority of time. I think no other platform has it
| this smooth.
| sixbrx wrote:
| IDE's can be fiddly, and anyway I don't think it's good
| to depend on an IDE for building.
|
| The project could have been set up instead with the
| "Maven wrapper"(1) which provides "mvn.cmd/sh" scripts at
| the top level of the project to fetch and run the proper
| Maven. So after cloning the project, all you have to do
| is set a proper JAVA_HOME if it's not already set, and
| then do "./mvn clean package" at the top of the project
| to do a complete build. The IDE's will then set
| themselves up properly if you import the project as a
| Maven project, and will sync with changes to the Maven
| pom.xml whenever it changes (Intellij does at least).
| That's really hard to beat.
|
| (1) https://github.com/takari/maven-wrapper (Being
| integrated into Maven itself soon).
| the_gipsy wrote:
| I can (and often do) build from CLI, that is much
| smoother. I tried using vim on java, but honestly you
| need an IDE for all the constant code generation and
| incessant fixups by mouseclicks that are needed. Vim+coc
| is more than enough in the other languages that I use.
| dboreham wrote:
| You're living in a parallel universe from the rest of us.
| IDE isn't necessary (and positively odd) for building
| Java.
| the_gipsy wrote:
| You do need to be able to build from IDE when you set
| breakpoints to debug.
| Hackbraten wrote:
| Your IDE should be able to connect to any JVM that has
| been launched with the proper VM arguments.
|
| We occasionally do remote debugging at work. It's just a
| matter of copy/pasting the correct JVM incantation into
| the IDE.
| Hackbraten wrote:
| I feel the parent comment was about editing, not
| building.
| vips7L wrote:
| He is. VsCode (or any editor) + the Eclipse Language
| Server is more than enough. His complaints about
| debugging is because he doesn't know about attach
| debugging.
| oblio wrote:
| I've interacted to a ton of Java projects. And with a ton
| of various other commercial and Open Source projects.
|
| In my experience (sample size of hundreds of projects),
| Maven projects are <<by far>>, on average, easier to
| build and manage than most other languages. The repo
| structure is standardized, the build cycle is
| standardized, the built packages are always in the same
| place, etc.
|
| The Java installation is a 1-time think. It's also a
| quick google away. I see this complaint a lot, I never
| understand it. It's plain and simple bikeshedding:
| someone complaining about a 1-time task that takes 5
| minutes in total.
|
| The rest of the stuff is IDE specific and I have no idea
| why you'd have to configure "getting the actual logs"?
| the_gipsy wrote:
| Well Java is arguably one of the most IDE-reliant
| mainstream languages. It's completely unusable and
| unergonomic without the myriad of constant code
| generation and fixing as you write.
|
| Treating the IDE like a separate problem is not realistic
| with java.
|
| With e.g. Rust, I can use vim, vscode, whatever floats
| your boat.
|
| > no idea why you'd have to configure "getting the actual
| logs"?
|
| Some genius java logging library, I can only guess.
| oblio wrote:
| > Well Java is arguably one of the most IDE-reliant
| mainstream languages. It's completely unusable and
| unergonomic without the myriad of constant code
| generation and fixing as you write.
|
| True, but with IntelliJ 99% of what you wrote is auto-
| configured.
|
| Eclipse needs a bit of hand-holding, but almost
| everything you described is due to project configuration.
|
| > Some genius java logging library, I can only guess.
|
| That's your problem, you're assuming that Java is dumb
| and its libraries are dumb. They're not. I'm reasonably
| sure that <<all>> mainstream Java logging libraries log
| to console by default.
|
| The previous engineer must have been a marvel of a
| developer to manage to screw even that up.
|
| What I'd say is: Java, especially older enterprise code,
| had a ton of over-engineered patterns. These are slowly
| fading away, except for Spring, and even Spring's simpler
| these days. Java also tends to have some low quality and
| a ton of average but unmotivated working devs on Java
| projects. So yeah, there's that ecosystem problem.
|
| But for example, if you'd start a new project and you
| approach Java with an open mind, it's one of the most
| powerful and flexible techs available. And it's much more
| modern than the stereotypes imply.
| Yeroc wrote:
| In my experience even Eclipse does a pretty good job of
| importing Maven projects without needing to tweak things.
| the_gipsy wrote:
| > with IntelliJ 99% of what you described is auto-
| configured
|
| It is not, that's what I'm saying. And I don't understand
| why, if IntelliJ is the de-facto IDE. I'm sure that a
| fresh project is a one-click import, but an average
| project that isn't fresh anymore, always have similar
| IDE-setup-magic problems. At least in my experience over
| the years.
| throwaway189262 wrote:
| IMO it's the other way around. Java has some of the best
| IDE's around so everyone uses them. You can code in
| notepad and compile with maven but why would you?
|
| With Rust you code in VIM because there's nothing better.
| Improving Rust IDE's has been one of the teams big
| focuses for years. Everyone codes in random text editors
| because there's no amazing IDE.
| kaba0 wrote:
| You can write java with vim, without any trouble. It's
| just that Java has the very best IDEs available and I
| would be stupid to not use them.
| furstenheim wrote:
| 100% lombok can only be developed on eclipse. They have
| an open issue to make it compile on intellij...
| matwood wrote:
| I only had to go a few comments to see someone (the
| person you're responding to) think Java is the same as it
| was 15 years ago.
| fian wrote:
| Guess I'm nobody. I created a simple Swing (desktop) app
| in Java a couple of weeks ago. The process was something
| like:
|
| Create new Java project in IDE Add no dependencies Use
| the built in IDE tooling to create a runnable JAR and
| tick the box to export the Ant build to a build.xml file.
|
| Why would I want to complicate things by adding
| Maven/Gradle to the mix?
| oblio wrote:
| And what if you want/need to add dependencies? A lot of
| them.
| fian wrote:
| Sure _then_ you might opt to use Maven or Gradle.
|
| My point is there are a wide variety of application types
| out there, not everything is a web application, not
| everything needs to use a complex build and dependency
| management system.
| oblio wrote:
| Yeah, but if you do know Maven, it scales down to small
| projects. The configuration for a simple project is
| trivial.
|
| So just use Maven and save anyone coming after you a
| bunch of trouble when they have to extend your project
| ;-)
| stepbeek wrote:
| The complexity of maven is well understood and battle
| tested. The complexity of a custom build is not. In my
| opinion it is of a far more concerning sort of
| complexity.
| fian wrote:
| It's an Ant build file - nothing complex at all. If you
| no or few dependencies and are comfortable managing them
| manually, Ant is fine.
|
| Non-networked applications don't tend to need to be so
| paranoid about keeping up to date with the latest
| versions of dependencies.
| lolive wrote:
| I will give you the secret trick of senior developers:
| don't be the one who manages the build process, otherwise
| leave the project asap.
|
| And I will also give you the secret trick of superninja
| senior developpers: be the one who manages the build
| process, so you will never EVER be fired.
| isbvhodnvemrwvn wrote:
| This method is useless for most projects, so yes, you are
| nobody.
| theflyinghorse wrote:
| > main complaint about Python is trying to use someone
| else's software. Then it degenerates into a maze of twisty
| little passages of trying to install the correct set of
| dependencies, not knowing where those files are installed
|
| Java is far worse on this front. Let's take a look at JEE
| or Spring - The entire experience is akin to summoning a
| demon with waving reciting correct incantations in correct
| places while having no idea about what even goes on in the
| background. There are MessageChannels, MessageProducers,
| ClientFactories that interact in mysterious ways and
| initiated in also very mysterious ways. And then there's
| EJB's and their containers which are just blackboxes of
| automagic.
|
| Or how about Hibernate?
| kaba0 wrote:
| Well, it does considerably more things than a hello world
| python app. So at least compare it to Python's full blown
| backend server with ORM and the like.
| BiteCode_dev wrote:
| Django: zero dependencies for years, you could literally
| copy paste the code and it worked, ORM included.
|
| It now has 2 dependencies. It is a 1000 times easier to
| use than hibernate, despite being one of the worse ORM in
| Python.
|
| That the problem with old Java libs like Swing or
| Hibernate: they have been designed for the 90' and don't
| leverage the potential of what a modern Java version can
| do.
| ppod wrote:
| What do you mean about R? Its packaging and distribution
| system is great!
| BiteCode_dev wrote:
| I came to say say that's not a language problem, that's a
| packaging problem. But that would be misleading.
|
| The reason packaging is still a problem in Python are
| linked to the language:
|
| - to get perfs, you need compiled extensions, which java
| doesn't need. So a Jar can be fast and portable, while in
| Python it's an "or" proposition. Wheels help, but they
| still are OS dependent, so you need a build per OS.
|
| - PYZ arrived very late in Python, while WAR were a very
| early thing in Java. Few people even know you can
| distribute a whole Python program in a single zip file with
| dependencies using something like shiv
| (shiv.readthedocs.io). So few people do it, and it's a
| shame. We do it for 0bin though:
| https://github.com/Tygs/0bin/releases. And it doesn't solve
| the wheel problem, although nuitka does but it a higher
| prices to pay.
|
| - packaging tooling have been a mess for 2 decades.
| Setuptools/distutils/setuptools2, easy_install/pip, and
| setup.cfg/setup.py/pyproject.toml. We failed as a community
| on this one. It's getting better, but it's a slow process.
|
| - the Python community is at least half composed of
| amateurs. It's a good thing for the dynamism of the
| community, but it also means the software are not very
| polished. Hard packaging + amateurs = packages that are
| releases when they reach "just good enough" stage, not one
| inch more. It also means you'll get things like leaking
| stack traces, config files in src and the likes.
|
| So yeah, compared to Java, Python packaging and
| distribution sucks.
|
| But compared to rust all packaging and distribution for all
| languages do, so there is that.
| mnw21cam wrote:
| It certainly doesn't help that the software I'm
| interested in is written for science, so there is a
| tendency to make it work just well enough on the author's
| machine to allow a paper to be published, and then
| abandon it.
| KptMarchewa wrote:
| >the Python community is at least half composed of
| amateurs.
|
| or, even worse, scientists.
| michaelcampbell wrote:
| And most recently, tons of self styled "Data scientists".
| This has, IMO, diluted the rabid rhetoric of the
| 90's/oughties python community which is good, but
| replaced it with people who don't know and don't care
| what good code even looks like, so it can be difficult to
| work among them.
| KptMarchewa wrote:
| I feel sometimes that they pride in writing shitty,
| unmaintainable code; that they do it on purpose. One of
| the ways they enjoy life is to disregard all "best
| practices". And I'm not talking about some high-level OOP
| principles, but the basics - like keeping consistent code
| style, or even writing _some_ tests.
|
| The previous crowd with love for monkeypatching
| everything and hate for abstraction other than
| dictionaries wasn't too pleasant, too.
| salixrosa wrote:
| lol I was just sitting here thinking I miss my Python job
| and not having trouble with IntelliJ detecting changes in
| dependencies and how frustrating it is to invalidate
| caches and reindex the whole project multiple times
| before I can run tests for the dependency change. I
| regularly miss the testing libraries we used, too -- it
| was so absurdly clean and easy to build robust mocks in
| our DJango stack (and I set up that tooling, largely on
| my own iniatiative, based on my team's feedback, so it's
| not like I'm just like wishing other people had already
| done the work). Now I work with a bunch of Java devs who
| use to work for Amazon and somehow use that as an excuse
| for not caring about tests, our ci-cd tools, and all
| these other things I'd gotten use to thinking of as
| standard in my past life as a Python dev.
|
| Code style! Hah. First day on the job I asked about that
| and was told nobody cared and everybody had their own
| preferences.
|
| ... I'm very bitter today. I'm working on it.
| newbie2020 wrote:
| Is shiv better than pyinstaller? When turned my script
| into a binary with this, it took 10 seconds extra on
| every execution just to start running the script (Eg to
| just print the help message). I found that to be
| unbearable since this was a command line script that was
| invoked anew for every execution
| nonameiguess wrote:
| If you're not already using the --noupx flag for
| pyinstaller, you can probably cut that startup latency at
| least in half. With UPX enabled, the executable has to be
| decompressed every time it is called. The space saving
| tends to be minimal and not worth it, definitely not for
| a CLI where startup latency much more directly impacts
| the user experience.
| BiteCode_dev wrote:
| They don't serve the same purpose.
|
| Pyinstaller builds bundle the python binary with the
| project. It works without a Python installed on the
| system, is not portable and the resulting binary is fat.
| It also can fail in numerous way and be slow, but end
| users will find it the easier to use when they work.
|
| Pyz files just contains python code. Shiv produce them by
| bundling your code and the dependencies, but you still
| need a Python installed on the system to run that. You
| pay the cost of zipping only on the first run though,
| after that, it's unzipped. And their are portable if you
| use no binary wheel. It's light and easy to get right.
|
| In that sense, they look more like War files in Java.
|
| Pyinstaller, like cx_freeze and nuikta are for end users.
|
| Pyz are for devs.
| michaelcampbell wrote:
| > I can't stand python - too wishy-washy.
|
| That's an interesting take; my experience has been (at
| least the community) is quite proudly dogmatic on the One
| Right Way To Do It, for all values of "It".
|
| I also don't like Python, but I think for different reasons
| and perhaps a bit less than you.
|
| Never used R, but I understand it to be quite fiddly.
| dunefox wrote:
| > my experience has been (at least the community) is
| quite proudly dogmatic on the One Right Way To Do It, for
| all values of "It".
|
| This hasn't been true lately. Python is growing ever more
| complex.
| michaelcampbell wrote:
| I hear you and agree to an extent; my suspicion is the
| influx of non-CS self-styled "data scientists" using
| Python for all the ML hype has diluted the historical
| rabidness.
|
| But, for people still working in "computer science-y"
| domains, I haven't seen the historical dogmatism lessen;
| in many cases people are digging in.
| 131012 wrote:
| R is an analysis tool. You don't write software in R.
| timita wrote:
| Well, maybe _you_ don't write software in R. Others can
| write a pretty capable server[0] using just that.
|
| [0] https://github.com/opencpu/opencpu/tree/master/R
| MichaelRazum wrote:
| You are kind of right. Install non standard stuff in python
| is sometimes pain. BUT you can do it absolutely right. Also
| most of the time only few packages make you trouble. So you
| just need sometimes a fix for them. That's it. You even can
| download it and make it completely offline. Instagram is
| running on python... so it is battle tested. By the way, I
| would always try to avoid anaconda in production.
| BiteCode_dev wrote:
| I've seen plenty of even small Java projects becoming hard to
| manage as well. The design pattern hell is a thing.
|
| You know the joke: a dev has a problem, uses Java, and now
| has a ProblemFactory :)
|
| Not to say Java is not a great language for big projects, it
| certainly is well equipped for that, especially because it
| has superb tooling available on the market.
|
| But I've done plenty of big projects in Python, some ended
| badly, some ended great. Not to mentions dropbox, youtube and
| instagram are testaments to Python can be used in large
| projects.
|
| So I don't think Python is unsuitable for big sized projects.
| You certainly do have to worry about different problems than
| in Java, especially for projects that started without type
| hints. In my experience though, you reach less architecture
| dead ends with Python because the language is so flexible
| that a bad decision early on can easily be transformed or
| worked around even very late in the project without much
| fuzz.
|
| So I don't use "size of the project" in my consideration to
| not user Python/Go/Rust/etc over Java.
| slver wrote:
| > You know the joke: a dev has a problem, uses Java, and
| now has a ProblemFactory :)
|
| It's a funny joke, but it maligns a harmless pattern
| identical in FP to a function returning a function.
|
| While FP coders would brag about how awesome high-order
| functions are, we just keep mocking our own style for some
| reason. Factories are very powerful when used right.
| Nursie wrote:
| > You know the joke: a dev has a problem, uses Java, and
| now has a ProblemFactory :)
|
| I think this joke is probably about as dated as the
| versions of java it was made about.
| BiteCode_dev wrote:
| Unfortunatly, I know a lot of devs that don't even know
| it's a joke.
|
| Singleton is still a design pattern used in the wild.
| drdec wrote:
| The cool devs don't use the Singleton pattern anymore, we
| use @ApplicationScoped.
|
| (Poe's Law disclaimer: yes, that was light sarcasm.)
| Nursie wrote:
| I'm not going to argue there are lots of ridiculous
| patterns out there, which seem to be embraced and
| encouraged by the various frameworks that a lot of
| developers seem to rely on.
|
| Why bother setting things up explicitly in the way you
| want when you can declare things as injected, other
| things as singletons, and then have no real idea why it
| all went horribly wrong?
| BiteCode_dev wrote:
| It's starting to be the same in Python though.
|
| Inertia is huge in our industry, and the HN bubble
| doesn't gives a good picture of it.
|
| Behind corporate firewalls I now see things done the way
| they were 10 years ago: packaging, string handling,
| concurrency...
|
| I assume it's the curse of being popular and old.
|
| And java has been popular for longer than Python, so
| inertia is even stronger. It doesn't matter if it has
| lambda since V8 if people still believe the best practice
| is to pass fat objects around.
| dvdkon wrote:
| Generally the Python codebases I've looked at have been
| more straightforward and therefore more immediately
| readable than Java codebases. You could write a simple
| codebase in Java, but if so many people use it to write
| complex monoliths, maybe the language does have some (in
| my view negative) influence.
| doctor_eval wrote:
| > You know the joke: a dev has a problem, uses Java, and
| now has a ProblemFactory :)
|
| I LOL'd at this joke (again) because it's true, but if
| we're honest, it's also unfair. ProblemFactory is a bad
| idiom, rather than anything to do with Java The Language.
| You could (and IMO, probably should) just use a new
| Problem().
|
| Java The Language was very stable for a very long time, so
| IMO the hype and fads got built on top. First we have a
| constructor - no, now we need a factory, but how to
| construct a factory? I know, let's use another factory! All
| in the same unmodified language.
|
| Likewise, how do we configure an object? First we have
| methods, but languages are cooler, so let's build a DSL, no
| wait let's use a fluent API so it just looks like a DSL!
|
| I one had a dev replace a constructor call with a fluent
| builder, so now _in the single use case where the object
| was ever created_ , we got five LOC where previously we had
| one.
|
| His code was idiomatic, it was bad engineering, but it
| wasn't Java the language.
|
| Java is a pretty great language, but some of the crap
| people stuck on top of it was (and still is) a nightmare
| for readability and reusability. I use Go these days, and
| prefer their more basic approach to engineering, but there
| is much I miss from Java-the-language.
| toomanybeersies wrote:
| > Java is a pretty great language, but some of the crap
| people stuck on top of it was (and still is) a nightmare
| for readability and reusability
|
| I think that applies to literally every language. Bad
| programmers write bad code, regardless of whether it's
| Go, Java, Python, Bash, or Assembly.
| dragonwriter wrote:
| > I LOL'd at this joke (again) because it's true, but if
| we're honest, it's also unfair. ProblemFactory is a bad
| idiom, rather than anything to do with Java The Language.
|
| The Factory pattern's pervasive use in Java was in large
| part a fairly direct consequence of JavaBeans requiring
| nullary constructors, so that the normal constructor work
| for a Bean had to be done elsewhere, i.e., by a Factory.
| Now, Beans was just a core part of the first-party
| enterprise framework that was central to the ecosystem
| and not strictly part of the language, but its not
| completely unrelated, either.
| doctor_eval wrote:
| I'm not going to say you're wrong because you are
| probably right :) but I don't remember things happening
| in that order. JavaBeans was a super early Java spec and
| it introduced some (IMO) poor idioms, such as the mandate
| to use getters/setters. And I certainly agree that
| JavaBeans had a huge influence over the rest of Java
| culture (for the worse IMO).
|
| But my memory is that pervasive use of Factories came
| along many years later, and seemed to be driven by the
| perceived needs of TDD, for example to provide instances
| of mock classes in unit tests. And I thought the factory
| pattern itself came from the GoF, but I might be
| misremembering.
|
| That said, I'm not trying to contradict you. It's likely
| that there was more than one driver for the pervasive
| adoption of factories. In any case it was a bit of a
| nightmare for a while, hopefully things are improving
| there now.
| dragonwriter wrote:
| > And I thought the factory pattern itself came from the
| GoF, but I might be misremembering.
|
| It did, and GoF certainly influenced OOP outside of Java,
| too. But EJB created a need into which the Factory
| pattern was really the only solution. (GoF precedes EJB
| and even Java.)
|
| But certainly its not the only thing; Java hit popularity
| right around the time GoF was most influential; OOP
| languages whose ecosystems developed earlier (e.g., C++)
| or later (e.g., C#, though GoF-heavy code isn't unheard
| of there) wouldn't be as influenced by it, all things
| being equal. Java just had the perfect combination of
| language features, early specs like JEE (which included
| Beans), and timing to be naturally inclined for maximum
| naive GoFism.
| cbm-vic-20 wrote:
| On the other hand, JavaBeans was a simple pattern to
| understand and use, and the old OO dream of "software
| components that can be plugged together" actually worked:
| it was not uncommon for JavaBeans-compliant classes to
| work well together, even if the development teams never
| even heard of each other.
| pydry wrote:
| The crap people created on top was typically responses to
| deficiencies in the language, whether they knew it or
| not.
|
| Stuff like "everything is a class".
| BiteCode_dev wrote:
| Design design does lead community culture.
|
| Java also had the unfortunate destiny of becoming popular
| at the time where "OOP all the thing" was a mantra in
| tech circles. Also design pattern were all the rage.
|
| Those things have a huge inertia, and while Java is not a
| much more flexible language, the image stuck, to the
| point that new comers still implement singletons in the
| wild.
| pydry wrote:
| Java created that hype to market itself. OOP all the
| things probably wouldn't have been a thing without it,
| for instance.
|
| It was very much a marketed language and a language
| designed to be sold to top heavy corporations. This
| fueled a lot of the crappy design decisions, the hype and
| the culture.
| dragonwriter wrote:
| > Java created that hype to market itself. OOP all the
| things probably wouldn't have been a thing without it,
| for instance
|
| "OOP all the things" predated (and led to) Java, it
| wasn't a product of Java (C++, Objective-C, Object Pascal
| and, well, a bunch of other things from the late 1980s
| and early 1990s were where it got started.) Java was
| about a decade into it.
| pydry wrote:
| There's a big difference between "OOP is cool" (which
| Java didn't invent) and "OOP ALL of the things".
| dragonwriter wrote:
| > Java also had the unfortunate destiny of becoming
| popular at the time where "OOP all the thing" was a
| mantra in tech circles.
|
| Java was a product of "OOP all the things", it wouldn't
| have existed without it.
| doctor_eval wrote:
| I don't think that's true at all. Like most languages,
| Java has its share of deficiencies - I'd personally put
| null handling, type erasure and brain dead Optionals near
| the top of my list of things I'd change if I was King of
| Java - but fluent APIs and factory methods didn't even
| start with Java, and have nothing to do with "everything
| is a class".
| Pet_Ant wrote:
| What is wrong with Optionals?
| blacktriangle wrote:
| I have a saying for that: design patterns are a language
| smell.
| pydry wrote:
| Ha. Good one.
|
| I'm absolutely convinced that's true for some of them. I
| was never 100% convinced it was true for _all_ of them.
| BiteCode_dev wrote:
| Yeah I was teasing a bit.
|
| Same goes for Python. Reading the hacky code of a
| geographer for his SIG system is rarely a fun day.
| doctor_eval wrote:
| Yeah - look it's a really valid criticism about idiomatic
| Java, and is one of a (fairly small) number of reasons I
| prefer Go these days. I ended up writing a heap of non
| idiomatic Java and enjoyed it immensely. But you do get a
| bit tired of going against the grain.
| crazypython wrote:
| > Python projects that start to grow has a tendency to become
| hard to manage in a way that I have not seen in Java at all.
|
| Mypy is excellent. It has two-way type inference like
| Haskell. Good usage means catching almost all type errors
| before running.
|
| So is PyCharm, which is IntelliJ for Python.
| V-2 wrote:
| _" the IDEs is not as good as the java counterparts yet"_
|
| How do you mean? What IDEs are you referring to? Kotlin is
| fully (and very well) supported in IntelliJ Idea -
| unsurprisingly so, given that it's JetBrains own invention...
| pharmakom wrote:
| You use Java because it is low risk. I think it might be lower
| risk than any other language in terms of design patterns,
| hiring, library support, run-time surprises, etc.
|
| The language itself isn't great though. Java solutions tend to
| be bloated and make it hard to decipher the underlying domain
| logic.
|
| I certainly wouldn't pick Java for a small team of experienced
| developers.
| yoneda wrote:
| I generally agree, except the part about the low risk of
| runtime surprises. Java's type system is so weak that it
| doesn't even prevent null from inhabiting almost every type.
| The programmer is then forced to manually reason about when a
| value can be null or not, and of course humans can easily
| make mistakes in doing so. This inevitably leads to
| NullPointerExceptions at runtime when a project becomes
| sufficiently complex. Type systems of "low risk" languages
| prevent such mistakes by offloading this kind of error-prone
| reasoning from the programmer to the machine.
| saagarjha wrote:
| > Java's type system is so weak that it doesn't even
| prevent null from inhabiting almost every type.
|
| "So weak"? You do realize that this is basically where
| every language was less than a decade ago?
| KptMarchewa wrote:
| I like Java, but that's weak argument.
|
| We're in 2021, not decade ago.
| kaba0 wrote:
| And java has excellent static analysis, so if you want to
| you can prevent every single npe.
| Pet_Ant wrote:
| What language sees wide spread use without at least a
| decade in gestation? Java, ironically, but cutting edge
| languages take longer than a decade before making it to
| the blue collar programmer's floor. I mean the number of
| people that struggle with even stuff like generics still
| is amazing and that has been around for 17 years at this
| point so 10 years is nothing.
| BlargMcLarg wrote:
| Progressively slower development seems like a pretty massive
| risk these days, where not being able to chase a competitor's
| big feature can be the death knell to your company.
|
| Though it seems java in general attracts a culture of slow
| moving bureaucrats which doesn't necessarily translate into
| higher quality (in fact, I'd argue it translates into _worse_
| quality).
| funcDropShadow wrote:
| > Progressively slower development seems like a pretty
| massive risk these days, where not being able to chase a
| competitor's big feature can be the death knell to your
| company.
|
| You are conflating to different layers. Not being able
| chase a competitor's big feature can be the death knell to
| your company, yes. But this does not mean that building
| your business software on stable and proven foundations is
| a high risk. On the contrary you want to be fast moving
| with your business features not with keeping up with
| quicksand under your feet. I.e. a stable well understood
| basis, is IMHO a prerequisite to moving fast above of it.
|
| In addition to my arguments above, one still has to
| consider whether a tool matches the problem. Writing an
| Excel plugin in Java is probably a very bad idea (I really
| don't know, I just assume that anything based on .NET would
| be a better fit), although both Excel and Java value long
| term compatibility. If you want to follow the latest trends
| in AI without really understanding what is going on, it is
| probably best to follow all the tutorial about AI and use
| Python. But if you plan to hire people that understand the
| details of AI libraries, you might come to the conclusion
| that the AI libraries on the JVM also provide the basic
| blocks you need, the higher levels are customized to your
| application anyways.
|
| To come back to the original point, a technology or
| programming language is not good if it moves fast, it is
| good when it fits your problem, doesn't create too many new
| problems, is well understood by you and your team and is
| maintained.
| BlargMcLarg wrote:
| You're the one conflating my argument here. What I'm
| pointing out is this: there's somewhat of an assumption
| that java moves slow yet steady, therefore not generating
| the code mess other languages get blamed for, ending in
| either an undecipherable mess, or degradation of
| development quality and speed. The idea being that java
| makes one more likely to win the marathon in favor of
| losing the sprint. Whereas many other languages can only
| win the initial sprint, become messy, and then proceed to
| be unable to move with competitors anyway later down the
| line.
|
| In practice, I've barely ever seen this assumption truly
| come to fruition. I see java codebases degrade, become
| undecipherable messes filled with reflection, inflate
| themselves to become incredibly hard to understand or
| work with, at similar rates. I still see JSPs throwing
| garbled stacktraces that barely help understand what's
| wrong. Still see business shoot itself in the foot
| because it said "this should never happen", so the code
| is made under the assumption it doesn't happen, because
| null is still available and no one uses optionals, and 2
| months later you have clients show you another NPE after
| going through 15 layers of business-modifying logic and
| people spend a week uncovering how the situation can take
| place (or worse, it is retroactively sealed up and the
| actual bug is still there). If there's some magic spell
| that helps java become less messy than other static
| languages or even some dynamic languages, I have yet to
| see it.
|
| At that point, one has to question: what are we losing
| the sprint for? Are we truly increasing the odds of us
| winning the marathon? Not even its most espoused
| benefits, libraries, write once work everywhere, etc.,
| seem to be remotely unique anymore. The only two answers
| I see, are legacy, and the number of java devs available.
| Lose a java dev, no problem, just pop in another. Want to
| rewrite the app in a different language, or even in less
| verbose, modern java? Good luck convincing management
| firmly believing that a rewrite of one month is more
| costly than pushing out features at 1/10th the speed
| post-refactor for another 2 years.
| kaba0 wrote:
| I highly doubt the progressively slower development claim.
| BiteCode_dev wrote:
| I agree that Java is low risk from a manager responsibility
| perspective: nobody has been fired for choosing it for a long
| time.
|
| Now, from a project success perspective, I think it's not.
| I've seen a lot of Java projects fail, over engineered, full
| of spaghetti code, riddle with inscrutable abstraction, stuck
| in a glue of badly designed architecture that has been
| fossilized by the type system.
|
| I'd say from a project risk perspective, it's a pretty
| average language, it has pros and cons, but they balance each
| other.
| kaba0 wrote:
| Well, law of big numbers. Java is used everywhere. For
| every failed Java project, there is many successful one as
| well. And honestly, chances are that team would have failed
| in any other language as well.
| goto11 wrote:
| I have seen a _lot_ of projects fail over the years, for
| many different reasons, but I have never seen a project
| fail due to the choice of programming language.
|
| > I've seen a lot of Java projects fail, over engineered,
| full of spaghetti code, riddle with inscrutable
| abstraction, stuck in a glue of badly designed architecture
| that has been fossilized by the type system.
|
| Sure, but do you really think the same organization would
| have produced perfect simple elegant error-free code is
| Haskell or Smalltalk (or whatever "better" language you are
| comparing to) under otherwise same requirements, deadlines,
| resources and management?
|
| I'm not saying languages doesn't matter. A better/more
| appropriate language is like having a bigger screen or a
| better chair. All else being equal, it will increase
| productivity and make developers happy. But it will not
| make or break a project. The things that will break the
| project: Bad/unclear specifications, bad management of
| change requests, lack of testing, unrealistic scheduling,
| lack of customer feedback, bad communication or conflicts
| among developers.
| BiteCode_dev wrote:
| It's an anwser to "You use Java because it is low risk".
| I just don't think it's immune in any way.
| chii wrote:
| > Java projects fail, over engineered, full of spaghetti
| code, riddle with inscrutable abstraction, stuck in a glue
| of badly designed architecture that has been fossilized by
| the type system.
|
| these are properties of a poorly designed project, and
| isn't due to it being java.
|
| You may be able to causally link the failure to the people
| on the project being "incompetent" - but that's not really
| the fault of java!
|
| i say java is a pretty good language, if you have large
| teams, with varying levels of competency amongst the
| members. As long as you have somebody good to do the
| overarching design and direct the project, it would do
| relatively OK.
|
| if you have a small, elite team, then it may not be the
| right choice (depending on the team).
| suyash wrote:
| Ever heard a technology called GraalVM ?
| 2ion wrote:
| My main issue is that people writing Java (or for the JVM)
| because of their backgrounds (app-level code printers) almost
| completely disregard how that code works on the JVM, at scale,
| in a highly responsive and/or high throughput service. You
| can't just use a big, "safe bet" framework like spring, which
| taints EVERYTHING in that project, write a simple REST API and
| then do heavy work "in the background" without side effects.
|
| "Running Java" requires detailed system engineering / ops
| expertise specific to how the JVM works and can be tuned, and
| all too often, how specific frameworks internally pile their
| abstractions on top of each other. Problem is, a modern "Java
| app" is a pile of large frameworks and libraries.
|
| As a system engineer, I HATE Java applications written by
| clueless programmers. They are difficult to handle and I often
| have to dig in and fix bad usage of framework features that
| somehow passed code review by equally clueless "senior"
| developers. I then get to spend a day to find out why this or
| that connection pool in there managed by this or that library
| does not handle its connections correctly, just to find the
| magic framework level variable that tunes that specific screw.
| Stuff of nightmares.
|
| Every Java project is also __severely__ underdocumented. That's
| because even if you write documentation for YOUR code, the
| framework has books of documentation on ITS specifics, and
| includes high-level libraries which THEMSELVES have heaps of
| specific documentation. Climbing the tree until one arrives at
| actual standard library calls is like climbing into clouds and
| hoping to see the sun some day.
| cartoonfoxes wrote:
| >"Running Java" requires detailed system engineering / ops
| expertise specific to how the JVM works and can be tuned
|
| > almost completely disregard how that code works on the JVM
|
| As an occasional clueless programmer, I've had occasion to
| touch systems written in Java. Could you point me at some
| resources?
| throwaway189262 wrote:
| IMO terrible Java code is partially due to how good the JVM
| is. Performance is within spitting distance of native code,
| so people can do TERRIBLE things and it won't tank
| performance.
|
| Endless abstraction, loading giant things into RAM, looping
| over every item in huge arrays. Blocking server threads for
| minutes at a time. In most languages you would be punished
| severely with awful performance or OOM. Java chugs along
| until things get horrifically bad.
| menotyou wrote:
| > "Every Java project is also __severely__ underdocumented.
| That's because even if you write documentation for YOUR code,
| the framework has books of documentation on ITS specifics,
| and includes high-level libraries which THEMSELVES have heaps
| of specific documentation. Climbing the tree until one
| arrives at actual standard library calls is like climbing
| into clouds and hoping to see the sun some day."
|
| This weaknes stems from Java being OO. On larger projects you
| start to have abstractions which tend to be insucfficiently
| documented or the documentation not being updated with
| changes. Throw in some helper classes here and there, from a
| certain point of complexity of the project from an outside
| perspective the whole thing looks like being obfuscated.
| [deleted]
| kaba0 wrote:
| I think it's not a language problem. Frontend devs can be
| just as clueless, and don't even get started on bad
| programmers writing in low level languages. Basically, the
| reason Java become so popular at the time was the bad
| programmers writing leaking, segfaulting programs in c++. Now
| they write bad programs in Java that "works" when one looks
| at it from an angle and is lucky.
| helsinkiandrew wrote:
| It's horses for courses. Some plus points for Java:
|
| - you can integrate code from hundreds of developers fairly
| safely (knowing that no one has changed the default behaviour
| fo builtins and different dependencies won't clash).
|
| - the syntax, although not the most succinct is fairly easily
| readable and maintainable by other developers.
| reader_mode wrote:
| >the syntax, although not the most succinct is fairly easily
| readable and maintainable by other developers
|
| I dislike that people conflate simple languages with easy to
| read code.
|
| Low level verbose abstractions make code harder to read -
| going through the layers of IFactoryRepositoryLocatorBullshit
| because the language abstractions suck doesn't make it easier
| to read code.
|
| It makes the code more accessible, in the sense that you can
| probably find some 20$/hour devs to read through that and
| spend a day solving something that should take a couple of
| hours most.
|
| Good high level code express the problem domain without
| boilerplate and let's you focus at problem at hand - Java is
| terrible at that.
| acdha wrote:
| > - you can integrate code from hundreds of developers fairly
| safely (knowing that no one has changed the default behaviour
| fo builtins and different dependencies won't clash).
|
| It's exceedingly rare for this to be untrue of Python -- it's
| technically possible to hack builtins but there's intense
| community pressure against doing that.
|
| > - the syntax, although not the most succinct is fairly
| easily readable and maintainable by other developers.
|
| This is sort of true but it misses the aspect which makes
| Java hard to maintain: the language being less capable means
| that you end up with more boilerplate syntax which has to be
| understood when reading it and the patterns that produces
| tend to be the long-term maintenance issue instead.
| kaba0 wrote:
| > This is sort of true but it misses the aspect which makes
| Java hard to maintain
|
| The boilerplate syntax you talk about comes from like java
| 1.4.
|
| Modern Java is quite expressive with streams and lambdas.
| If one does employ the Java Beans convention than yeah,
| he/she has to autogenerate a few getters setters, but those
| don't occlude the actual logic.
|
| And frankly, empirically, Java is anything but hard to
| maintain. You would be hard pressed to find many languages
| that continue to manage at the scale Java apps routinely
| handle.
|
| Yeah, it's (typical business monstrosity) hard to
| understand, probably has many thousands hours of technical
| debt, but it just works, and more things can be added to it
| (and occasionally with much more work, removed as well).
| acdha wrote:
| > The boilerplate syntax you talk about comes from like
| java 1.4.
|
| I was thinking about things I've recently seen in new
| Java 15 code, so no. There are lots of old APIs in the
| Java language and popular libraries, and while things
| like streams are quite powerful, they're far from
| universal. I still see developers cranking out code which
| has to do what is built-in in other languages.
|
| As a simple example, not having multiple return means
| that you end up with worse APIs in some cases or small
| classes which exist to wrap a couple of things -- not
| necessarily terrible but it means that you've just taken
| on maintenance work for something which would be trivial
| in other languages. That extra code isn't exactly a huge
| lift but when you add things like that up regularly it's
| not hard to understand why all of the good Java
| developers I know are keenly following things like Kotlin
| which give more expressiveness without giving up all of
| their familiar tools.
| xdennis wrote:
| It's true that Python programmers don't often hack
| builtins, but they still do things which aren't possible in
| Java.
|
| For example: imports inside functions instead of at the top
| of the file (because the import does work, but the
| configuration hasn't been set up yet).
|
| An example of this is an internal package at my workplace
| which makes a external service request at import time.
| BiteCode_dev wrote:
| It's also True for Go, Rust, Haskell, etc.
|
| But even for Python (which syntactically speaking is probably
| the easiest to read of all the list), if your team scale, you
| just scale the tooling with it.
|
| The Python ecosystem is very rich in tooling for enforcing
| best practices. Poetry will manage dependencies cleanly.
| pylint will let you check that builtins are not overriden.
| Mypy will check for types.
|
| So of course, it's not as good as Java, but again, the post
| is about compromises the language make, which are not the
| proper ones for me, personally.
| fighterpilot wrote:
| Java is great when you need speed approaching Rust/C++ but
| don't actually need to be the fastest.
|
| It's way easier than C++ and will get you 80 percent of the way
| there in terms of performance
| fouric wrote:
| > not opinionated enough to compete with Lisp/Haskell
|
| Interesting - you seem to be saying that Lisp is very
| opinionated. If that was your intent, may I ask why? Your
| experience doesn't jibe with my experience as a Common Lisp
| user, which is that Lisp _isn 't opinionated enough_, and gives
| you too much flexibility (in some cases).
| huonib wrote:
| I think the problem is because of the virtual machine, instead
| of being compiled to an executable. I mean GraalVM is great -
| but why did it take so long to develop? I mean Sun could still
| be alive if developers and users had instant startup times,
| could have easily deployed Java to servers and clients, and
| that it was not only faster but used way less memory.
| kaba0 wrote:
| It didn't take too long, there was AOT compilers available
| two decades ago as well.
|
| There was just not much interest in it, because performance
| gets worth, and startup time is seldom interesting. (Pretty
| much only command line tools would require faster startup,
| and recent serverless)
|
| And memory usage is a tradeoff. Though most of the time java
| could run with almost half of the currently used memory, it
| is unnecessary work to GC if memory is available.
| mnd999 wrote:
| The virtual machine is (was?) the whole point. You can run
| the same binaries on your dev box or your server, whatever
| flavour of server that happens to be.
|
| Startup times are not an issue on servers as processes are
| typically long-lived anyway. It is a bit of an issue on
| serverless (lambda etc.) but that's a relatively new thing.
| High memory usage is generally poor tuning - if you give the
| JVM 1gb it will use it and avoid GC until it needs to.
| Sometimes it's poor coding too, I've seen web APIs accepting
| files as base64 encoded json strings which is horrific server
| side.
| huonib wrote:
| I'm sorry, did you claim poor tuning?
|
| look at this graph:
| https://alvinalexander.com/sites/default/files/inline-
| images...
|
| from: https://alvinalexander.com/scala/graalvm-native-
| executables-...
| mnd999 wrote:
| Graal is very clever, but that memory example is
| nonsense. I just tried the Find example they give and
| whether the graal version beats the java version is
| completely dependent on Xmx.
|
| Obviously I don't have their dataset, so it's not exactly
| the same test.
|
| edit: In fact the numbers in the blog are so far off mine
| they may accidently have been testing /usr/bin/find.
| de6u99er wrote:
| Those are all the wrong reasons in an enterprise environment.
| Seasoned Java developers would laugh at you if you would tell
| this to their face
|
| What I love about Java is, that I can update the runtime
| without being afraid to break something. I also love the mature
| eco system. What's also great is that the compiler catches most
| code issues before you try running your code.
|
| What I don't like is the module support introduced with Java 9,
| which is vastly inferior to OSGi.
| a_imho wrote:
| I have the exact same criticism about Python.
| BiteCode_dev wrote:
| Well, that's the point of opinion isn't it ?
| Nursie wrote:
| Python is generally less performant. Go has a smaller
| ecosystem.
|
| IMHO, YMMV etc.
| jokoon wrote:
| You're right, but:
|
| * performance is not really an issue for most software ("97%
| of the time, premature optimization is evil"). A well
| designed software doesn't suffer from performance issues with
| current computer performance, unless you do AI or bleeding
| edge graphics or science simulation.
|
| * there are ways to speed up performance sensitive parts with
| something else than java, for example by using C/C++, would
| it be with a python module or cython. Not ideal, but
| generally you gain performance by adapting your design, not
| by changing languages. A garbage collector is rarely
| predictable, hence java is not a good fit for performance.
|
| * I remember playing minecraft with friends, and the server
| was regularly crashing because it was out of memory, or
| something like that.
| Nursie wrote:
| The OP brought up performance reasons to choose language.
| :shrug:
|
| > I remember playing minecraft with friends, and the server
| was regularly crashing because it was out of memory, or
| something like that.
|
| I've seen this, but I don't think you can really use one
| server program running out of RAM as indicative of much. I
| do still find the pre-setting of max memory on the command
| line a little bit odd though.
| toomanybeersies wrote:
| Pre-setting max memory seems odd these days, when
| everything runs in docker, with its configurable memory
| limits.
|
| Handling process memory usage pre-docker wasn't so easy.
| pydry wrote:
| Performance as an issue is massively overstated in high
| level languages. CPU intensive hot paths are rarer than
| people think, I/O performance is a bigger deal than
| people think and there's more hyper optimized code
| written in performant languages that you can call
| directly than most people realize.
|
| A lot of graduates think that compsci jobs involve
| optimizing algorithms or some shit coz they did that type
| of thing as undergrads, so they port that attitude
| across.
|
| It's also the reason why pypy was massively hyped for a
| while and then not really used all that much. It was
| solving the performance problems python never really had.
| Nursie wrote:
| It's true, that the situations in which you care about it
| are few. The most recent performance issue I've come up
| against is actually java's startup time, because for
| reasons unknown my client decided java AWS lambdas were
| the way to go, has quite a large, complex codebase built
| around it, and now has complaints about startup latency.
|
| I have noticed some younger engineers on C++ projects
| doing some kooky things "because it's more optimal", and
| have taken time to explain to them that the micro-
| optimisations they're using impact readability, are going
| to be done by the compiler anyway if they're at all
| useful, and are likely to be several orders of magnitude
| less relevant than some lock somewhere, or a bit of IO,
| or whatever.
| CodeGlitch wrote:
| > I remember playing minecraft with friends, and the server
| was regularly crashing because it was out of memory,
|
| Could be a problem with the logic/design of the server
| rather than a problem with Java? Despite memory being GC'd,
| you can still run out of it if you just keep allocating
| stuff. The important thing about Java is that it doesn't
| suffer from the usual C or C++ memory exploits.
| bluetomcat wrote:
| Python code which uses stuff mostly from the standard
| libraries isn't really that slow. Parsing a JSON? Call a
| wrapped C function. Process a media file? Call a wrapped C
| function. If you keep the actual CPU-intensive stuff in C
| code, the ops executed by the Python interpreter can be
| negligent.
| michaelt wrote:
| That Python's performance doesn't matter because you can
| write things in C instead is faint praise indeed.
| BiteCode_dev wrote:
| You don't need to write it. The ecosystem is already
| chock full of compiled extensions. That's kinda the
| point.
| BiteCode_dev wrote:
| Yes, but that's my point.
|
| If I don't need performance, Python is ok.
|
| If I do, I won't go Java, I will choose something that is
| built for performance. Python is good enough for 99% of my
| performances need. The last 1%, jumping to java is not a big
| difference, I'll use rust or go.
|
| I won't use go for the ecosystem, but it's unique
| characteristics: easy concurrency, dead simple binary
| production. Java can't beat that. IF I need an huge
| ecosystem, I'll go Python.
|
| For the need for Java, I would need this very specific sweet
| spot where I need just enough speed, and just a rich
| ecosystem enough to justify it, and nothing that is a killer
| feature in alternatives. And a situation where compromise
| over this is not possible.
|
| It never happens to me, that's all.
| _pmf_ wrote:
| > The last 1%, jumping to java is not a big difference
|
| That's where you're wrong, kiddo.
| BiteCode_dev wrote:
| Oh, I'm afraid I can't claim that sobriquet anymore
| unfortunately.
|
| But that's not the point. The point is that, for the 99%,
| staying on a slower language is ok. For the last 1%, I'll
| skip Java and go to Rust/Go. If I have to do a rewrite
| for perf sake, I'm not going to go half way.
| bjourne wrote:
| But you are not going to get higher performance in
| Rust/Go.
| BiteCode_dev wrote:
| Rust can literally contain inline asm so yes, you will.
| But even without that, the startup time is always going
| to be faster.
|
| And for IO, you will get faster perf in Go more easily.
| Sure, you can finely tune your Java code to get there,
| but it's a lot harder.
|
| It in both cases it will eat up way more memory.
|
| There is a reason Google, that did use heavily Java
| internally, is now moving to Go, a language they custom
| designed for concurrency.
| jvolkman wrote:
| I wouldn't say Google is really "moving" to Go. It's an
| option, but plenty of projects new and old continue to
| choose Java.
| kaba0 wrote:
| Well, project loom will make the JVM arguably a better
| platform for concurrency.
|
| Basically every language is more expressive there (even
| Java), GC is much much better - in benchmarks it is not
| as obvious only because Go avoids creating garbage most
| of the time, but it can't always be avoided; and the
| platform is incomparably richer on the JVM side.
| chriswarbo wrote:
| > Python is good enough for 99% of my performances need.
| The last 1%, jumping to java is not a big difference, I'll
| use rust or go.
|
| Whilst I _roughly_ agree, that 's still a bit too
| simplistic.
|
| In particular, we might prefer something like Rust to write
| a performance-critical algorithm, but that forces us to
| make a decision:
|
| - Do we stick with Rust for _everything else_ (networking,
| data plumbing, etc.)? This forces us to confront the
| ecosystem problem.
|
| - Do we wrap our algorithm as a library for other languages
| (like Python)? This forces us to confront interoperability
| (ABIs, FFIs, cross-language dependency management, etc.).
|
| There's lots of room in between these extremes for other
| pareto-optima, like Java.
|
| Also, we often need to consider latency and throughput
| separately, rather than just "performance". Java is a
| pretty stark example, since it's pretty slow to start but
| reasonably fast when left running (compared to native
| binaries like Rust, which are low latency and high
| throughput, or scripting languages like Python which are
| high latency and low throughput).
| BiteCode_dev wrote:
| Agreed, it's just a general overview, I skipped a lot of
| nuances for the purpose of conveying my main message.
| adrianN wrote:
| Java is orders of magnitude faster than Python for code
| that doesn't spend all of its time waiting for IO. Java
| perf and Go perf are about the same.
| AzzieElbab wrote:
| Even IO heavy code, it is much easier to write
| multithreaded async code for the jvm than it is for
| python
| BiteCode_dev wrote:
| If it's just about I/O, then no, threads in Python are
| super easy: import random
| import time from concurrent.futures import
| ThreadPoolExecutor, as_completed def
| hello(seconds): print(f"Starting hello in
| {seconds}s") time.sleep(seconds)
| print(f"End of hello in {seconds}s") return
| seconds # At the end of this blocks, it
| automatically join() and clean with
| ThreadPoolExecutor(max_workers=2) as executor: # 2 tasks
| in parallel max # this send jobs to
| threads via safe queues a =
| executor.submit(hello, random.randint(0, 5))
| b = executor.submit(hello, random.randint(0, 5))
| # this collect results from queues in order of completion
| # sync is automatic for future in
| as_completed((a, b)):
| print(future.result())
|
| And if about network I/O only, you can get even more
| perfs using asyncio.
|
| Threads in Python are only inferior to Java threads when
| it's about using several CPU.
| acdha wrote:
| > Java is orders of magnitude faster than Python for code
| that doesn't spend all of its time waiting for IO.
|
| It's hard to separate the absolute performance of Java
| the language from Java the culture where inefficient
| patterns or attempts to implement dynamic behaviors in
| some framework code defeat the JIT (not to mention the
| benefits of type-checking). If you have a team which
| cares, it should be faster but the average business app I
| see does not have that team and will, if lucky, perform
| within the same order of magnitude as Python.
| acomjean wrote:
| Having got back into Java a bit recently I was surprised
| how fast it was (coming from python/Perl and php).
|
| Speed doesn't matter always, but when it does it Java
| feels snappy. Our programs our command line based so our
| framework use is limited. Also the built in data
| structures are nice. I still find getting Java's set up
| painful, which is a huge impediment for us using it more.
| kaba0 wrote:
| Well, that same team would have trouble even writing
| complex python apps as well, without types
|
| (yeah I know it has type hints now)
| BiteCode_dev wrote:
| But not Rust.
|
| And Go is better if you do I/O.
|
| That's my points. Compromises.
|
| I'm not saying "Java is bad". I'm saying, "I have no use
| case where I, personally, would use Java over something
| else."
|
| I do know other people have use cases for it.
|
| I just don't, because those compromises don't make sense
| for me.
| pjmlp wrote:
| Where is Rust AWT? Not to mention Swing, JavaFX, or even
| an whole mobile ecosystem.
| BiteCode_dev wrote:
| Well, if we create a desktop app, the Python + C bindings
| will be a better choice for my own project. Easier to
| dev, equivalent perfs, equivalent libs (and the QT Rad is
| excellent).
|
| Java does have android right now, although it has to
| share with ReactNative, Xamarin and flutter. Again, for
| different compromises.
| pjmlp wrote:
| So apparently Rust isn't that better than.
|
| Java also has the IDE ecosystem between Netbeans, Eclipse
| and all JetBrains offerings, with exception of Apple and
| Microsoft offerings.
| BiteCode_dev wrote:
| It's not a matter of better. The original comment is all
| about what compromises work for me, and why I don't have
| a use case for Java.
|
| You are trying to move the debate toward the quality of
| java, which is was never my point.
| pjmlp wrote:
| Not at all, I though your point was how Rust and Go are a
| much better option.
|
| > If I do, I won't go Java, I will choose something that
| is built for performance. Python is good enough for 99%
| of my performances need. The last 1%, jumping to java is
| not a big difference, I'll use rust or go.
|
| So given that, I am curious where are those GUI
| alternatives with the required perfomance in Go and Rust.
| BiteCode_dev wrote:
| So you are in the very niche use case where:
|
| - you need a GUI
|
| - you need perf beyond what Python is capable and you
| identified it clearly in advance
|
| - you can't use numpy / multiprocessing / cython, pypy or
| they won't give you the perf you need
|
| - you can't find a main hotpath you can optimize with a 5
| lines c or rust extension and write 99.99% of your app in
| python. Or you don't want to bother.
|
| If you ever find yourself in this very use case, then
| yes, use Java.
|
| But I never found myself in this very precise use case.
| michaelt wrote:
| To be fair, even people deep in the Java ecosystem don't
| like its desktop application/GUI support.
|
| Its only saving grace is that all other cross-platform
| GUI systems also suck, and if you're doing everything
| else in Java it might be the path of least resistance.
| kaba0 wrote:
| For ordinary desktop apps, javafx is quite good. It's a
| hidden gem in the ecosystem.
|
| (Though I haven't tried its mobile "backend")
| wing-_-nuts wrote:
| Java and Go are roughly equal in performance (seriously,
| look up the benchmarks). If you're using go for it's
| concurrency primitives, kotlin has equivalents.
|
| I got into Go for a while, but if I'm honest, it's a
| kludgey language. Half the reason it has taken off as it
| has is simply down to the fact that it's backed by google.
| Brian_K_White wrote:
| How did you manage to miss the entire point of the comment?
| Nursie wrote:
| I didn't, thanks.
|
| I think that there are use-cases in which java is more
| performant than his low-performance options, and can be as
| performant as his high-performance options, while providing
| a much larger ecosystem.
|
| I think the parent poster actually makes a very weird set
| of choices - "when my high level choice, python, is not
| cutting the mustard, I am happy to throw away breadth of
| support entirely in the name of optimisation."
|
| It's up to him what his preferences are, of course, I'm not
| saying they're wrong as much as personal.
| Brian_K_White wrote:
| Eh, kinda still sounds like you did. Thanks for removing
| any doubt.
| Nursie wrote:
| Perhaps you could enlighten me then? Rather than just
| posting low-effort, content-less, drive-by snark?
|
| The OP even says they're just posting their own selection
| criteria in other comments.
| Brian_K_White wrote:
| Probably I can't.
| Nursie wrote:
| Thanks for your constructive input to the discussion
| then.
| bengalister wrote:
| I agree mostly. Some good use cases for Java:
|
| - cryptography: It has a wide range support of
| symmetric/asymmetric algorithms from legacy to modern ones.
|
| - XML and SOAP with Web Service Security in particular.
|
| - Modeling large business concepts because of static typing,
| Objects inheritance and polymorphism, no memory management
| while still being performant. I would not use Python for that
| but other languages can compete C#, Scala, Kotlin, maybe
| Typescript.
| BiteCode_dev wrote:
| Python and Ruby both would fit the bill perfectly for all
| those use cases for me.
|
| The cryptography module in Python is awesome. lxml and sud
| deals with XML and Soap in a blink.
|
| Modeling large business concept is a joy with dataclasses,
| and the language will never be the perf bottleneck.
|
| Now I understand that if you are experienced with Java, it
| would solve all those problems perfectly.
|
| But again, I would not, personally, gain anything by using it
| for this.
| pron wrote:
| You say Java is not X enough to compete and then list things
| that Java has successfully competed with for years and
| continues to have a very wide lead over _now_ , with the
| exception of Python and JS _in limited circumstances_ -- the
| browser and machine learning.
|
| The reason Java does compete so successfully is that it is high
| level and yet provides a virtually unmatched combination of
| performance, maintainability and observability (including
| always on, low-overhead deep profiling). None of the
| alternatives you mentioned come close. This is why it continues
| to be a top choice at Amazon, Apple, Netflix, Google, Alibaba,
| Uber, Soundclous, and almost all Fortune 500 companies. Saying
| it is "out of the loop" is either wishful thinking or
| delusional, depending on your perspective. It's just not the
| reality.
| BiteCode_dev wrote:
| I'm just exposing my own selection criteria. It's not an
| absolute metrics.
|
| I'm just saying, "to me, that's why I never end up using
| java".
|
| Java is good enough for the vast majority of things. But so
| is Python.
|
| And for specialized things, there are better choices
| available to me.
|
| I'm not a Fortune 500 though.
| pron wrote:
| > But so it Python.
|
| For a very different definition of "good enough," i.e.
| unless you're working on a large codebase maintained by a
| large team for years, need high performance, or need deep
| low-overhead observability. So Java is "good enough" for a
| much wider selection of "serious" (large/mission-
| critical/long-lived/ high-performance) software.
|
| > And for specialized things, there are better choices
| available to me.
|
| That's OK, but in reality Java does very successfully
| compete with almost all the languages you've mentioned; it
| is they that, in practice, find it very hard to compete
| with Java.
| BiteCode_dev wrote:
| Dropbox, instagram, google and youtube all were written
| in Python at some point. Languages don't scale,
| architectures do.
|
| But even when the language became the bottleneck, they
| went the road of rust and go, not the road of java.
|
| Again, not to say Java is not used by those companies
| with great success.
| RhodesianHunter wrote:
| There is an absolute mountain of Java at Google. Pretty
| sure it's the most used language by LOC.
| pjmlp wrote:
| I bet it has more to do with their HQ location and
| feeling trendy than anything else.
| BiteCode_dev wrote:
| Well, it's true popularity in tech is not necessarily
| related to quality.
|
| Trending does have an impact.
|
| But by experience, having a killer feature, and a good
| adoption story usually does much more.
|
| E.G:
|
| - PHP: easy to make web page in 2001
|
| - JS: monopoly on the client side web
|
| - Go: simple concurrency and binary production
|
| - Rust: borrow checker
|
| - Python: "yes, you can do that too. Also in 2 lines"
|
| Etc.
| ZephyrBlu wrote:
| - Ruby: "yes, you can do that 5 different ways in 1 line"
| BiteCode_dev wrote:
| Ruby, readable Perl since 1995.
| tmccrary55 wrote:
| Ruby: Buggy async io for 20 years
| why_Mr_Anderson wrote:
| re Python: "...All actual work is done by C libraries
| though, you could just as easily use BASIC instead"
| BiteCode_dev wrote:
| Well, believe it or not, VBA is doing to have to do with
| Python competition in Excel in a not so distant future:
|
| https://excel.uservoice.com/forums/304921-excel-for-
| windows-...
| pjmlp wrote:
| > While we don't have specific plans to announce at this
| time, we have been researching the topic, conducting
| customer interviews, and are working with the Python team
| at Microsoft so we can build a plan that we think can
| address the scenarios you told us about and ensure it can
| run wherever Excel runs.
|
| Any long time developer on MS stack knows that actually
| means "thank you very much but no".
| BiteCode_dev wrote:
| They just hired Guido, the father of Python, at
| Microsoft.
|
| So, I would not be so sure.
| pjmlp wrote:
| Yeah, because he did so much for Python tooling at
| Google.
| johnnycerberus wrote:
| Google is hugely invested into Python, especially the
| data engineering branch. TensorFlow, Jax, etc. Though
| they will probably get replaced by Dex lang, they even
| dropped Swift 4 Tensorflow to focus on Dex [1]. The
| language looks very Pythonic compared to Julia which is a
| 180-degree turn in terms of language design.
|
| [1] https://github.com/google-research/dex-lang
| pjmlp wrote:
| All of the Tensorflow underlying libraries are
| implemented in C++ and nowadays usable from almost any
| language with native interop.
|
| As for Dex,
|
| > Research language for array processing in the
| Haskell/ML family
|
| > This is an early-stage research project, not an
| official Google product.
|
| Where is Python?
| winrid wrote:
| Java is very high level - it runs on a VM and manages memory
| for you.
|
| I think the opinion you're trying to convey is "not untyped
| enough".
| justbored123 wrote:
| > Python is older than Java, well supported
|
| WELL SUPPORTED???? Have you ever coded a real thing in python?
|
| I'm getting "Warning, no longer supported" console messages in
| all my basic well established tools and libraries written in
| python because a guy that lives in a world of academics and
| theory and not in a world of business and delivery dates
| decided that python3 was not going to have backwards
| compatibility with python2 because they made a massive
| irreparable disaster when they designed python2.
|
| That is not a professional tool for multi-million dollar
| companies, that is a toy for spoiled nerds. Exactly the same
| that Visual Basic 5-6 were when I was starting. Extremely easy
| to use and extremely fast, at the price of been garbage for
| anything larger than a toy app.
|
| And because all the kids learned that at uni and went to create
| the next thing in it like PyTorch and TensorFlow, now you have
| to do all the real code in C / C++ to handle what python can't
| in terms of speed an reliability, doubling you code base, your
| Dev teams, and the needed skill set.
|
| I have been programing in java in large multinationals for 10
| years and I used python every single day for the past 3 years
| for what its useful: small hacky scripts to increase
| productivity. The real sh*t that manages you cellphone towers,
| you home-banking, you online shopping, your logistic chain and
| your android cellphone apps, all things that I have worked on,
| gets done in Java.
| BiteCode_dev wrote:
| Dropbox, Instagram, Google, Youtube, reddit and Nasa all have
| been heavily Python powered for a decade.
|
| I myself have coded a streaming platform getting half a
| million user every day in Python. Baring the CDN to store the
| content, it runs on 2 servers, one for the DB.
|
| So real things get done in Python pretty well.
| the_only_law wrote:
| I almost considered using Java instead of Erlang for a project
| I started working on. For one, my mind is still stuck in trying
| to model systems in a very OOP way, and I was (am?) struggling
| with OTP. I figured I could pull in Akka to get some of the
| nice Erlang stuff.
|
| But Erlang was just such a good fit for this project. I wasn't
| so huge on the Java version of Akka. I also briefly looked at
| Scala, but I avoid Scala for similar reasons to C++ and
| Haskell. The nativess of a lot of the features I wanted to
| Erlang just looked better and it will be a cool homage to the
| language's roots.
|
| Also this is probably more my fault, but I don't really
| understand how distribution works anymore. Supposedly Oracle
| JDK is no longer supported and you're supposed to package a JVM
| with your application, but all the big Java apps still require
| me to have a system wide JVM to run them? OpenJDK seems to work
| fine for now.
|
| Also after toying with a LAPB implementation, I'm so mad other
| languages don't have a good type for dealing bit level data.
| Bitstrings are a godsend.
| kaba0 wrote:
| OpenJDK is basically the Java JDK. Oracle JDK is only a
| "fork" of it, but they have complete feature-parity. Oracle
| only provides paid support for current and older versions of
| OpenJDK (similarly to many other vendors)
|
| So you can just install OpenJDK from a package manager, use
| the jlink tool and create your own small "JRE" that you want
| to bundle. Jpackage can create a platform native executable
| from that, that is either an installable exe, .deb, rpm or
| MacOS's format (I forgot it's name)
| jokoon wrote:
| You perfectly nailed how I feel about java.
| DrBazza wrote:
| Don't forget that Java first appeared in the late 90s and is a
| language of its time. That's not say that it hasn't evolved,
| but many of the decisions and choices were of that era.
| BiteCode_dev wrote:
| - Java: 1995
|
| - Python: 1991
| dagw wrote:
| The first and second half of the 90s where very different
| times when it came to programming.
|
| Furthermore Python and Java set out to solve very different
| problems, which is reflected in their design decisions.
| dnautics wrote:
| There's a lot of very reliable distributed systems written in
| java. But if something goes wrong, and it will, because
| distributed systems, you will not want to debug it. And because
| java is very enterprisey, distributed java developers are
| expensive. You're competing with faang salaries.
| ivan_gammel wrote:
| There are ways to deal with this problem. Debugging of
| microservices can be efficient and you don't have to hire the
| entire team of experts.
| kaba0 wrote:
| What other platform would you want to debug? There is
| basically no better one then the JVM when it comes to
| profiling. Exceptions are detailed with stack traces, you can
| even attach a profiler in production and let it run there
| because of the negligible overhead with flight recorder.
| Hell, there are even debuggers that can run your program
| backwards.
| dnautics wrote:
| most things on the erlang virtual machine? Debugging elixir
| is fantastic.
| hahamrfunnyguy wrote:
| As a now old guy developer, I laughed when Microsoft released C#.
| I figured it was just a half-assed attempt at a Java clone. Then
| I used it, and realized I was wrong. Microsoft has been
| continuously improving the language, and .NET has support on a
| lot of platforms. As long as Microsoft keeps making my life
| easier, I am going to keep using it.
|
| I haven't worked on a big Java project in a few years, but I
| would always find myself missing stuff from C#.
| jariel wrote:
| It's not perfect for anything but it's very robust and
| dependable.
|
| The API's are comprehensive, well thought through, to this day
| it's bizarre nobody has copied Javadoc. Python docs drive me mad.
|
| For a script - Python. For the web Typescript. For low level C or
| Rust.
|
| But Java is quite powerful for anything that stretches in
| between: not the fastest to write, but generally fast, the
| tooling is robust, the performance is quite good usually.
|
| And I love that it's uncool.
| dragonwriter wrote:
| > to this day it's bizarre nobody has copied Javadoc.
|
| JavaDoc-style structured documentation in comments with
| toolchain to generate user docs from a combination of the
| comments and the associated class/method/function signatures
| has been widely applied; Doxygen and JSDoc obviously owe a lot
| to it, as do Sandcastle (for .NET), Rdoc/YARD for Ruby,
| Sphinx/autodoc (for Python), etc.
|
| I'd be surprised if there is a major language today for whuch
| there isn't at least one JavaDoc-inspired documentation
| generator.
| nsonha wrote:
| I like the simplicity of java, syntax is a bit lame but the
| majority of language is sane. I used to hate the fact that every
| file must be a class but if you respect inversion of control then
| that's a good default. The part that I think really stupid is
| java beans.
| Jaxkr wrote:
| Thanks for the two upvotes so far! Please feel free to leave
| criticism of the article or my writing; I'm trying to strengthen
| my composition muscle.
| baby wrote:
| You def. are doing well with both title and content,
| controversial stuff always has an audience.
|
| I would just recommend learning another programming language :)
| zodiakzz wrote:
| Your jab at TS was lame as Java itself has complete type
| erasure for generics.
|
| >by crystallizing type definitions and guaranteeing type guards
| by default.
|
| Not so crystallizing if you know.. if you've ever used a Java
| List, Set or a Map. i.e., List<icouldbeanythinginhere>. such
| guarantee. wow.
|
| Honestly, I'd prefer TS with strict mode over Java any day
| because nullability is explicit, don't have to watch out for
| the dreaded NullPointerExceptions left and right.
| Jaxkr wrote:
| Thank you, good point. I forgot about HashMap's type unsafety
| even though I wrote the following monstrocity a few days ago
| to loop over a HashMap<UUID, ExpiringEntityPlayer>
| Iterator ghostI = hashtableNPCs.entrySet().iterator();
| while (ghostI.hasNext()) { ExpiringEntityPlayer
| expiringEntityPlayer = (ExpiringEntityPlayer) ((Map.Entry)
| ghostI.next()).getValue(); }
|
| Apparently this is the only way to do it, and the Map.Entry
| type absolutely nukes any semblance of type safety.
| cesarb wrote:
| You are supposed to use generics:
| Iterator<Map.Entry<UUID, ExpiringEntityPlayer>> ghostI =
| hashtableNPCs.entrySet().iterator(); while
| (ghostI.hasNext()) { ExpiringEntityPlayer
| expiringEntityPlayer = ghostI.next().getValue(); }
|
| However, it's a sham. The generic types are stripped at
| runtime. The compiler will prevent you from putting values
| in the map that are not an ExpiringEntityPlayer, as long as
| you are diligent in using generics everywhere, and don't
| fall in the few traps where the wrong type can slip by
| without a warning, but you can still be hit by a
| ClassCastException at runtime if you're not careful.
| twic wrote:
| This is exactly like saying all types in C or C++ are a
| sham because you can cast a typed pointer to a void
| pointer.
| tpxl wrote:
| > but you can still be hit by a ClassCastException at
| runtime if you're not careful.
|
| While it is true the generics are more or less syntactic
| sugar, I have never seen a ClassCastException due to this
| in all my years.
| twic wrote:
| One thing to bear in mind as you read the comments is that the
| great majority of people commenting clearly do not have good
| up-to-date experience of working with Java. They're arguing
| against the Java that they used a decade ago, or perhaps even
| just repeating flames they read a decade ago.
| da39a3ee wrote:
| I'm curious which editor/IDE you used while writing typescript?
| I've recently started writing typescript and I've been finding
| it more or less a mecca of good editor completions and LSP
| support, compared to what I was doing previously (Python in an
| old school editor) (I'm using VS Code for typescript).
| goldenkey wrote:
| Comparing TypeScript to Java is like comparing a swimming pool to
| a sauna. Yes, "ignorant CS undergrad" is quite apt.
|
| Java is one of the most unpleasurable technologies to work with.
| It is slow to start up, full of idiosyncrasies, and all in all, a
| pretty awful language when it comes to brevity. Java is the
| epitome of "lets use this language so we can hire cheap coders."
| It is a vestige of what it came from, even if some new features
| have been added 10 years too late.
| internetrando wrote:
| Personally, I wonder if/when Java will become the next COBOL:
| nobody wants to learn it, feels extremely awkward and obtuse
| compared to whatever is current then, but there will be loads of
| old code that needs maintaining. Certainly feels like it's on
| that track now...
| popypooping wrote:
| The guy was changed with a niggres, hey it is updated
| nesarkvechnep wrote:
| I think the author just hasn't seen enough. There's not a single
| language that's better than every other language at everything.
| Java's type system is inferior to ML language's type system.
| Java's developer experience is laughable compared to Common
| Lisp's interactive development. A lot of languages have great
| package managers - Rust and Elixir comes to mind. Also sometimes
| smaller community with higher quality is better than huge
| community with average or below average quality. It always
| depends. I hope the author doesn't turn into a Java monoglot just
| because other languages are different. Well, problems also differ
| from one another.
| jaywalk wrote:
| The fact that somebody had to point out to him that C# also met
| his four points under "A holy grail of productivity" should
| tell you all you need to know about his complete lack of
| experience in the field.
|
| This is nothing more than the ramblings of an inexperienced kid
| who thinks they know it all. He'll probably look back on this
| in a few years and realize how little he actually knew.
| jbluepolarbear wrote:
| Java is fine; just fine. It's not flashy or fun, comes with 25
| years of CRUD, and so many ancient, enterprise codebases you'll
| never run out of soul-sucking positions to bring your toolbox.
| Except they moved to the new hot CRUD framework and you'll have
| to learn it all again.
| Igorvelky wrote:
| sorry long sentences are not my forte
|
| ## python comprehensions,
|
| better then java or c++ way . which is absolutely same . so java
| === c++20 (ms way) .
| https://calmcode.io/comprehensions/example.html (not affiliated)
|
| ## jupyter lab
|
| your data and your processing is on same machine potentially
| remote, nas, privatecloud... so you can do things on your data
| without unnecesary bs from browser with youbikey, google titan
| auth.
|
| ## neovim
|
| because... well, dont be negative and treat it as fedora for your
| redhat (vim) (yes i remember, im that old)
|
| ## little bit of trolling
|
| do this on your brand new mac in vscode ... yes, he has fingers
| https://www.youtube.com/watch?v=-I1b8BINyEw
|
| ## Java
|
| is good for Transform UML to code. thats it, DONE.
|
| ## AI ! ! ! ! XOr Not
|
| Btw who said machine learning can code for you ? uh, me not! Lets
| draw pictures for ML, to have better MS Office!
| https://knowyourmeme.com/photos/1845265-back-to-the-future
| hutrdvnj wrote:
| Java is great, because it is not worse at anything.
| desktopninja wrote:
| Personally for me: java -jar application.war
|
| Is as elegant as: v=ir
| brutuscat wrote:
| Not sure how things are now, but I would rather use Ruby via
| JRuby and still benefit from most of the Java ecosystem but using
| the much more higher level abstractions of the Ruby lang.
|
| Many years ago I discovered that I could use all the Java
| components just like that:
| https://speakerdeck.com/brutuscat/jruby-experiences
| hnal943 wrote:
| Is this a joke?
| dkarl wrote:
| This post from "an ignorant computer science undergrad" is pretty
| silly, so allow me to get a little silly in response.
|
| I think if Java's new features are an attempt to woo new
| developers, Java comes off pretty tragically, like the old guy in
| the club, trying stay relevant by showing off how it just got up
| to date with ideas that hit the mainstream ten years ago. Whoa,
| check out these record classes! Fresh stuff over here! I don't
| think there's any significant audience for this (a few "ignorant
| computer science undergrads" aside,) and I doubt that's what
| Oracle is shooting for.
|
| I think what Java is really doing is reassuring people who
| committed to it long ago that it will take care of them. Java is
| not the old guy in the club; it is the middle-aged guy dressing
| up and taking his wife out for a night (or half an hour,
| depending on her arthritis) of dancing at a jazz bar. It's doing
| its honorable best to show the people who committed their lives
| to it that it understands they still need a little bit of
| excitement now and then, and they don't have to sacrifice their
| dignity to some cad at the bar at the country club to get it.
|
| They don't really want to leave Java. Java understands things
| about them that nobody else ever will. All Java needs to do to
| keep them is love them enough to keep doing its best.
| icholy wrote:
| How is this the top comment?
| dkarl wrote:
| I read the linked post from beginning to end. I wouldn't
| normally post jokes, but for an HN audience, there isn't much
| to process in it except to criticize the author's
| inexperience, which seemed mean, and the issues it raises
| have been argued thoroughly many times on HN, so there didn't
| seem like much of a chance of a meaty technical discussion.
| The demographics of who the further evolution of Java will
| and won't appeal to seems like the most interesting question
| the post raises.
| bronlund wrote:
| Why is this post on the front page. That's the real question.
| januszpawlacz wrote:
| Your metaphors are tiring
| ebiester wrote:
| More importantly, there are likely billions of lines of java
| code in production at this point, and just having that as an
| option matters for those code bases.
|
| It might not be what you choose for a new company, but it may
| not be fashionable here but it is very common and quality of
| life improvements are welcome.
| dkersten wrote:
| > I doubt that's what Oracle is shooting for
|
| My guess is that they're not trying to win over people from
| other languages with these features, but rather to not give
| Java people a reason to move to other languages. Why move
| (legacy and lock-in aside), when Java has the features you're
| considering moving elsewhere to get?
| hyper_reality wrote:
| This is funny and I would love to hear your personifications of
| other languages. I imagine Python and Perl offer a lot of
| material.
| strictfp wrote:
| Java development scales, it has pretty good performance, and
| great tooling.
|
| I agree that it's underhyped. You can pick a lot of other
| languages, but no other language is as broad as Java.
|
| Python reads like a dream but has useless perf and threading.
|
| Javascript (Node et al) has the I/O concurrency but no clear
| solution to threading, and is bad at number crunching.
|
| C++ has good perf but is overly complicated, compiles take
| forever, no good module management, etc.
|
| Rust is great but super-hard to learn.
|
| Golang lacks tooling and perhaps some libs, albeit being a
| really good contender.
|
| Naturally there are other languages to bring up, but I
| personally think that Java strikes a good balance. The language
| itself doesn't really have any clear weak points anymore. With
| lambdas and streams, even FP is succinct in it.
|
| The only thing really speaking against Java right now is the
| culture of overly complicated frameworks with too much meta-
| programming and magic. And the fact that the market of
| lightweight alternatives is too fragmented.
| dehrmann wrote:
| > great tooling
|
| Something I underappreciated until I delved deeper into other
| languages is how much observability the JVM gives you into
| how an application is running. Something like VisualVM makes
| it _incredibly_ easy to see what threads are running, in what
| state, etc.
|
| There's a class of things where the overhead of a VM (like
| the JVM, not VMWare) doesn't make sense (kernels, drivers),
| and startup time can be an issue, but for code where pretty
| good performance is enough, running in a VM is an asset to
| me.
| dkarl wrote:
| > Java development scales, it has pretty good performance,
| and great tooling.
|
| I agree with this, but I think these qualities are shared by
| a lot of languages that run on the JVM, and Java the language
| is no longer a worthy flagship language for the JVM.
|
| > With lambdas and streams, even FP is succinct in it.
|
| I have the opposite reaction to lambdas and streams. I think
| Oracle could have gone two ways with the evolution of Java:
|
| - Be conservative about what features were adopted into Java,
| but be willing to change the syntax and feel of the language
| to do it in the best possible way. Only add features that
| both made sense for Java and had proven themselves after
| years of experience with the languages that pioneered them,
| but give Java the most elegant and polished version of them,
| so that Java would be a kind of "best in class" language that
| trailed the leading edge but always reflected it in an
| excellent way -- at any moment, the best version of Java that
| could be built with the industry's combined experience.
|
| - Or, keep Java feeling as familiar as possible, while adding
| any features that are embarrassing to lack. It's okay if new
| features feel bolted on or don't feel as elegant as they do
| in newer languages; it's more important that longtime Java
| programmers don't feel like the fundamentals of the language
| are changing underneath them.
|
| Streams are what convinced me that Oracle were committed to
| the latter route. They came out with an implementation that
| looked and felt clunky compared to what people were used to
| in other languages, but it felt very Java-y, and existing
| Java developers were pretty immediately comfortable with it.
| vbezhenar wrote:
| As a developer who used Java for 12 years, I don't really like
| the direction Java takes. It's not happening like you're trying
| to describe. Java have some weak points which could be
| addressed easily. For example properties are relatively easy to
| implement, but instead developers decided to implement records
| which are very different. Modules are weird thing that nobody
| asked for and they broke old code (what a blasphemy in Java
| world). And still I'm not aware of any useful modules use-
| cases. They throw out Java EE instead of improving it.
|
| I'm sure that Java developers have a vision which they're
| moving to. They're trying to convert old language into a new
| one with immutable classes, pattern-matching, green threads,
| modular JVM, all that stuff. May be I'll like that new
| language, but so far I'm a little bit unsatisfied. And, as it
| seems, young people are not that impressed either.
| kaba0 wrote:
| > For example properties are relatively easy to implement,
| but instead developers decided to implement records which are
| very different
|
| But why would they bake in a misfeature? Yeah it is popular,
| but was never a good idea to begin with. Records and new
| language features try to slowly shift the focus to a more
| immutable, FP-oriented style of OOP, which is imo a good
| decision. Of course it doesn't make imperative code legacy,
| the two worlds can coexist perfectly.
|
| > Modules are weird thing that nobody asked for
|
| This is the feature that allows the JDK team to do their
| work. You either expose the internals and freeze it,
| effectively killing the platform, or encapsulate it. It
| is/was a great decision, and it didn't broke too many things.
| vips7L wrote:
| Providing records was never about providing properties, but
| yes I agree properties would be a great addition.
|
| > They throw out Java EE instead of improving it
|
| Giving EE to the Eclipse foundation and transitioning it to
| Jakarta EE is about improving it. It allows the Eclipse
| foundation to move faster without having to go through the
| JDK standardization process.
| vbezhenar wrote:
| The first thing they did is performed source-incompatible
| change of package names. That's hardly improving in my
| book, more like sabotaging. I understand that's because of
| trademarks, but that's another issue: why didn't Oracle
| provide all the necessary legal protections at least for
| package names.
| chris_j wrote:
| A cynic might suggest that Oracle deliberately sabotaged
| Java EE because competitors like IBM and RedHat had
| beaten it in the marketplace and were making all the
| money off it.
| jcadam wrote:
| I think Kotlin is pretty much what a modernized Java should
| be. Between it and Clojure I don't spend very much time with
| Java anymore.
| jackcviers3 wrote:
| Kotlin could he better, but doesn't go all the way. Without
| HKTs and implicit injection, Java is going to eat its
| lunch. Java already has records, type inference, parametric
| null safety with Optional, Loom provides coroutines, vavr
| and streaming apis have given us theabilitytodo FP...
| what's left as a unique feature?
|
| Kotlin will survive because it was picked for Android to
| avoid copyright issues. But the difference between the two
| languages is vanishing small.
| blacktriangle wrote:
| Could you clarify the point on Android and copyright
| issues? At least at the time in 2017 when Google blessed
| Kotlin as an officially supported language, it seemed
| like the reasoning was Kotlin was far more ergonomic than
| Java. How does copyright come into this?
| alcidesfonseca wrote:
| Oracle suited Google for copying the APIs (not the
| implementation) of the Java standard APIs. It all started
| in 2010 [0]
|
| Kotlin was Google's backup if the suit went Oracle's way.
|
| [0] https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_Am
| erica,_....
| pvorb wrote:
| I'm no expert in the Android ecosystem, but I think it
| was primarily a good choice for giving devs features they
| wanted to have while the underlying runtime and standard
| library got stuck at Java 6. The reason why they are
| still on Java 6 might have to do with the law suit,
| though.
| blacktriangle wrote:
| I guess given the recent court ruling we should see if
| Google sticks with Kotlin as a hedge, sticks with Kotlin
| because the community has embraced it, or pulls away from
| Kotlin as a no longer needed source of extra work.
| jcadam wrote:
| It's Google. They'll probably come up with a completely
| new programming language which they'll force on the
| community in some ham fisted way, then suddenly drop it
| in a few years when they can't figure out a way to
| massively monetize it.
| mhoad wrote:
| I thought that was Dart. Which is honestly a shame
| because it's a genuinely great language. But it does very
| much fit the bill otherwise
| nine_k wrote:
| When Java gets the Kotlin's brilliant "last argument of
| lambda type can be a block", let me know. It allows to
| massively extend the perceived syntax of the language
| where needed, and create nice, typechecked DSLs. A number
| of small ergonomic improvements is also impossible to
| port to Java.
|
| And I'm definitely happy that Java does not feature
| implicit injection, which looks so cool but is so painful
| to work with in Scala.
|
| When I need HKTs, I can pick a perfectly good Haskell :)
| I'm afraid Java or even Kotlin will never achieve this
| level of FP-ness; for that, a language should be designed
| differently. Rust, OTOH, likely will.
| cutler wrote:
| Dream on. Java, even including upcoming features, has
| nowhere near what's included in Kotlin out of the box.
| Nullability? Extension methods? First class functions? I
| could go on.
| scrubs wrote:
| Agree re: silly OP post. I read it thinking: Eventually this
| guy will move to sales and marketing majoring in language wars.
| So I'll further the silly follow-on as follows:
|
| Guys, c'mon, get your head in the game. Before we tech out how
| under hyped JAVA is we still never sorted out just how awesome
| VI is and how VI is way better than EMACS, Code Lion, and
| whatever other crazy complex IDEs are out there. Once we figure
| that out, only then can we afford to resolve the lesser
| pressing problems.
| maxpert wrote:
| I've already moved to Kotlin. I love the language other than
| the fact that JVM objects are just too heavy. Nothing against
| Java but language has aged like milk, the readability and
| writability is just too bad. Recent strides with records and
| project loom etc are evident efforts to make it evident again.
|
| I've kinda started to like Kotlin from syntax perspective &
| Go's nature of compiled and low overhead prospective. I wish
| somebody can combine those together (don't tell me GraalVM).
| gilfoyle wrote:
| Java language gets its hate from its historical lack of focus on
| developer happiness. Beyond the language, the crufty experience
| with Java Bean, Java EE, WebSphere era all contributed to this.
|
| Thankfully, Java ecosystem has learnt from other languages and
| frameworks and with Java 8 onwards has addressed some of major
| pain points For e.g. lambda, streams, vars, text blocks, records
| etc,
|
| On the other hand, Shopify and Dropbox that used Ruby and Python
| heavily had to invest in type checking to bring back some sanity
| and this is evidence that beyond a size of code base, static type
| checking is worth it.
|
| Considering these, I find Java to be a very good option to build
| stable enterprise applications compared to Ruby or Python.
| hn_throwaway_99 wrote:
| > Considering these, I find Java to be a very good option to
| build stable enterprise applications compared to Ruby or
| Python.
|
| Which is honestly why I think Typescript with Node on the
| backend is an excellent choice for many enterprises.
| patrec wrote:
| I think Rust also meets all the criteria the author lists,
| probably Kotlin too, and arguably even Typescript (the quality
| package manager is a bit of a stretch, but I suspect the nominal
| typing the author hankers after can be emulated well enough to do
| the trick e.g.
| https://www.typescriptlang.org/play#example/nominal-typing). As
| to the reasons Java lost its hype: Enterprise baggage and Oracle;
| the terrible startup times and long GC pauses probably also
| didn't help (even if there has been a lot of progress in this
| area in recent times).
| bni wrote:
| The reason Java is so disliked is because new developers first
| contact with it is maintenance programming on the horrible
| J2EE/Spring monstrosity that has evolved since 2005, or from even
| earlier.
| exdsq wrote:
| I wonder if it's 'fun to write' because the boilerplate lets the
| author feel like they're writing lots of code, even though it's
| unnecessary in other languages. I've never met a developer in
| industry who prefers Java to Scala, and having used both in
| production myself, I'd agree too.
| Koiwai wrote:
| I'd admit it is very successful, since C++ already existed, it's
| a commercial miracle. But if you're still promoting Java in 2021,
| I'd say you're very shortsighted.
| king_magic wrote:
| The sheer verbosity of Java is just unbearable when you're used
| to Python/Go/Swift/etc.
|
| No, Java is just about as hyped as it needs to be. Which is to
| say, it's more or less fine. Not great, not terrible. Middle of
| the road at best.
| eitland wrote:
| Or you could say nobody who has ever had a working IDE setup
| could ever go back to Python.
|
| Saying this as someone who Java after Python and other
| languages.
| coldtea wrote:
| > _The sheer verbosity of Java is just unbearable when you 're
| used to Python/Go/Swift/etc._
|
| I'm used to Python (and some Go) for decades, and the verbosity
| of Java is a non-issue to me.
|
| I'd rather have the speed, type safety, and refactoring tools
| support, over Python... (not to mention the much better
| packaging situation).
|
| I'd still prefer Python for smaller programs, basically because
| of the startup time and quick write/try cycle. But for larger
| stuff, I'm not so sold, and I've been doing them (in Python)
| for decades...
| eklavya wrote:
| I am sorry, Go? That can't be right. I even doubt it's any more
| verbose than python or swift. You CAN make it verbose that's
| for sure.
| yongjik wrote:
| You _can_ write verbose code in any language, but most other
| languages don 't consider it normal to name a class
| LangDetectLanguageIdentifierUpdateProcessorFactory. (Random
| example from an open source framework.)
| baby wrote:
| I just got some flashback reading that long string, and my
| heartbeat raised. The namespacing system is also a
| nightmare
|
| Com.prout.shit.lol...
| koolba wrote:
| Namespacing in reverse dns order is something Java got
| right. It naturally segments things and you can
| immediately see the relative provenance of classes.
|
| It's just impossible to use without editor support.
| Nobody who cares for their sanity can type out those
| package names manually. I think even Gosling said as
| much.
| eurasiantiger wrote:
| Just trying to find files relevant to some functionality
| is incredibly difficult without full-text searching all
| the files. Namespacing is fine but why must the entire
| path be reflected in directory structures?
| koolba wrote:
| But how else will your app automatically detect and inject
| its enterprise LangDetectLanguageIdentifierConfligurator at
| startup?
| [deleted]
| thu2111 wrote:
| Eh, any sufficiently large or complex codebases will get
| ridiculously long names at some point. Here are some from a
| famous C API (Windows):
| CoMarshalInterThreadInterfaceInStream D3D12_GP
| U_BASED_VALIDATION_SHADER_PATCH_MODE_UNGUARDED_VALIDATION
| RtlWriteDecodedUcsDataIntoSmartLBlobUcsWritingContext
|
| Or how about:
| GtkColorSelectionChangePaletteWithScreenFunc
|
| The alternative is things having names that aren't actually
| descriptive at all, which is not clearly better.
| madia_leva wrote:
| Or have a good package system... If you use a language
| with import with aliases, you don't need all that noise.
| thu2111 wrote:
| Java has such a system but people write long class names
| anyway, because people don't like to have too many types
| with identical names distinguished only by namespace. You
| _can_ do it but it 's a bit questionable to what extent
| you should.
| dmingod666 wrote:
| or as the saying goes, "you can write java in any language".
| eurasiantiger wrote:
| Making JavaScript turn into Java bytecode is not a magical
| experience.
| da39a3ee wrote:
| Perhaps verbosity isn't the right word, but having to put
| every function in a class (in a correspondingly-named file)
| feels extremely cumbersome to people who grew up with
| languages that just have functions and weren't exposed to
| Java early on.
| nemothekid wrote:
| > _You CAN make it verbose that's for sure._
|
| No true scotsman? Even if you want to argue that Java CAN be
| made more terse, the vast majority of Java that exists today
| is incredibly verbose. Even _running_ a Java program is
| verbose. Java is the only language I 've used where it's more
| common to have a shell script that starts your Java program
| than just running ./helloworld.
|
| And yes, Go is less verbose than Java. Go might require some
| _boilerplate_ , but it is certainly much less verbose than
| Java.
| eklavya wrote:
| We should keep in mind the kind of features, performance,
| observability the jvm can provide, compare that with the
| other runtimes and then see if the script to execute is too
| much :)
| twic wrote:
| > And yes, Go is less verbose than Java
|
| No, this is utter, utter nonsense. I have written plenty of
| both, and it's not even close.
|
| If you are going to press this extraordinary claim, you
| need to supply at least some evidence for it.
| wing-_-nuts wrote:
| Go's error handling is painfully verbose. Go's lack of
| generics leads to passing empty interfaces everywhere (come
| on proposal!). Don't act like go doesn't have it's warts.
| If it wasn't backed by google it wouldn't be nearly as
| popular as it is.
| LaserToy wrote:
| Verbosity is not a problem in large code bases. Speed of
| understanding and debugging of what somebody else wrote is.
|
| So, less magic is better. I will take Java codebase over
| Scala or Python every time, unless it is a toy script which
| is 100 lines
| tirrex wrote:
| Java style verbosity hurts readability. That's the most
| important issue with Java imho.
|
| Take a look at a http server one in Java and one in C.
| Readability difference is crazy.
|
| My company is in transition from Java to C, for bunch of
| stuff just for performance reasons. So, I debug similar
| projects time to time both in Java and C, http server, in
| memory cache, iot server etc. After seeing both, I just
| think although Java has great tooling, it drives
| developers to write unreadable code.
| LaserToy wrote:
| I mentioned C as a language of choice. Cool kids are
| picking node js and esoteric Closure, not C
| cle wrote:
| Every significant Java codebase I've worked in has had
| incredible amounts of magic. Between AOP, DI frameworks,
| APT, reflection, proxies, SPI, Lombok compiler hacks,
| dynamic classloaders, etc., there is a LOT of magic
| flying around and it can be quite hard to understand what
| will happen at runtime.
| LaserToy wrote:
| I'm talking about the language, not frameworks.
|
| AOP sucks because it is paaaain to debug, proxies are
| magic. There is Dagger that solve some stuff
| esarbe wrote:
| This is what drove me away from Java; the ungodly amount
| of magic that's required to make it economic. If it all
| works, it's fine. But as soon as something fails... Get
| yourself ready from some frustrating hours.
| pbadenski wrote:
| ALL Java developers should be required to watch this
| course (it's Free):
|
| https://software-mastery.teachable.com/p/uncommon-sense
|
| FYI: I am NOT an author of this course.
| fomine3 wrote:
| This. Java communities tried to solve redundant code
| problem by complex, hard to recognize way.
| smitty1e wrote:
| Still got PTSD from a Hinernate codebase that had all
| sorts of initialization magic afoot.
|
| Who needs CPP macros when you've got reflection?
| inshadows wrote:
| Don't forget XML DSLs. Or are we past that?
| tirrex wrote:
| I'm not a backend java dev but whenever I take a look at
| java web projects which use spring/jsf/jsp etc
| frameworks, docs say to handle a request, write a method
| with that signature, we'll call it when there is a http
| request. I always want to know enterence/exit points of a
| network message but that is impossible with these fancy
| frameworks. It is pure magic.
| bpodgursky wrote:
| Nobody who has ever written error handling in Go could
| possibly downvote this comment. Holy moly, the error checking
| after EVERY interesting method call. Talk about verbose.
| praptak wrote:
| Go's error checking is the 2020's equivalent of "Python's
| significant whitespace". Both are pretty common and rather
| shallow critiques of a language.
| thiht wrote:
| It's useful verbosity. Java's verbosity is misplaced, which
| is worse.
| kaba0 wrote:
| That's just false
| ncmncm wrote:
| Being excited about Java is like being excited about dirt--not
| any particular dirt, just dirt in general. Yes, practically
| everything that grows grows in dirt, and anybody can walk on
| dirt, and in a pinch you can throw it at people or dig a hole and
| crawl in. Dirt.
|
| Java was designed by people who had absolutely no intention or
| desire to ever use it. They cribbed parts from other languages
| they didn't really understand, and changed details in ways that
| make no sense on their own, or with other things they changed for
| actual reasons.
|
| Their estimation of its expected users was very low, so they made
| everything dull and squishy so nobody could do much harm whether
| by mistake or deliberately.
|
| It got billions of dollars more hype than it deserved on merit.
| Its privileged place in the corporate world, like its good
| tooling support, are direct products of that hype. The hype it
| got on first release, beyond the (very large amount of) money
| backing it, comes from a peculiar twist of history: right then,
| millions of programmers were sharecropping on Microsoft's
| plantation, and saw Java as their 40 acres and a mule. It was a
| balky mule, but it promised freedom from switching to a whole new
| app framework literally every 2nd year.
|
| Since then, a very large number of libraries have been made to
| package most common operations. It's barely adequate for making
| libraries, but people have put a great deal of effort in because
| of the big user base.
|
| "I enjoyed programming in Java, and being relieved of the
| responsibility for producing a quality product.":
|
| <http://blog.plover.com/prog/Java.html>
| aryehof wrote:
| I think that Java is more like "concrete" than dirt. Fairly
| gray, unexciting and utilitarian, but nevertheless much of the
| world is reliably built on it.
| bluetomcat wrote:
| Java is undermined by the orthodoxical OO culture around it. As a
| language, it's a pragmatic one with no fancy features to get
| excited about. Similar in design philosophy to Python or Go. What
| ruins it is its conservative dev culture stuck in the OO craze of
| the late 1990s.
| isamuel wrote:
| As a bookmark I can point to later, I want this on record:
|
| This kid's going to the moon.
| ntw1103 wrote:
| While attneding university, Java made an appearance in 4
| different classes, the first two clases students take are Java
| classes. One interesting thing to note, is that for these
| classes, none of the students were allowed to use any of the Java
| libraries, or external libraries, everything had to be built from
| scratch. So I didn't actually learn about using external
| libraries or Maven until later when I started developing for
| Android. >"How many languages can you think of that meet the
| following conditions?" I think that dlang comes pretty close. The
| Dlang community isn"t super large, but I've found everyone I've
| interacted with to be polite and helpful.
| Jaxkr wrote:
| I had the exact same experience in my C++ courses: no external
| libraries at all. But those are a PITA anyways, even with
| CMake.
|
| And I've heard good things about Dlang but I've never used it
| myself, I'll have to check it out some more.
| seiferteric wrote:
| I have never been a java developer but I get the impression
| it is similar to C++ in the way that they were not that great
| early on in their history but have since been dramatically
| improved, but the old reputation persists to outsiders.
| oftenwrong wrote:
| Java is poor choice as a language for teaching programming.
| There are simply too many irrelevant bits that will get in the
| way of learning.
| baby wrote:
| Schools use it because it used to be the best way to get a
| job. Not anymore.
| askonomm wrote:
| > Used to be the best way to get a job
|
| Java is the most in-demand technology in my home country,
| Estonia. Java also has around 800 open positions at any
| given time where I live now (Buenos Aires, Argentina). In
| fact, pretty much everywhere I've looked, Java is
| consistently one of the best ways to get a job simply
| because it has the most jobs available.
|
| HN favourites like Go and Rust? I haven't yet found a city
| in Europe that would have more than 10 job offerings for
| either of them.
| loriverkutya wrote:
| Try London.
| nemothekid wrote:
| Go/Rust will get you hired in Silicon Valley working on
| "cool" teams. I believe a bunch of AWS teams are deep
| diving into Rust, and not to mention the hundreds of
| startups working in Go/Rust.
|
| However, the sausage is still made Java. Amazon, Google,
| and Apple are, as far as a I know, primarily Java shops.
| It's just no one ever starts a blog with "Here's
| something cool I did in Java".
| askonomm wrote:
| Ah yes, I keep forgetting that HN folk are American-
| centric and often either do not know or forget that the
| vast majority of developers do not actually live there,
| or work for FAANG.
|
| Outside of USA, a little digging I did via Glassdoor:
|
| Buenos Aires, Argentina: - Rust: ~5 jobs - Go: ~3 jobs -
| Java: ~800 jobs
|
| Lisbon, Portugal: - Rust: ~6 jobs - Go: ~30 jobs - Java:
| ~278 jobs
|
| Barcelona, Spain: - Rust: ~1 job - Go: ~50 jobs - Java:
| ~751 jobs
|
| These are just places I've lived at and while I can see
| Go slowly becoming a thing, Rust is still half a decade
| away from anything tangible for the real world I would
| say. So if anyone asks me what should they become an
| expert in for the next 10 years, I would not hesitate to
| say Java.
| disgruntledphd2 wrote:
| Yeah, I've been on HN for a decade now (back when Ruby
| was the new hotness), and I remember looking through the
| engineering jobs in Ireland and almost entirely Java and
| C#.
|
| Additionally, pretty much all the distributed data
| processing tools run on the JVM, which is a big deal if
| that's what you do for a living.
| twic wrote:
| Not just American-centric, but "Silicon Valley working on
| "cool" teams"-centric. Across all jobs in the US, Go and
| Rust are still a tiny share.
| [deleted]
| jariel wrote:
| I think the opposite actually.
|
| Python, JS and C/c++ are full of idiosyncrasies.
|
| Java allows students to quickly get up and running and focus
| on the 'CS'.
|
| That said, Python might be more practical for anything
| applied in school.
| oftenwrong wrote:
| I don't that find Java as a language has fewer
| idiosyncrasies (perfect term btw). For example, the many
| modifiers: public, private, "package-private", protected,
| default, abstract, static, final, volatile, synchronized,
| etc. How much of that is relevant to a fledgling
| programmer?
|
| If you extend your consideration to build systems and other
| tooling, it's easy to see that students have a lot to
| overcome with Java as an intro language.
|
| I think purpose-built languages like the HtDP languages or
| Logo are better choices. Students can get started with zero
| faff, learn the essential concepts, and move on.
|
| Java is a fine choice for higher level courses, with
| students that are already capable programmers.
| jariel wrote:
| I don't think concepts such as public/private/abstract
| are idiosyncratic because scoping and non-instantiable
| entities are common in programming.
|
| Yes - 'Logo' is a good choice for the most entry-level
| users, maybe for high schoolers who are taking CS as a
| 'required' part of the curriculum, but anything beyond
| that Java is fine.
|
| I think Generics, Java9++ 'Modules', jar files and class
| files might be the idiosyncrasies to worry about.
|
| That said, it's weird that in 2021 we don't have a
| universally 'basic' programming language that is
| essentially the 'vanilla' of programming.
|
| Somewhere inside JS/Python/TS/Java/Dart I think is that
| 'basic vanilla' imperative language I think.
| RamblingCTO wrote:
| I feel like the arguments would've been better applied to kotlin
| (especially with IntelliJ). Java has two big problems: Null and
| boilerplate code (getters, setters etc.) which messes with code
| coverage (and no, lombok is no appropriate solution to this).
| Kotlin is pretty null safe and has very little things which we
| cannot properly test. The language is easy to learn and fun to
| write. It feels sleek, modern and you need to write less code
| than compared to java. You still get the whole ecosystem and can
| even migrate file-by-file. We actually still have a mixed
| codebase with 30% java and 70% kotlin (rough estimate) and it
| works wonderfully.
| kaba0 wrote:
| Having 100% code coverage just because is not meaningful in
| itself, so I don't see your point.
|
| Having 100% is just as not enough because you can arrive at a
| line of code from exponentially many states. Mutation testing
| is a good way to show whether the tests are actually worth
| anything.
| slver wrote:
| I think the author is still forming their opinion on those
| languages. Several of their points sound wrong.
|
| "Dependency heavy workloads and industry trends"
|
| The author complains about JS having small packages about trivial
| things (and for some reason when people talk about this they
| always mention lpad, apparently lpad is the only small package in
| NPM /s).
|
| And about the fact Java has a type system. Many languages have a
| type system. In fact JS also has a type system through
| TypeScript.
|
| "Nominal typing"
|
| TypeScript typeguards are compared with the lack of Java
| typeguards.
|
| - Java has typeguards and they're even being extended:
| https://openjdk.java.net/jeps/394
|
| - Type guards have nothing to do with nominal vs. structural
| typing. They're rather used to disambiguate unions. If you have
| no unions you need no type guards.
|
| - Interfaces in TS are structural, but classes are nominal.
| Typeguards can be either.
|
| "Removal of responsibility for optimization"
|
| The author believes Java frees them from memory management and
| multithreading race conditions, and the need to optimize (like
| think about underlying data structures, algorithms etc.).
|
| Java reduces memory management concern relative to C++, but you
| still have reference leaks, you still need to free resources like
| file handles, connections etc. Also Java is no different than JS,
| C#, Python, etc. in that regard.
|
| Java DOES NOT prevent race conditions.
|
| Java DOES NOT mean you don't have to optimize.
|
| -------------
|
| All in all this reads a bit like a JS developer who just
| discovered Java and is excited. That's good, but my conclusion is
| Java isn't underhyped. Or overhyped. It's hyped just about as
| much as it needs to be.
| cnity wrote:
| > Interfaces in TS are structural, but classes are nominal.
| Typeguards can be either.
|
| Is this true? I might be missing something, but this snippet to
| me suggests otherwise[0].
|
| [0]:
| https://www.typescriptlang.org/play?#code/MYGwhgzhAECyCeBhcV...
| slver wrote:
| Sorry, you're right. I was thinking about "instanceof" which
| is a native JS feature, and it matches classes nominally.
| cnity wrote:
| Got you. I was a little disappointed that TS only had
| structural type checking, but then it's still better than
| nothing.
| slver wrote:
| To be honest it makes sense for it. It means if something
| (a library, browser API etc.) has no type, you can write
| an interface for it and hint for it, without depending on
| anything else.
|
| You can think about the structural type as a hash check
| on a type. If the hash matches, chances are it's the type
| you want. Collisions are possible, but highly unlikely,
| hence why in practice it works great (and we still have
| instanceof and tagged types).
| [deleted]
| batushka3 wrote:
| Java development is like eating fish with bones and caughing to
| get them loose ocasionally. My stomach hurts when I think Python
| jobs may run dry and I'll need to go back to Java.
| vikingcaffiene wrote:
| There is no greater sin than to say something positive about Java
| on the orange site...
|
| IMO Java and C# and other compiled languages have the opposite
| problem with languages like python and JavaScript (I love all
| these languages btw). It's easy to get up and running quickly
| with the latter. It's not until your project has grown in
| complexity when the formers value becomes apparent. This is
| similar to mongodb vs say, Postgres.
|
| Also modern Java has picked up a lot of the better ideas from
| Kotlin and Scala. I still prefer Kotlin but I think a lot of
| criticism I read is referring to older versions of Java.
| packetlost wrote:
| As someone currently trying to juggle a massive, extremely
| complex Python project, our code looks very Java-esque just so
| we can actually understand what's going on. Java/C# absolutely
| have a place, but the heavy startup mentality here will always
| lean towards "whatever lets me pump out my crapware and go to
| market fastest". Startups aren't known for producing well
| maintainable code (not that you can't make maintainable code
| with JS/Python, it just gets _much_ harder at higher complexity
| scales).
| vikingcaffiene wrote:
| Agree. It's YAGNI until you YNI. ;p
| eyelidlessness wrote:
| I think the discussion about TypeScript, and particularly type
| guards, really misses the point. Structural typing and manual
| type narrowing is basically what you'd do anywhere you don't know
| some data's type in the first place--for instance when you get
| some JSON from an external service. It just happens that that's
| fairly common in JS/TS.
|
| It's also a natural consequence of TS explicitly choosing not to
| expose its type system to the runtime; a choice which confuses
| many, but makes sense given the potentially unpredictable
| performance impact that could have. But there are plenty of good
| tools for declaring validation and getting types "for free",
| allowing you to choose explicitly where you want to incur that
| runtime cost--typically at API/network boundaries.
|
| This is not much different from interface/protocol/contract based
| typing, which often appears in a goofy way in Java: class Foo
| implements IFoo. But when you work in an environment where
| interface typing is commonplace and done well, it really helps
| guide good modular design.
| ramoz wrote:
| I align with most of these purists. But I don't think the
| verbosity matters. Its not a bottleneck when you're using Java
| because you shouldn't be in a position to care about such things.
| Hell, it's probably beneficial in the extensive SDLC you're
| probably working in.
|
| Sure, java has its place and enables fine productivity in
| enterprise dependent workloads & scale; but that scale's
| complexity is often nominal, because what's unique about a
| traditional java-based system? Why would you use Java to be
| unique... the jvm is perfectly magical? nah.
|
| Don't generalize engineering, lol, "feels good"... I think you
| mean "personally comfortable" which is what the oracles and jet-
| brains want you to feel. There is no art in java.
|
| I'd struggle to invest so deeply or engrain myself in an
| enterprise setup vs whatever personal/business circumstances Id
| be in that situation. If you really want to be hip in that type
| of world go .NET
| zkmon wrote:
| I completely agree with the author. When writing Java code, you
| get a sense of standing on a bed rock that never lets you down.
| You can be assured that you get everything you need. It is like a
| childhood friend or relative who always stands besides you and
| supports you. I don't get that sense when using any other
| languages though I have been using them for same number of years.
| The other languages sometimes annoy me by misguiding me or by
| being poor in some aspects, but never such case with Java. I have
| total respect to this language and I go to it whenever these more
| hyped languages give me a chance to do so.
| throwaway189262 wrote:
| Java is rock stable and "complete". Not just the language itself.
| Build tools, JVM, profiling, dependency management. Everything is
| at least decent, most language problems were solved years ago. I
| have used many languages and nothing comes close to Java in the
| balance of speed, flexibility, ecosystem, and polish. If you're
| not sure which language will be best for a project, Java is
| perfect.
|
| I work on a codebase with hundreds of thousands of lines that
| haven't been touched in 15 years. We're on Java 11 with plans to
| update to 17 later this year. Our 8->11 upgrade took me 3 days on
| a million+ line codebase. And when we released there were zero
| bugs related to the upgrade.
|
| Java has the stability keep projects maintainable over decades.
| The only mainstream language with comparable backwards
| compatibility is C.
| api wrote:
| Java was heavily hyped back in the 1990s and 2000s. It's still a
| decent language and has a number of things to recommend it, but
| today we have things like Go and Rust.
|
| I think it really fell out of favor due to Oracle's litigious
| handling of it. As soon as Oracle bought it I remember people
| actually cancelling Java projects and changing languages.
|
| Another problem is how complex and verbose it got. Original
| late-90s Java was pretty clean but eventually the ecosystem fell
| in love with enterprise style cruft and overengineered
| everything. It's less a problem with the language than the
| community though. Like C++, you do not _have_ to use every
| pattern and language feature... but many people think you do and
| write ridiculously complicated verbose code.
| Jaxkr wrote:
| > I think it really fell out of favor due to Oracle's litigious
| handling of it.
|
| Thanks for the info. Didn't know this. I use AdoptOpenJDK and
| am grateful the free version is so fully featured.
|
| I'd imagine back in the day Oracle Java reigned supreme and
| their licensing terms were a real concern.
| api wrote:
| I have heard about Java quite a bit more ever since Oracle
| lost against Google at the Supreme Court. I don't think
| that's a coincidence.
| twic wrote:
| Back in the day, Java came from Sun, who were generally
| pretty cool about it.
|
| Oracle bought Sun in 2010, things looked okay for a year or
| two, then it started to get scary.
|
| The situation now is not scary: there is a community process
| to manage the language and library definitions, the JDK is
| open source, with Oracle contributing, there are other
| significant contributors (notably RedHat and IBM ... so now
| just IBM), and there are multiple freely-available high
| quality binary releases of the same source.
|
| It could potentially get scary again. If Oracle stop
| contributing to the open source JDK, and instead work on a
| closed-source version of their own, then it's not clear that
| there is enough developer power among the remaining
| contributors to keep things moving at a healthy speed. But
| then, if that happened, maybe users would abandon Java rather
| than pay Oracle, so it would be a suicidal move for Oracle.
| Or, if that happened, other contributors could step up
| contributions to hoover up customers from Oracle. But it's
| not entirely reassuring to be depending on game theory like
| this.
| askonomm wrote:
| > today we have things like Go and Rust
|
| Except that if you actually code for money, neither of those
| have many jobs available. Heck, in many cities I've looked
| _any_ jobs available. Java is still one of the most employable
| tools out there simply because it has a lot of jobs. Sometimes
| the hype-train of HN makes me think that people here are just
| coding for a hobby or their own start-up and entirely forget
| how the real world actually works.
| api wrote:
| HN is indeed full of startup warriors. Go and Rust are
| popular for new fangled stuff, but you are correct that there
| are a massive number of Java jobs around.
| vinceguidry wrote:
| Ah another new dev enamored with IntelliJ. You'd think one day
| they'd realize that it's the IDE they love, not the language. But
| in my observation, they never do.
|
| Reminds me of a rationalization I heard once about how people
| pick their brand of cigarettes. They all taste like crap until
| you're finally addicted, then the one you happen to smoke at the
| time is now your brand.
|
| Every new language / stack now gets compared to Java with
| IntelliJ because that's what they learned. Can't tell 'em any
| different.
| cosmotic wrote:
| The static types enable IDEA to do its magic. It's nowhere near
| as good for Python, JS, PHP, etc. C# support is great though.
| Jaxkr wrote:
| A fair point, haha! I tried PyCharm recently (normally use VS
| Code) and I was really impressed.
|
| I think my emotions are misplaced: I might just like IntelliJ.
| vinceguidry wrote:
| IntelliJ is nice, don't get me wrong. You can't really get a
| nice (for 2020) experience out of Java without it, because
| it's an absolute slog of a language. Just... so... much...
| ... ... ... everything. IntelliJ cuts through all that. You
| can get a nice for 2005 experience with Eclipse. Without an
| IDE, Java really falls down.
|
| Java is a phenomenal piece of kit, the amount of engineering
| that went into the JVM is insane. But people took the lessons
| from Java and put them into newer languages, that don't have
| the problems Java does that require an IDE.
|
| My love is in the language that IDEs don't and can't really
| add much to, Ruby. Emacs give me all I need.
| [deleted]
| lenkite wrote:
| > Without an IDE, Java really falls down.
|
| VSC has a pretty good Java experience.
| w4rh4wk5 wrote:
| Yeah right; after almost 2 years the standard formatter
| still occasionally deletes code. [1]
|
| [1]: https://github.com/redhat-developer/vscode-
| java/issues/1132
| disgruntledphd2 wrote:
| But doesn't it use the eclipse compiler?
|
| Certainly the emacs mode does:
| https://projects.eclipse.org/projects/eclipse.jdt.ls
| cle wrote:
| Even Emacs handles Java pretty well these days, with lsp-
| mode and jdt.ls (powered by...Eclipse). I've been using it
| for the past year and it works great.
| a_imho wrote:
| Exactly, tooling is underhyped, programming languages do not
| exist in a vacuum. Intellij is at the top of the power
| continuum as far as I'm aware. It is a perfectly valid to pick
| Java just for this single reason imo.
| thrower123 wrote:
| Pretty much anything general purpose that I might want to use
| Java for, I can use C# instead, and I like it better.
|
| Cross platform support used to be the trump for Java, but
| DotNetCore/5 works on Linux and has nearly everything ported over
| now.
| shock wrote:
| What IDEs exist for Linux that are free and on par with Eclipse
| for Java?
| thrower123 wrote:
| I don't much like Eclipse, but it's a fair point.
|
| Rider is really good, better than Visual Studio in most
| respects even, but it does cost about $100/year for a
| personal license. There are some programs JetBrains offers
| for free licenses though.
|
| VS Code is also an option, albeit much less powerful.
| nonbirithm wrote:
| The amount of vitriol Java receives in the game development space
| is rather strong. However, whenever people dismiss Java as being
| a bad language, I can't help but think of Minecraft.
|
| Yes, it's one of the few mainstream titles where Java has been
| successfully applied, but I believe Minecraft's success was
| specifically because it was written in Java.
|
| With no JVM, there would have been no Minecraft mods at the level
| of flexibility that Forge provides, and the game would probably
| have stagnated in comparison with the sheer amount of community
| content from the past ten years that's available. Being able to
| use libraries like ASM that allow you to transform the compiled
| bytecode in radical ways were possible only because Minecraft
| targeted a virtual machine. The incredible thing was that this
| was _in spite of_ the obfuscation Mojang applied to the compiled
| source. If it was possible to create a flexible mod system at all
| thanks to the JVM, people were just too motivated for any
| deterrence to stop them.
|
| For the people who say that Minecraft should have been written in
| C++ or something from the start, because Java is a mediocre
| programming language, there's Bedrock Edition. Nobody I know
| cares about it enough to play it. For all its bloat and
| performance issues, the benefits of the JVM were simply too
| convincing.
| strictfp wrote:
| Bedrock is by far the most popular version of Minecraft.
|
| It's the version used on all handhelds and consoles.
| slver wrote:
| > The amount of vitriol Java receives in the game development
| space is rather strong.
|
| Java is a language with mandatory GC, tiny objects scattered
| around the heap (poor locality), and no value types or low-
| level memory access.
|
| This makes it very poor for games (you know, other very basic
| ones).
|
| But they're rapidly addressing these concerns.
| kaba0 wrote:
| For the great majority of your code base, it doesn't matter
| (look at scripting languages inside game engines), and for
| the performance critical parts, you have excellent profilers
| and can easily pinpoint which function creates too much
| garbage and can write that part in an imperative way with
| arrays and that's it. It will run plenty fast.
|
| Especially now with ZGC, not even tiny freezes should happen.
| wing-_-nuts wrote:
| >But they're rapidly addressing these concerns.
|
| Expand?
| slver wrote:
| Project Panama (Foreign Memory Access):
|
| https://medium.com/@youngty1997/jdk-14-foreign-memory-
| access...
|
| Project Valhalla (Inline Classes aka Value Types):
|
| https://dzone.com/articles/project-valhalla-fast-and-
| furious...
|
| The links I picked are a bit random but they'll get you
| going with the basics.
| mrighele wrote:
| This is true for JS too, but I never hear as much hate for
| that language.
|
| Also there are classes of games for which the latency
| introduced by a GC may not be that much relevant (e.g.
| strategy or simulation games).
| Ashanmaril wrote:
| You probably don't hear as much hate for JS as a games
| language because it's not even on the table for a
| consideration when making a moderately intensive game
| slver wrote:
| > This is true for JS too, but I never hear as much hate
| for that language.
|
| Really? https://www.google.com/search?q=JavaScript+is+the+w
| orst+lang...
|
| If it exists, some people hate it. If it's popular, most
| people hate it. It's a universal law. /s
|
| Anyway, you never hear "JS is not suitable for high-end
| games" because with JS that's kind of self-evident. While
| with Java, some people don't know enough to realize that.
|
| > Also there are classes of games for which the latency
| introduced by a GC may not be that much relevant (e.g.
| strategy or simulation games).
|
| Strategy/simulation games can get quite big/complex. Keep
| in mind you're not just modeling the units, but also the
| terrain the various particle effects and so on. You can
| definitely pull off something like StarCraft 1. But people
| want games to match the capabilities of their hardware, not
| that of a Pentium from the 90s.
|
| And performance remains crucial on mobile. I.e. you may get
| the game going, but it'll suck your battery empty in record
| time.
| chii wrote:
| > no value types or low-level memory access.
|
| i dont think you need value types at all, and you can
| simulate it by using byte buffers with an abstraction on top
| of it. After all, what's the difference between value types
| and a byte array?
|
| As for things like low level memory access - you also don't
| need that in most cases. Graphics libraries will give you
| enough access. And for any other case, you can always JNI
| into native code, or call any existing system calls or
| libraries. Interop between java and native is not that bad
| (cumbersome for sure, but still possible).
|
| The only reason java gets poor performance is the coder doing
| java is too used to producing garbage (or is too
| inexperienced to write high performance java code). you can
| easily avoid most performance problems in memory by pre-
| allocating and reusing memory by pooling. These techniques
| are already commonly employed in C.
| saagarjha wrote:
| Why even use a high language at all when you can just write
| the assembly directly? Clearly you can write "Java" that is
| patently unsafe in an effort to eke out some performance,
| but this is not what most people would consider reasonable
| or desirable. When writing Java, you almost always want to
| go with the flow, and that at the moment means creating
| objects. The general fix for this is to have good
| abstractions for places where heap allocations can be
| elided, not dropping down to lower-level primitives in an
| ad-hoc way.
| slver wrote:
| > i dont think you need value types at all, and you can
| simulate it by using byte buffers with an abstraction on
| top of it. After all, what's the difference between value
| types and a byte array?
|
| The difference is a bit like coding in Java vs coding in
| assembler (more below in an example).
|
| > The only reason java gets poor performance is the coder
| doing java is too used to producing garbage (or is too
| inexperienced to write high performance java code).
|
| Read about Entity Component Systems, the leading
| architecture of high-performance game engines these days.
|
| To do this in Java, with the implied memory locality, would
| basically mean storing your entire game state in
| bytebuffers, and constantly unpacking and packing them to
| do any operation on them. And when you unpack them if you
| unpack them to a random object in heap, you negate the
| entire purpose of the locality of a bytebuffer. So you
| somehow need to do the job raw, reading everything inline
| and putting it back inline, so you can stay on the stack.
|
| I also doubt that the get/put calls you'd need to do to
| get/set every number would be free. So performance would
| probably end up quite terrible.
|
| > you can easily avoid most performance problems in memory
| by pre-allocating and reusing memory by pooling.
|
| If you make an object pool in Java you'll save on memory
| alloc/dealloc. You won't achieve memory locality, so your
| code will be much slower than languages where you can do
| that.
| kaba0 wrote:
| Having thousand NPC objects around is no problem at all.
| The rendering part is the only thing critical/numerous
| enough that you may have to optimize to such a low level.
| slver wrote:
| Not sure what you cover by "NPC objects" but they easily
| can participate in physics and AI as well (or at least
| basic scripted behavior).
|
| Also significant game state is not only represented by
| renderable content.
| kaba0 wrote:
| Well, if it's physics as well, then yeah having a
| separate NPC objects may not be the best idea (though if
| the physics engine awaits some primitives, like for each
| "object" 3 coordinates before simulation, and then sets
| the corresponding position on each NPC, it may be fast
| enough). But Valhalla really is coming, and until many
| many games have more than enough performance packed in
| the JVM already.
| georgeecollins wrote:
| >> The amount of vitriol Java receives in the game development
| space is rather strong.
|
| I think this is because of the way it handles memory. It's like
| the clunkiness of C++ without the power to optimize. Also,
| compared to python it is fast, but not compared to C or Rust.
|
| That said, for 99% of applications the Java garbage collector
| is safe and tends to produce reliable code. The article is
| right in that Java is an extremely useful language with good
| tools. Games are an edge case.
| kaba0 wrote:
| > Also, compared to python it is fast, but not compared to C
| or Rust.
|
| It is comparably fast. Much more close to them than to
| python.
| correct_horse wrote:
| I think the Minecraft mod scene happened because java is easier
| to deobfuscate than C++. JVM bytecode doesn't have as many
| opcodes as x86_64 and JVM bytecode's opcodes are on average
| simpler. I suspect that modding a new unobfuscated game written
| in C++ that contains debugging symbols would be far easier than
| modding Minecraft was before obfuscation maps were available.
| But games rarely ship like this, since they would be easy to
| pirate.
| donatj wrote:
| > For the people who say that Minecraft should have been
| written in C++ [...] there's Bedrock Edition. Nobody I know
| cares about it enough to play it.
|
| Been playing for just under ten years, everyone I know plays
| Bedrock these days. I built and manage a very popular tool /
| Minecraft community and while I don't have actual numbers, my
| general sense is the majority of players run either console or
| mobile Minecraft - all of which are Bedrock at this point.
|
| If you don't care about modding or particularly complex
| redstone, I don't know why you wouldn't run Bedrock. It's far
| more stable, reliable and performant. My laptops fans rarely
| come on in Bedrock but never shut off in Java.
|
| In my eyes Java is the public prototype / feature target and
| Bedrock the _actual product_.
| scaladev wrote:
| >I don't know why you wouldn't run Bedrock
|
| Because not everybody runs Windows? I don't consider mobile
| and console platforms as gaming, but that's just my biases.
| TrickyRick wrote:
| > I don't consider mobile and console platforms as gaming,
| but that's just my biases.
|
| Gatekeep much? You know that you just excluded probably 90%
| of all gamers right there?
| Twirrim wrote:
| > Because not everybody runs Windows? I don't consider
| mobile and console platforms as gaming, but that's just my
| biases.
|
| Most PC gamers use Windows, consoles or devices. The non-
| Windows gaming market is very small.
|
| While I prefer Java edition, my kid much prefers Bedrock,
| because it has the main killer feature of being able to
| share a world directly with friends. Anyone that's an XBox
| Live friend can see when they're playing on-line, and join
| the world. No need to set up a realm, run my own server
| online somewhere, or punch a hole through the firewall to
| the minecraft server at home etc.
| donatj wrote:
| I actually personally run the Bedrock Android version on my
| Mac with a launcher. It's a little temperamental but still
| preferable to Java Edition in my eyes. I mostly play on
| Windows and Xbox however.
|
| - https://mcpelauncher.readthedocs.io/en/latest/ - it's out
| of date but they link a fork that works.
| zanellato19 wrote:
| wtf.
|
| Mobile I was used to, but consoles as well is next level
| gatekeeping.
| thu2111 wrote:
| It's probably worth noting that Minecraft has an incredibly
| lackadaisical approach to Java and Java upgrades in general.
| They're still on Java 8 and thinking maybe about upgrading to
| Java 11 at some point, although the performance benefits of
| going to the latest versions are really quite enormous in
| almost any benchmark.
|
| There's an additional problem: when Notch first wrote it, he
| had some experience of doing games on the JVM and wrote the
| code in a performance sensitive style. But it wasn't a fully
| OOP style that people associate with clean, well designed
| codebases, so when Notch moved on, they immediately went and
| introduced tons of tiny classes for things like points or
| vectors where the prior code simply passed the components as
| parameters. That trashed performance. Again, newer JVMs are
| better at gobbling this stuff up, but it didn't help.
| Valhalla will eventually remove this tradeoff.
|
| At any rate, Minecraft is a very good example of why more
| people should target the JVM for video games: modding is
| real, it can create communities that propel your game further
| than ever. It's not a great example of how to get the best
| possible game performance from the JVM. At all.
| Yeroc wrote:
| That's curious. I don't play Minecraft myself but my kids do.
| They have Bedrock Edition (via Nintendo Switch) and they keep
| begging me to get them the Java Edition. This is partly
| because it seems all the prominent YouTubers are on Java
| Edition.
| npteljes wrote:
| Minecraft is not successful _because of_ its programming
| language, it 's successful _despite_ the questionable choice of
| its programming language. Games can be fine and successful
| withouth being top-notch software, they need to be enjoyable,
| not performant. Cities:Skylines is also successful, and with
| decent hardware you get like 40 fps. Again, not its hardware
| efficiency made it popular.
|
| Regarding modding, I think if the game is successful, then
| there will be at least a small handful of people that write a
| modding interface for others.
| boyadjian wrote:
| For me, Java can be very useful for amateur game programming,
| especially using IntelliJ. You have libraries like LWJGL, that
| are very powerful, and much others like ODE4J
| MrPowers wrote:
| Java has gotten better over the years (borrowing good ideas from
| Scala) and is maintainable. They make a huge effort to keep Java
| backwards compatible, even across major releases.
|
| I depend on some ancient Java libs and they still work just fine.
| It's a huge relief when major version bumps don't break
| everything.
| thiht wrote:
| > Java is fun to write, productive
|
| What the hell? I don't think we have the same definition for any
| of these words.
|
| I know Java has changed quite a bit since Java 8 (Java 9 being
| the last version I used professionally before switching
| completely to Go), but I just can't write Java again, it's
| physical. When I want to try a new Java feature and think about
| writing the scaffolding code, my stomach actually hurts.
|
| Not to mention the pain point that it still is to install and
| configure a JDK, and make it work properly with Intellij, why is
| it still so complicated?
|
| Then there's Maven and Gradle that are just... bad, I have no
| other phrasing. I hear a lot of people saying Maven already
| solves all the problems we have with today's tools but that's
| just not true, even the entire Maven stupid lifecycle should be
| thrown away!
| dmingod666 wrote:
| "fun to write" give them IDE-driven-developers a text editor
| and see how much "fun" it is.
| detaro wrote:
| "Don't let them use the appropriate/preferred tool for the
| job and see how much fun it is" is a fairly nonsensical
| proposal for pretty much every profession.
| dmingod666 wrote:
| I can't think of one other major programming language that
| relies so heavily on the IDE to do the development work,
| can you?
| panzerboy wrote:
| C#
| metaltyphoon wrote:
| That's not even remotely true
| slver wrote:
| Let's assume it is. So what?
| detaro wrote:
| LabVIEW ;)
|
| More seriously, IDEs exist and work, so if people are
| productive with them, what does "but you'd be less
| productive if you didn't have your IDE!" gain us? C++ is
| a bit less verbose, but still the wide majority of devs
| uses an IDE with it because it does useful things.
| Programmers of Lisp etc use editors that have tools to
| edit Lisp files better. etc. I get not liking the
| existing options as a matter of personal taste, but
| that's different.
| eurasiantiger wrote:
| OOPHP.
| dmingod666 wrote:
| lolz! had to google that one.
| slver wrote:
| Give them text-driven-developers a magnetic needle and a hard
| drive and see how much "fun" it is!
| Nursie wrote:
| On my new air I installed IntelliJ and brew-installed Java. It
| all works.
|
| Where's the pain?
| thiht wrote:
| Wait for updates or projects requiring a different JDK.
| wing-_-nuts wrote:
| Then you use something like jenv or an alternative
| pulse7 wrote:
| You just install any JDK in any directory - nothing to
| configure there - and then point IntelliJ to this
| directory... If this is hard, then... hmmm....
| dunefox wrote:
| Acting like Java tooling isn't more difficult than other
| languages is dishonest. Starting with a Java project is
| considerably more complex than with most other languages.
| "Missing manifest" or issues with classpaths are not
| intuitive.
| WatchDog wrote:
| Building a standard maven or gradle project is
| substantially easier than most other languages, in my
| experience.
|
| I don't have to setup a $GOPATH, downloading dependencies
| doesn't kick off a million scripts that end up running
| native compilers, like in the node/ruby/python/php
| ecosystem. I can build and run a Java project on almost
| any system, without making substantial changes to my
| environment and without giving up and using docker for my
| dev environment.
| blandflakes wrote:
| Ok I'm super sympathetic to how annoying it is to manage
| JDKs, but holy hell it's not like Python tooling (for
| example) is a walk in the park. Are you using system
| python? Is it pip, with it's constantly breaking
| upgrades, or poetry, which isn't necessarily production
| ready? Do you have a virtualenv? Pipenv? How do you
| package it?
|
| Java tooling can be painful but to me it's VERY squarely
| middle of the road.
| dunefox wrote:
| I agree, Python is horrible. And I don't even like the
| language itself much. I like Julia, for example -
| although packaging there isn't great either.
|
| My problem is that Java is one of the (probably) 3
| biggest languages in use, both investment and dev time
| wise, and it's overall just _not that great_.
| blandflakes wrote:
| I honestly wish I knew what was better - it's not like
| I've ever used a build tool I didn't hate in some way.
| Part of the problem with Java to me is that (IMO) maven
| is the only build tool that doesn't make force me to
| spend significant time maintaining the build as well as
| the code, but maven is... very much a local maximum.
|
| I generally agree with "not that great" - Java the
| language I actually find fine, and to me it scratches a
| lot of the pragmatism that Go tries to get, with
| different warts in each. I try to avoid the Java
| framework ecosystem so I don't have to deal with beans
| and annotations and piles of codegen, not because I don't
| like the language. And Android has done much damage to
| the community's impression of Java.
| Nursie wrote:
| "gradle init --type java-application"
|
| Honestly I haven't had to deal with the issues you talk
| about in the last five years (which is as long as I've
| been writing java commercially, before that I was mostly
| a C developer).
|
| Having had recent experience with Go and Javascript/Node,
| I can't say either struck me as especially easier or more
| intuitive to get started with.
| dunefox wrote:
| Most likely because you have dealt with them many times
| before that you don't notice them anymore or prevent them
| in the first place while setting up a project. But
| everytime I need to do something in Java I get bitten by
| this stuff, and I'm not the only one.
| Nursie wrote:
| I've never had to, was my point. Not since waaay back in
| the day when I was first learning about it (more than 20
| years ago). I came to java (commercially) 5 years ago,
| and it's not that I've dealt with it so much I don't see
| it, I've never had to deal with it.
|
| Maybe things have got much better in the last handful of
| years, I don't know. My experience of getting started
| with a java project in that time has been no worse (and
| not really any better either) than in other languages.
| spentu wrote:
| People tend to forget that everything seems easy when you
| know things.
|
| I have been in situations where I had to compile some
| projects from other people and it has been painful every
| time. Especially as I might be in an environment where
| there are no IDEs that wrap things up for you.
|
| Everyone has different experiences and requirements for
| their projects and not everything is same as it is for
| you. Don't take it personally and try to passively insult
| other people's intelligence.
| pulse7 wrote:
| The parent said "Not to mention the pain point that it
| still is to install and configure a JDK, and make it work
| properly with Intellij, why is it still so complicated?"
| It is NOT complicated. Everybody can try this out. But if
| the parent had these problems on some specific project
| where thigs were messed up, he should not generalize
| these problems from a specific project to every Java
| project... Everybody can install a fresh IntelliJ IDEA
| and fresh JDK - and see that this is easy and not
| complicated at all.
| eurasiantiger wrote:
| That is a perfect demonstration of the toxic attitude
| I've come to expect from Java fanatics.
| pulse7 wrote:
| I've just written an argument which can be verified. If
| you call me a "fanatic" because of writing a provable
| argument I can at least say I have a freedom of speech...
| eurasiantiger wrote:
| I did not mean to make a judgment on substance, rather I
| made an observation about tone that seems to reflect a
| disagreeable personality. Would you agree?
| pulse7 wrote:
| I submitted a >>single<< disagreement, so please don't
| generalize this into a "disagreeable personality". Please
| provide opposite arguments - for example some facts that
| show how complicated it is to setup new JDK in
| IntelliJ... such arguments will improve quality of
| discussion here...
| twic wrote:
| Installing a JDK is trivial. What do you mean by "configure" a
| JDK? You mean tell your IDE it exists? Wow.
| jiggawatts wrote:
| You just described how I feel about C++
|
| I used to be a C++ _wizard_. I did things with that language
| that were just unspeakable. I used features so obscure that I
| don 't even know if they have an official name.
|
| Then after I dunno... the five hundredth nonsensical linker
| error, something in me just snapped and I just can't ever go
| back there.
| omginternets wrote:
| It seems like grappling with these arcane features _feels_
| productive, at first. You enter a flow state and after a
| while, something works that didn't work before. It's only
| when you step back and ask what actually got accomplished
| that you realize it's time wasted.
| ragnese wrote:
| I agree that Java isn't fun or productive, but I'll qualify
| that statement with "for me".
|
| I really do believe that the reason we have programmer holy
| wars is because we approach problem solving in different ways.
|
| The way _I_ approach solving a problem with a computer program
| is almost incompatible with the Java programming language. And,
| no- this is not a thinly veiled way to shit on object oriented
| programming. I can work in an object oriented paradigm _just
| fine_. It 's just Java specifically that doesn't work for me.
|
| Here are some examples that _constantly_ bother me when writing
| Java:
|
| * Null. Enough said.
|
| * Writing value types used to be very tedious and bug-prone
| before Records. I haven't written Java with Records yet, but
| I'm glad to know that they'll be there if/when I do Java again.
| Even for an object-oriented architecture, value types can be
| useful and I use plenty of them.
|
| * Type erased generics are painful. Especially with interfaces.
|
| * The number and arithmetic APIs are incredibly frustrating. No
| unsigned numbers, silent wrap-around on overflow, silent data
| truncation on casts, etc. I have zero confidence that my Java
| code that deals with numbers is robust at all.
|
| I'm sure that many programmers don't even notice these things,
| because they way they interact with program design is just
| different than my way. But when I write Java (or mostly any JVM
| language) one or more of these issues are on the forefront of
| my mind with almost every single line of code I type. It's
| almost unbearably frustrating.
| V-2 wrote:
| I also don't understand where is the "fun to write" aspect
| exactly that the author insists about.
|
| _" This cannot be understated: Java simply feels good to
| write"_
|
| But why?
|
| The only explanation that follows is that _" a lot of this is
| due to the craftsmanship JetBrains puts into IntelliJ IDEA.
| Everything is autocompleted, jump-to-definition is fast, find-
| usage works well, and refactoring is easy"_.
|
| I too think that IDEA is an excellent IDE, but why should Java
| take the credit for it. If anything, the more it needs an
| excellent IDE in order to feel pleasant, the worse it says
| about the language itself.
|
| It really looks to me like the _" ignorant computer science
| undergrad"_ mainly worked with JavaScript (having only dabbled
| with C++ and a few other languages as part of his uni courses),
| and got excited by discovering a proper IDE and a statically
| typed language that happens to have a low entry threshold.
| watwut wrote:
| > I too think that IDEA is an excellent IDE, but why should
| Java take the credit for it. If anything, the more it needs
| an excellent IDE in order to feel pleasant, the worse it says
| about the language itself.
|
| It actually does, the language itself makes those features
| possible. The reason javascript does not have as good IDE is
| that language itself stands in a way.
| dunefox wrote:
| You mean by having a (not very powerful) static type system
| and constructs that serve as name spaces for auto-
| completion lookup. Any language with modules and a static
| type system supports this, if the effort is put into
| creating the tools.
| blacktriangle wrote:
| It's a bit of a "stop hitting yourself" situation. Java
| features make awesome tooling possible, but awesome tooling
| is necessary due to some really bad features of Java. So I
| don't care if a different language has worse tooling when
| it also does not have the problems that Java has that the
| tooling solves.
| watwut wrote:
| The result of that tooling is better. It is easier to
| read, navigate, refactor and write then supposedly
| superior language without tooling.
|
| The large the project, the bigger the gap gets.
| scaladev wrote:
| >Not to mention the pain point that it still is to install and
| configure a JDK, and make it work properly with Intellij, why
| is it still so complicated?
|
| IDEA can download and configure one of multiple JDK
| distributions in a single command:
|
| https://www.jetbrains.com/help/idea/sdk.html#jdk-from-ide
| Twirrim wrote:
| > Not to mention the pain point that it still is to install and
| configure a JDK, and make it work properly with Intellij, why
| is it still so complicated?
|
| I used to work for a company that had about 100 different Java
| web applications running, each with their own JDK. It was
| _trivial_ to set up and maintain. Was it wasteful? Sure. I
| shipped a JDK with each application. Was it hard to automate?
| No. Basic deployment automation made it trivial. The JDK was
| just an application artifact alongside the JAR file, and the
| application starting script set JAVA_HOME pointing to it for
| that process.
|
| IntelliJ makes it trivial to maintain a project specific JDK.
| You just add the location of your JDKs to it (IIRC it can even
| auto-populate the list), and then choose the JDK from a simple
| menu within the IDE.
| hamilyon2 wrote:
| Ideas in the foundation of maven are old, but that is the only
| complaint I have with this tool. Problems it solve are not new
| either.
|
| As for amounts of scaffolding, IntelliJ product writes it for
| you. And modern Java forces you to write only a half of it
| anyway.
| oftenwrong wrote:
| >Not to mention the pain point that it still is to install and
| configure a JDK, and make it work properly with Intellij, why
| is it still so complicated?
|
| You just download the JDK, and set JAVA_HOME to point to it
| when you want to use it.
|
| For IntelliJ, you set the JDK in the project settings. It has a
| menu where you can point it to a JDK it knows about already, a
| JDK on your FS, or you can select a JDK for it to download for
| you. Couldn't be easier.
|
| Java build systems are mostly terrible - you're right about
| that. Maven has the best tooling support, and is actually very
| straightforward, but a bit limited. I have had a number of bad
| experiences with Gradle. The Blaze-family build systems (Bazel,
| Buck, Pants, Please, etc) are far more sane, but have low
| adoption.
| kaba0 wrote:
| You actually went to Go and say that java is painful to write?
| Wth?
| McScroogy wrote:
| I used to feel like you, but I have come back to Java.
|
| Other languages have other pains, for example I have physical
| revulsion against the version management hacks for python or
| ruby (rbenv and stuff like that - somehow hacking environment
| variables on the fly to manage multiple installations of the
| language).
|
| Two years ago I wrote a small web app in Python and I found
| hosting very complicated, compared to Java. PaaS exist but are
| very expensive.
| stunt wrote:
| > Java simply feels good to write. A lot of this is due to the
| craftsmanship JetBrains puts into IntelliJ IDEA.
|
| You can put it another way and say it doesn't feel good to
| write Java without JetBrains.
| offtop5 wrote:
| >When I want to try a new Java feature and think about writing
| the scaffolding code, my stomach actually hurts.
|
| Like, if you're out of work for a couple of months and the only
| way to feed your kids is to take a Java job, I don't think
| you'd pass it up. I wouldn't pass it up either even though I
| don't like Java. The whole language feels like it's designed to
| meet some minimum lines of code requirement.
|
| If you're working on a team, strongly typed languages like Java
| and C sharp are a must. Otherwise it can get extremely hard to
| figure out what exactly other people are doing.
| thiht wrote:
| > Like, if you're out of work for a couple of months and the
| only way to feed your kids is to take a Java job, I don't
| think you'd pass it up.
|
| I would honestly consider the alternatives. I'd probably take
| it in the end because money is good, but I'd try to flirt
| with manual work instead, if Java was my only option.
| offtop5 wrote:
| >I would honestly consider the alternatives. I'd probably
| take it in the end because money is good, but I'd try to
| flirt with manual work instead, if Java was my only option.
|
| Eh. 150k working on Java enterprise systems vs working at
| Costco for 15$ an hour. Java isn't great, but it's still
| much easier than C or C++ imo.
|
| In a perfect world we could all work in Python all day, but
| that's not life
| dunefox wrote:
| If starving is the only reason to take a Java job then it
| doesn't exactly speak for it.
|
| Python, for example, is also strongly typed. You most likely
| mean static typing, which is very useful but not exactly
| Javas or Cs strong suit either.
| offtop5 wrote:
| Yeah, Static typing. In C# I swear this the only reason I
| can get anything done( Visual Studio's auto complete is
| nice).
|
| Most people basically work to eat, I've taken Java jobs
| just because I needed the work. It can always be worse.
| scottious wrote:
| Totally agree, especially about Maven/Gradle. I'd also like to
| point out that the popular Spring Framework is just...
| annoying. It's full of magic. You have to know the right
| incantations to get anything done. Somehow there is too much
| documentation and not enough at the same time.
|
| I've never seen a Java program in my entire career that was
| actually fast and not a huge pain to work with. I'm working on
| a new one right now and the prototype/skeleton literally does
| just basic CRUD operations and the CI/CD pipeline takes 7
| minutes.
|
| Golang was a breath of fresh air for me.
| sto_hristo wrote:
| curl -OL <jdk url>
|
| tar -xzvf <jdk archive>
|
| <set JAVA_HOME env var to point to dir>
|
| <add to PATH $JAVA_HOME/bin>
|
| So complicated.
| hurril wrote:
| All your projects are belong to that one version of the JDK.
| Great success.
| sto_hristo wrote:
| No success is greater than 100 different projects needing
| 100 different JDKs on the same machine. But somehow i don't
| have a problem building an android app in its own java,
| while the backing service is done in a completely different
| jdk. It's not ideal as i would want the latest language
| features in the android side, but that is an android
| problem.
| P_I_Staker wrote:
| So, I'll admit to not reading TA, but I find this headline a bit
| silly. Isn't java one of the most widely adopted languages, maybe
| THE most used? Top tier at least. People aren't using it for no
| reason, same with C.
| Hasz wrote:
| If you feel that way about Java, I'd love to know how you feel
| about C. Fast, runs everywhere, tons of interoperability, fairly
| compact language, your choice of compiler, etc.
|
| Also, congrats on graduating from CU! Just graduated last
| semester.
| jiriknesl wrote:
| I think, there are three things in this one. JVM, Java itself and
| how it is used.
|
| JVM is great. I think it gets a lot of love (in comparison with
| .NET Core which is IMHO as good as JVM). In this one, you see JVM
| everywhere except desktop apps.
|
| Then, there's Java itself. As a language, it really isn't as
| modern and doesn't provide much what isn't already available in
| C#, Scala, Kotlin, or even PHP or TypeScript. And it doesn't
| provide some things that other languages have. So on this scale,
| once you know Java, you can be productive, but I doubt you will
| be more productive than someone who knows C#, Scala, etc.
|
| And then, there's Java culture. Plenty of Java devs (mainly in
| J2EE, Spring world) don't develop in classes, they develop in
| design patterns. AbstractFactoryStrategy, complete abstracting
| out databases, five layer data models, classes for things that
| should be enums. It's a matter of taste, you don't have to do it
| (Android devs don't do this that much even when they use Java).
| And I think all the coolness of modelling, UML, etc. is over.
|
| I think, you can be productive in Java (if you use it a bit like
| PHP). I think JVM is fantastic. For me, I am 8 years in Clojure
| world and I wouldn't go back to design patterns, writing (in Java
| often generating) dozens of lines of code just to insert
| something to the database (entity, mapping, repository, business
| logic layer, etc.) when in Clojure, this would be three lines
| (defn, schema check, insert).
| strictfp wrote:
| I left Java due to the culture.
|
| I actually think the core language is great. And under Suns
| management Java was largely what golang is today; it was the
| pragmatic choice and it put the focus back onto writing code
| and away from complicated language features.
|
| Then IBM stepped in with JEE, and it completely transformed
| Java into a language for bureaucrats and over-complicators.
| JEEs ethos was that the programmer is stupid and that the
| framework saves the programmer from their own stupidity. Not
| the greatest of ideas if you ask me.
|
| Sane people jumped to newer languages. I tried to stick around
| and argue against bureaucracy, but in the end I realized the
| pointlessness of it all.
|
| Now I'm ironically back with c++, but still the community is
| much purer and focusing much more on actual coding than snake
| oil.
|
| Still write Java on my spare time and love it for it's relative
| ease of use, speed, and clarity. Not the most portable,
| ironically, but my language of choice for prototyping.
|
| Java still has some true high quality libraries in it. I'm yet
| to find a good replacement for Doug Leas concurrency libraries
| in other languages. And the containers are great. And despite
| all the flak it gets, I actually think Swing is really good for
| whipping up a simple UI.
| maxehmookau wrote:
| I totally agree. I learned Java throughout my entire first-year
| at University (CompSci 2009) and it gave me such an excellent
| grounding in how OOP works.
|
| I don't use it day-to-day in my work anymore, but the principles
| I learnt were definitely useful!
| hcarvalhoalves wrote:
| I don't care much about the language, but the JVM/ecosystem might
| be underhyped, yes.
|
| There's no GC'ed VM that competes with it still, compatibility is
| taken seriously and what build systems + Docker try to solve now
| with a lot of moving parts was solved years ago with uberjars.
| victornomad wrote:
| I used to dislike Java until I had to refactor code with
| Javascript...
| [deleted]
| bcatanzaro wrote:
| Java: the worst of both the interpreted and compiled worlds.
| andrepd wrote:
| >Surprising absence from university curriculum
|
| Oh if only that was true. Sadly it's probably one of the most
| popular languages in undergrad courses around the world.
| pbadenski wrote:
| For me personally, it's really important how productive a
| language environment is after a few years of development.
| Therefore:
|
| - debugging environment
|
| - memory and CPU profilers
|
| - compilation and linting time of 100k+ codebases
|
| - IDE support for 100k+ codebases
|
| - static analysis & software architecture metric tooling
| (complexity, dependency analysis etc.)
|
| - inherent scalability of the language, maturity of patterns &
| practices of scalability
| praptak wrote:
| I remember when Java _had_ the hype - Virtual Machine! WORA! Runs
| in your browser! Your microwave will have Java! That was around
| my 3rd year in CS at university.
|
| A few years passed and I got to program in Java in a commercial
| environment. It was J2EE 1.4.
|
| It was bloated, had a really heavyweight and crappy ORM
| (JavaBeans? Active Beans?). As a framework it sucked. Also it was
| boring business applications, the cool kids used Python at that
| time.
|
| Just my personal snapshot of how Java lost the hype for me -
| crappy "dozens of layers" framework and an unappealing niche.
| twic wrote:
| Early Java EE was astoundingly bad. It's vastly improved now
| (from EJB 3 onwards), but still not wonderful.
|
| In one job, i used an enterprise framework that actually
| predated Java EE. Several ideas in EE were copied from it. But
| incredibly, this framework was substantially _better_ than
| early EE. I believe, because that framework was built by people
| who actually needed to ship products to customers to pay their
| bills, which limited the amount of overcomplication and
| obstruction they could get away with. There was no such limit
| on Sun 's architects.
| praptak wrote:
| Java the language has also improved since that time. Pre-
| generics Java was pretty bad. Unlike Go (whose creators
| obviously had decades of history to learn from) there weren't
| even any baked-in polymorphic types.
| Nekorosu wrote:
| Java is Criminally Omnipresent.
| k__ wrote:
| lol, Java was overhyped for quite some time.
|
| It even did deliver at the beginning, but then it stagnated.
|
| Now, it's just bloated. The syntax, the programming model, the
| package manager, the runtime. If you look at systems like Eclipse
| and Jenkins, even the software developed with it seems to go that
| way.
| mr_tristan wrote:
| Java really hasn't had great _social_ stewardship for some time.
| Oracle has really just kept the tech going, but there 's a number
| of very real issues:
|
| Newcomers get no real guidance on what to do. What do you
| install? It can be any of a number of different vendors. How do
| you deploy? The official documentation hasn't been updated since
| Java 8:
| https://docs.oracle.com/javase/tutorial/deployment/index.htm....
| It still mentions applets! (Which are going to be _removed_
| soon.) IMO, all projects should be using jlink and shipping a
| slim runtime they 've used to test against
| (https://docs.oracle.com/en/java/javase/11/tools/jlink.html).
| There's basically zero documentation on how to use this for non-
| modular applications, and you have to find and apply non-official
| plugins to get that work done. I continue to see most deployments
| using the _entire_ JDK which, honestly, has been unnecessary for
| _three years_.
|
| Nobody really knows what they mean with "OpenJDK". They might be
| talking about some distribution based on the source code. Or,
| they might be talking about a download from jdk.java.net. Or they
| might be talking about installations from Azul, Microsoft, AWS,
| or any number of ad-hoc vendors because the name is unlicensed.
| This is a big deal, because I've had team matest install
| "OpenJDK" and actually end up with ad-hoc builds that weren't
| tested, and had random bugs.
|
| Professionally, I've ended up having to deal with fixing
| landmines because Java devs tend to not learn the intricacies of
| their frameworks as well.
|
| The technology is still going strong, and is moving faster since
| the modularization. Loom
| (https://blogs.oracle.com/javamagazine/going-inside-javas-pro...)
| will be a big deal... but I wonder, will most devs practically
| understand how to take advantage of it?
| The_rationalist wrote:
| And so is Kotlin!
| eurasiantiger wrote:
| This reads like it was written by someone with Stockholm
| syndrome.
| 131012 wrote:
| I see a lot of comparison with Python and Rust and other
| languages, but not with C# which I feel is the true java
| equivalent. Anyone worked with both? I feel this is the
| comparison I'd really appreciate.
| throwaway10110 wrote:
| Wait till the author discovers Kotlin his mind will be blown
|
| Kotlin should have called itself Java++ imho, that would help
| adoption in enterprise where managers might not know difference
| with Java
| Lapsa wrote:
| "Type guards are my least favorite TypeScript feature. They're
| essentially duck typing that you have to implement yourself and
| trust that they're implemented correctly." Amen
| NuSkooler wrote:
| Ah, someone who wasn't around to see the years of _real_ Java
| hype.
|
| I've had to work with Java professionally for a number of
| projects over the years, and honestly the only use for it I've
| actually agreed with as "good" is on Android -- and as we know,
| Google tweaked it, battles ensued, yadda yadda ...and even they
| are moving away from it.
|
| The shitshow that owns it is good enough to avoid it, let alone
| the language itself.
| daptaq wrote:
| > Java simply feels good to write. A lot of this is due to the
| craftsmanship JetBrains puts into IntelliJ IDEA
|
| The issue with Java is that you need an IDE for it to be usable.
| That's not an argument for Java itself.
| kaba0 wrote:
| It needs an ide as much as any other language. Java programmers
| are just lucky that they have the best IDEs around.
| LaserToy wrote:
| Java is not hyped because it is a tool. Like a microscope, it
| just does what it supposed to do.
|
| IMO, if you want to get a descent job in a large company working
| on backend systems, you want to learn: Java, C/C++ or recently
| Go. You will be able to build pretty much anything, from a micro
| service to self driving car.
|
| If you want to stick to startups, you can do well with anything
| else till it growth, experienced engineers are hired and rewrite
| it in one of those languages.
| baby wrote:
| I always refused to work with C++/Java, and I managed to get a
| job with Rust at FAANG. If I can do it, you can do it :P
| LaserToy wrote:
| Why would any reasonable person limit their choices based on
| a tool? Rust or Blast - whatever
|
| I really don't care what language I'm using if it it doing
| the job. I use Java, Java Script, Go, Python, Scala when
| appropriate.
| Brian_K_White wrote:
| You just asked "Why would any reasonable person care what
| they spent half of their waking hours of their life doing?"
|
| The fact that you don't care does not make everyone other
| than you not a reasonable person.
|
| Frankly I don't see how any reasonable person could fail to
| develop some preferences, but I bet you would not like it
| if I called you unreasonable, or perhaps just
| unsophisticated.
| LaserToy wrote:
| Because preferences are based on emotions are not
| rational.
|
| I'm talking about picking a tool that does the job
| according to the requirements (speed, memory,
| debuggability), not based on what some YouTuber said.
|
| We are engineers and paid for results. It help with
| carrier to embrace it.
| baby wrote:
| Because some of these tools bring more joy or despair than
| others. A worker is only but his tools.
| erik_seaberg wrote:
| Mastering a more powerful tool prepares me for more
| appealing roles solving harder problems. Time spent on a
| weak tool is just wasted; it'll never get better and
| neither will I.
|
| Java has become reasonable though I'd always reach first
| for Scala or Kotlin (maybe Clojure?) I'd like to work with
| Rust but it seems hard for an employer to cost-justify the
| dev work to avoid paying for G1.
| loopz wrote:
| Because it is most likely not your choice.
| askonomm wrote:
| The "learn Go" part always puzzles me. In a city of 15 million
| (Buenos Aires), I can find about ~3 jobs for Go, but ~800 for
| Java. Clearly Go isn't going to be paying anyones bills anytime
| soon. At least not in this part of the world.
| Laremere wrote:
| I read this post far more as "JS/TS are overhyped" than "Java is
| Underhyped". Javascript is a mediocre at best language which has
| been thrusted into the limelight by the fact that it's the
| language of webpages. Some people have decided that they want to
| write the same language everywhere, so they started using it for
| the backend.
|
| The points listed in the article for why Java is great apply to
| many of the workhorse languages in the industry today.
| vardump wrote:
| Java (and JVM) sure has its advantages. And I enthusiastically
| advocated it in the nineties, when no one seemed to see its
| strengths.
|
| It was simple, performed well (other than GUI and classloading
| sometimes took a minute) and was very portable. I even wrote some
| demos in it in the late nineties to show it can actually do 60 Hz
| realtime graphics.
|
| Over time, the ecosystem got pretty strong. JVM improved and the
| performance got better. Life was good.
|
| But something bothered me. Those crazy dependencies, how
| everything was overcomplicated. Perhaps JVM got _too_ good at
| optimizing and monomorphizing abstractions away? You didn 't have
| to pay performance penalty for complexity anymore!
|
| Worse, all these layers of dependencies and abstractions made it
| nearly impossible to actually understand the whole system and
| figure out root causes for the issues other than by using
| arguably fairly mature and good tooling available.
|
| All this made me puke. So I stopped coding in Java, maybe 2005 or
| so. Haven't looked back.
|
| Nowadays I'm happy developing things where Java doesn't stand a
| chance. Kernel drivers, bare metal firmware, tricky low level
| stuff, vectorized high performance code. Things that just can't
| get bloated or they might not work at all.
|
| I don't have strong feelings about JVM much anymore, as long as I
| don't have to touch it.
|
| JVM's high power consumption bothers me though, we're wasting so
| many nuclear powerplants worth of power for pretty much nothing.
| Of course the same is true for many other high level languages.
|
| Perhaps we should work on high level languages with low power
| consumption?
| kaba0 wrote:
| Actually, the JVM uses comparably less power than other high
| level languages.
|
| And frankly, you simply can't write all the software in use in
| low level languages. Yeah, it is theoretically possible but not
| feasible
| vardump wrote:
| I agree on both counts, but my point still stands that having
| a high level language with low power consumption would be
| great.
|
| Don't ask me how to create one. But perhaps someone who sees
| this has some ideas that gets us started on this path. You
| never know.
|
| Power consumption doesn't get enough attention from software
| developers.
| kaba0 wrote:
| Yeah I completely agree. But perhaps we should not start
| from scratch again, maybe another JVM implementation with a
| focus on power consumption? Perhaps even a fork of OpenJDK
| is enough.
| abhi_kr wrote:
| I have programmed in Python, Ruby, JS, C, Go and Java. The main
| reason Java receives so much flak is because it's setup is not
| beginner friendly. JS, Python, Ruby make it so much easier to
| just write a program and run it. Naturally, any novice programmer
| would quit Java in the setup process itself. It's not easy in
| Java to just write a program and run it instantly.
|
| But once you are through that painful process, there is no other
| ecosystem more stable than Java. Things don't move too fast and
| that's a good thing for production applications.
|
| I do dislike the verbosity sometimes while doing something that
| would take just a few lines in python or ruby. But IntelliJ more
| than makes up for it.
| monster_group wrote:
| I vividly remember writing my first few Java programs. It was
| the most ridiculous thing to get it to run. JRE can't find the
| program when both the source and class files are right there in
| the directory where you are trying to run the program from. You
| have to set the classpath first else it won't ever find your
| program. A beginner would be definitely frustrated. I was. I
| earn my livelihood writing Java code but I have recommended
| Python to both my brother and son who are just getting into
| programming.
| Gnarl wrote:
| Norwegian is underhyped; performs way better than Swedish. Stop
| quibbering over programming languages already and just build
| well-tested, robust software.
| stunt wrote:
| It's more accurate to say that "JVM is Underhyped". I think more
| people will agree with that.
| stephankoelle wrote:
| I know Hacker News doesn't like java a lot. I just want to speak
| up: I love Maven, Wildfly, IntellyJ and JAVA. Kudos to the
| brilliant minds behind JAVAs evolution: Brian Goetz and Mark
| Reinhold.
| fallous wrote:
| Having been around in the 1990s, I can assure you that
| "underhyped" is the very LAST thing I think of when Java is
| mentioned.
| cesarb wrote:
| I agree, my first reaction on seeing the title was "Underhyped?
| Really? You must be joking."
|
| The reason Java can be a nice language/runtime today is the
| sheer amount of resources available to be poured on it due to
| all the hype in the 90s. It was supposed to save us from all
| the effort porting our software to many operating systems and
| processor architectures (the computing world was much less
| homogeneous back then). It was supposed to run everywhere
| without modification, from the smallest smartcard to the
| biggest mainframe. It was supposed to not only run within our
| web browser, but also be the implementation language of our web
| browser, or even the whole operating system. It was supposed to
| magically be faster than even C and C++ (those who used Java
| back then can recall how slow it was; for instance, hanging the
| whole browser for a whole minute while the JVM started up was
| not uncommon). Everything was supposed be written in Java; it
| was not good enough to call a native library for whatever
| functionality you wanted, it had to be rewritten in pure Java.
|
| Java was a mediocre language. All that hype led to a virtuous
| cycle, which allowed it to grow into what it is today.
| sideshowb wrote:
| > It was supposed to not only run within our web browser, but
| also be the implementation language of our web browser, or
| even the whole operating system
|
| Tbf with Android that came to pass, at least until the applet
| apocalypse
| qayxc wrote:
| Look at their age. We've arrived in a world were young
| developers rediscover old tools and missed the time when Sun
| Microsystems brute forced Java down the throat of everyone.
|
| Heck, here were native Java CPUs, Java Smartcards and different
| editions like JavaME for what today is branded IoT devices.
|
| I cannot get the "write once - run everywhere"-slogan out of my
| head to this day. I don't even want to imagine a world where
| Java Applets actually "won" the internet and we would have
| proprietary multimedia applets instead of <audio> and <video>
| tags or even just CSS...
| fallous wrote:
| I recall that we rapidly turned the "write once run
| everywhere (WORE)" slogan into "WORN- write once, run
| nowhere" thanks to all the platform-specific changing that
| always occurred.
| da39a3ee wrote:
| I was surprised to find out that so many of the "software
| architecture" books are not about how to architect backend
| ecosystems comprising multiple communicating services, but
| instead are about patterns to use to organize large java
| codebases.
| drdude wrote:
| I prefer Scala, even more elegant and expressive... not to
| underestimate overuse of its features leads to confusion hell.
| gpapilion wrote:
| I was surprised that java was missing from CS curriculums at
| University of Colorado Boulder. Roughly 20ish years ago we moved
| the data structures class to java at the university I worked at.
|
| There were a lot of complications(students hadn't learned java
| previously), and it took some understanding of what the JVM was
| doing, vs c/c++ where pointers made it very clear what was
| happening. This was also in very early days of java, just at the
| beginning of JIT and hotspot.
| mikl wrote:
| One word: Oracle.
|
| Given their insidious licensing and litigious nature, I wouldn't
| touch Java with a ten meter pole.
| [deleted]
| SavageBeast wrote:
| Open JDK is pretty good now - Im migrating our prod env away
| from Oracle JDK soon. The smoke test env running Open JDK has
| passed all tests. No reason to stay on Oracle anymore. There
| are other JDK makers and they work great.
| cesarb wrote:
| OpenJDK is pretty nice, it's the "CentOS" of the Java world.
| Which, given the recent events around CentOS, should give one
| pause. If Oracle ever closes the language again, will
| development follow one of these other JDK makers, or will
| they all trail the "official" Java like in the past
| (GCJ/Classpath, Harmony, and so on)?
| mjevans wrote:
| I didn't see this when I wrote my reply under
|
| theamk's post about
|
| > There are a few reasons to avoid Java today.
|
| Hard agree, and had the same thought BECAUSE Oracle.
| zerotolerance wrote:
| Speaking as a near 20 year Java programmer, Java is criminally
| bloated at every level. The ecosystem has been covering for its
| shortcomings since y2k. That ecosystem is so thick and full of
| abstraction that no two devs from different framework backgrounds
| would recognize the others code as Java. And the abstraction...
| it is a language for people who are more interested is the
| abstractions than actually getting things done.
| tirrex wrote:
| I agree with you.
|
| Actually, Java has great tooling, JVM is very nice, it has
| great potential for high performance code generation. It has
| everything for debugging. But at the end of the day, language
| is driving people to write bloated software.
|
| I just wonder, how come e.g Linux kernel code 100 times more
| readable than any project in Java? More importantly, how did we
| come to this point that we accept bloated/unreadable code in
| the name of higher/better languages?
| thu2111 wrote:
| Linux isn't readable because of C. My god, just go look at
| the source code of most GNU projects like glibc or gcc if you
| want to disabuse yourself of that notion.
|
| Linux is highly readable because Linus imposes readability on
| it through sheer force of will, and because they are willing
| to sacrifice driver API on the altar of clean code. The
| result is a very efficient and readable kernel that hardly
| anyone uses in the environment with the most complex and
| heterogenous hardware i.e. desktops and mobiles. Android
| doesn't really use Linux these days. Since some years it has
| developed its own stable driver ABI that bypasses the kernel
| for most things.
|
| If all Java codebases were run by a dictator-for-life who
| could sacrifice trifling details like adoption in order to
| get the most readable code possible, you'd find you'd like
| them a lot more too. And a few such codebases are actually
| like that! Look at the source code of the JDK itself sometime
| (not the bits by Doug Lea though), or Guava, or really quite
| a few open source Java projects have readable and nice code.
| loopz wrote:
| Java won by its portable deployment model, stack traces, GC,
| libraries and security sandbox safety. In over two decades,
| very few other platforms have come close to its promises. C#
| is perhaps much better, but has stronger proprietary ties and
| vendor lock-in.
|
| Java became overcomplicated by frameworks and design
| patterns, so has always felt bloated and slow. But has worked
| best for business logic. Though is maybe behind COBOL thus
| far, and tends to hide/obscure logic. No two java designs
| looks the same, scales well or converge to clear consensus.
| The language did lower the bar for what cheap programmers
| could accomplish faster though.
| benbristow wrote:
| > C# is perhaps much better, but has stronger proprietary
| ties and vendor lock-in
|
| What vendor lock-in? The whole thing is open source from
| the compiler to the runtime - https://github.com/dotnet
|
| If anything Java is more locked in as the most popular and
| 'official' runtime/devkit (Oracle Java/JDK) is completely
| closed source.
| Nursie wrote:
| Honestly I think it's time for some of these frameworks and
| abstractions to die, and to stop trying to be everything to
| everyone.
|
| Ship functionality as libraries, not massive sets of "Thou
| shalt do it our way in our all-encompassing , over-complex,
| hard to debug straitjackets."
|
| The language itself is not what it was, it's very capable.
| abraxas wrote:
| I don't think you experienced NodeJS development. There isn't a
| built in collections library. They all had to import a string
| leftpad function which then broke half of the world when it was
| pulled from their repository by the original developer.
| twic wrote:
| The ecosystem is large and diverse. But you don't have to use
| everything! You don't _have_ to use _anything_!
|
| I make a point of starting all new projects with just the JDK,
| and taking that as far as possible before adding dependencies.
|
| A 40k LOC codebase i work on has these external dependencies
| (plus some company- and vendor-specific libraries, which we
| would need in any language):
|
| 1. Netty, for serving HTTP
|
| 2. Glassfish JSON, for parsing and formatting JSON
|
| 3. FastUtil, for efficient collections of primitives
|
| 4. Guava, purely to get PairedStatsAccumulator
|
| 5. SimpleFlatMapper, to parse and format CSVs
|
| No frameworks, no criminal bloat.
|
| For the first few years of its life, this app used the JDK's
| own HTTP server, which was fine. Then we wanted to add
| websockets, so we needed a more sophisticated server.
|
| If there is a problem with Java here, it's that people don't
| realise you don't need frameworks. A lot of developers will
| reach for Spring, Java EE, or something else like that right at
| the start of a project, without questioning the need for it.
| But this is not a failing of the language, or a problem you
| have to impose on yourself.
| majjgepolja wrote:
| As a java n00b, thanks for listing the libraries. Do you know
| any other simple libraries which will be useful generally?
| twic wrote:
| Oh, there's millions of them. That's the problem!
| majjgepolja wrote:
| I meant "refreshingly simple" ones, as in _antithesis of
| spring boot_
| Nursie wrote:
| For http serving, I've always like SparkJava, just because
| its interface is very simple.
|
| But it's not the only way.
| CodeGlitch wrote:
| Anyone interested in modern Java should listen to their podcast:
|
| https://inside.java/podcast/
|
| (I'm not affiliated - just someone coming back to Java after 20+
| years of C++ and Python).
|
| Recent stuff includes:
|
| * Vector API
|
| * Record classes
|
| * JDK Flightrecorder
|
| * Java 16
___________________________________________________________________
(page generated 2021-04-16 22:03 UTC)