Comment by the_duke

While C# is great, but the problem with programming languages, is you're net only picking a language, but a kind of company who uses it, and a kind of person who writes it.

Which means if you write C#, you'll encounter a ton of devs who come from an enterprise, banking or govt background, who think doing a 4 layer enterprise architecture with DTOs and 5 line classes is the only way you can write a CRUD app, and the worst of all you'll se a ton of people who learned C# in college a decade ago and refuse to learn anything else.

EF is great, but most people use it because they don't have to learn SQL and databases.

Blazor is great, but most people use it because they don't want to learn Frontend dev, and JS frameworks.

I love C#, but have actually found LLMs to be quite bad a producing idiomatic code because the language is changing so fast and often they don't even know about the latest language(/blazor) features. I constantly have to undo my initial prompt and rewrite it to tell them that we don't use Startup.cs any more, only Program.cs, and Program.cs is a flat file and not a class.

I'm still sad that Silverlight[0] (and Moonlight) died because people hated MS so viscerally back then.

It was actually really good for the time and lightyears ahead of whatever Flash was doing.

But people rather used all kinds of hacks to get Flash working on Linux and OSX rather than use Moonlight.

[0] https://en.wikipedia.org/wiki/Microsoft_Silverlight

And actually coming over from C++!

Or Clojure, Scala, Groovy.

and with the GraalVM, JavaScript/Node, Python, R, and Ruby.

among many others.

I guess it's reasonable to be hopeful as a Java developer nowadays.

Modern Java communities are slowly adopting the common FP practice "making illegal states unrepresentable" and call it "data oriented programming". Which is nice for those of us who actively use ADT. I no longer need to repeatedly explain "what is Option<?>?" or "why ADT?" whenever I use them; I could just point them to those new resources.

Hopefully, this shift will steer the Java community toward a saner direction than the current cargo cult which believed mutable C-struct (under guise of "anemic domain model") + Garbage Collector was OOP.

Yeah, and you might just be given a mainframe with vacuum tubes..

Like, there are 10 million Java devs, there is a whole lot of completely brand new development going in any language, let alone in such a huge one.

> most enterprise software is stuck on older versions

This simply isn’t true. 60% of the ecosystem has moved beyond Java 8 in the last poll.

you shun unnecessary complexity.

If you dont think that exists in java, spend some time in the maven documentation or spring documentation https://docs.spring.io/spring-framework/reference/index.html https://maven.apache.org/guides/getting-started/ Then imagine yourself a beginner to programming trying to make sense of that documentation

you try keep the easy things easy + simple, and try to make the hard things easier and simpler, if possible. Simple aint easy

I dont hate java (anymore), it has plenty of utility, (like say...jira). But when I'm writing golang I pretty much never think "oh I wish this I was writing java right now." no thanks

> I can reasonably likely run a 30 years old compiled, .jar file on the latest Java version.

Great, pretty much every language ever can do the equivalent. Not what anyone is talking about.

> Java is the epitome of backwards and forward-compatible changes,

Is the number of companies stuck on Java 8 lower than 50% yet? [1]

[1]: https://www.jetbrains.com/lp/devecosystem-2023/java/

> The whole field is about managing complexity. You don't shun complexity, you give tools to people to be able to manage it.

Complexity exists in all layers of computing, from the silicon up. While we can't avoid complexity of real world problems, we can certainly minimize the complexity required for their solutions. There are an infinite amount of problems caused primarily by the self-induced complexity of our software stacks and the hardware it runs on. Choosing a high-level language that deliberately tries to avoid these problems is about the only say I have in this matter, since I don't have the skill nor patience to redo decades of difficult work smarter people than me have done.

Just because a language embraces simplicity doesn't mean that it doesn't provide the tools to solve real world problems. Go authors have done a great job of choosing the right set of trade-offs, unlike most other language authors. Most of the time. I still think generics were a mistake.

From what I have heard, Graal is still quite a headache if you are using libraries that are not compatible, but maybe this is out of date.

HotSwap is really useful to be able to make small adjustments, e.g. to add a logging statement somewhere to test your hypothesis. It's probably not safe to use to change the behaviour significantly, certainly not in production :)

Last I checked Crystal’s compile time was too slow for me to deal with for anything beyond toy projects.

Swift on Linux has been a fairly horrible experience, but the language looks promising.

In my opinion they need to invest a lot more time and money into it for that. The development experience on VSCode was pretty bad (I think the LSP has a memory leak), and some important (for me) libraries aren't tuned very well yet (a Vapor webserver can sit around 100 MiB memory, whereas putting a bunch of load on the grpc implementation balloons the memory usage to >1 GiB).

I haven't followed swift too closely, but ref counting is not a good fit for typical server applications. Sure, value types and such take off a lot of load from the GC (yes, ref counting is a GC), but still, tracing GCs have much better performance on server workloads. (Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive).

For Java 25 which is planned to be released in a couple of weeks:

----- https://openjdk.org/jeps/512 -----

First, we allow main methods to omit the infamous boilerplate of public static void main(String[] args), which simplifies the Hello, World! program to:

  class HelloWorld {
    void main() {
      System.out.println("Hello, World!");
    }
  }

  void main() {
    System.out.println("Hello, World!"); 
  }

  void main() {
    IO.println("Hello, World!");
  }

Always find 'java is verbose' to be a novice argument from go coders when there is so much boilerplate on the go side of things that's nicely handled on the java side.

Every function call is 3-5 lines in Go. For any problem which needs to handle errors, the Go code is generally >2x the Java LOC. Go is a language that especially suffers from the "code padding" problem.

It's rich to complain about verbosity coming from Go.

Nonetheless, Java has eased the psvm requirements, you don't even have to explicitly declare a class and a void main method is enough. [1] Not that it would matter for any non-script code.

[1] https://openjdk.org/jeps/495

An expert Ruby programmer can do wonders and be insanely productive, but I think there is a size from which it doesn't scale as nicely (both from a performance and a larger team perspective).

PHP's frameworks are fantastic and they hide a lot from an otherwise minefield of a language (though steadily improved over the years).

Both are decent choices if this is what you/your developers know.

But they wouldn't be my personal first choice.

When did you last touch java, before 2000?

Local environments are not tied to IDEs at all, but you are doing yourself a disservice if you don't use a decent IDE irrespective of language - they are a huge productivity boost.

And are you stuck in the XML times or what? Spring Boot is insanely productive - just as a fact of matter, Go is significantly more verbose than Java, with all the unnecessary if errs.

I know, both proprietary and enterprise, right? https://github.com/JetBrains/intellij-community/blob/idea/20... (I would also link to the Apache 2 copy of PyCharm but it wouldn't matter to folks who just enjoy shitting on professional tools)