Remix.run Logo
the_duke 4 days ago

I personally don't like Go, and it has many shortcomings, but there is a reason it is popular regardless:

Go is a reasonably performant language that makes it pretty straightforward to write reliable, highly concurrent services that don't rely on heavy multithreading - all thanks to the goroutine model.

There really was no other reasonably popular, static, compiled language around when Google came out.

And there still barely is - the only real competitor that sits in a similar space is Java with the new virtual threads.

Languages with async/await promise something similar, but in practice are burdened with a lot of complexity (avoiding blocking in async tasks, function colouring, ...)

I'm not counting Erlang here, because it is a very different type of language...

So I'd say Go is popular despite the myriad of shortcomings, thanks to goroutines and the Google project street cred.

cogman10 4 days ago | parent | next [-]

Slowly but surely, the jvm has been closing the go gap. With efforts like virtual threads, zgc, lilliput, Leyden, and Valhalla, the jvm has been closing the gap.

The change from Java 8 to 25 is night and day. And the future looks bright. Java is slowly bringing in more language features that make it quite ergonomic to work with.

theshrike79 4 days ago | parent | next [-]

I'm still traumatised by Java from my earlier career. So many weird patterns, FactoryFactories and Spring Framework and ORMs that work 90% of the time and the 10% is pure pain.

I have no desire to go back to Java no matter how much the language has evolved.

For me C# has filled the void of Java in enterprise/gaming environments.

CharlieDigital 4 days ago | parent | next [-]

C# is a highly underrated language that has evolved very quickly over the last decade into a nice mix of OOP and functional.

It's fast enough, easy enough (being very similar now to TypeScript), versatile enough, well-documented (so LLMs do a great job), broad and well-maintained first party libraries, and the team has over time really focused on improving terseness of the language (pattern matching and switch expressions are really one thing I miss a lot when switching between C# and TS).

EF Core is also easily one of the best ORMs: super mature, stable, well-documented, performant, easy to use, and expressive. Having been in the Node ecosystem for the past year, there's really no comparison for building fast with less papercuts (Prisma, Drizzle, etc. all abound with papercuts).

It's too bad that it seems that many folks I've chatted with have a bad taste from .NET Framework (legacy, Windows only) and may have previously worked in C# when it was Windows only and never gave it another look.

torginus 4 days ago | parent | next [-]

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.

CharlieDigital 4 days ago | parent | next [-]

I think you have a point with the types of resources, but in my experience, its also not hard to separate the wheat from the chaff with pretty simple heuristics (though that is likely very different now with AI and cheating!).

"Modern C#" (if we can differentiate that) has a lot of nice amenities for modeling like immutable `record` types and named tuples. I think where EF really shines is that it allows you to model the domain with persistence easily and then use DTOs purely as projections (which is how I use DTOs) into views (e.g. REST API endpoints).

I can't say for the broader ecosystem, but at least in my own use cases, EFC is primarily used for write scenarios and some basic read scenarios. But in almost all of my projects, I end up using CQRS with Dapper on the read side for more complex queries. So I don't think that it's people avoiding SQL; rather it's teams focused on productivity first.

WRT to Blazor, I would not recommend it in place of JS except for internal tooling (tried it at one startup and switched to Vue + Vite). But to be fair, modern FE development in JS is an absolute cluster of complexity.

theshrike79 3 days ago | parent | prev [-]

C# is also the lingua Franca of mobile games because of Unity.

And when the front end is C# so is the back end.

torginus 3 days ago | parent [-]

Imo, Unity C# is almost 'not real' C#, as in it uses a completely different programming model, with different object lifetimes, programming and object models. I know the execution bits are the same, but programming for Unity feels very different in every way than writing ASP.NET code (and more different than moving from ASP.NET to Spring Boot)

bre1010 4 days ago | parent | prev | next [-]

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.

CharlieDigital 3 days ago | parent [-]

I think that can be solved with an `instructions.md` and explicitly stating the language version/features to use.

theshrike79 4 days ago | parent | prev [-]

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

kstrauser 3 days ago | parent | next [-]

I was so glad it died. It was a weird proprietary replacement for Flash, which itself was weird and proprietary, except the new one was owned by a huge company that publicly stated they wanted to crush Linux and friends.

A big chunk of their strategy at the time was around how to completely own the web. I celebrated every time their attempts failed.

mhast 3 days ago | parent | prev [-]

As someone who developed in it at the time I found the reason it died was because they made new, slightly incompatible, versions every new Windows release.

After a while people got tired of doing updates.

arethuza 4 days ago | parent | prev | next [-]

To be fair those "weird patterns" weren't really Java itself but the crazy culture that grew up around it when it became "enterprise".

gf000 4 days ago | parent [-]

And actually coming over from C++!

pjmlp 4 days ago | parent [-]

It is incredible how many people think GoF has Java on it, without ever reading anything about the book.

figassis 3 days ago | parent | prev | next [-]

This, Go came and I just have no desire to go back to those languages spawned from hell that force fed me horrible patterns and called it best practices.

Go is amazing in that it lets you tell the machine what you want, simply and you can easily verify that that is indeed what the machine should be doing.

Regarding defer, idk about other, but I never assumed it was a gotcha, you read the go docs once and all is just clear and you don’t make most mistakes that others claim are footguns.

mohaine 4 days ago | parent | prev | next [-]

That isn’t Java, but spring.

That said, if on the JVM, just use Kotlin.

aeonik 4 days ago | parent [-]

Or Clojure, Scala, Groovy.

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

among many others.

lisbbb 3 days ago | parent | prev | next [-]

I spent untold hours and years mastering inversion of control and late-binding and all those design patterns that were SOOOOO important for interviews only to never really utilize all that stuff because once the apps were built, they rarely, if ever, got reconfigured to do something besides the exact thing they were built for. We might as well have not bothered with any of it and just wrote modular, testable non-OOP code and called it a day. After just about 25 years, I look back at all the time I spent using Spring Framework, Struts, and older products and just kind of shake my head. It was all someone else's money making scheme.

I'm also reminded about the time that Tomcat stopped being an application you deploy to and just being an embedded library in the runtime! It was like the collective light went on that Web containers were just a sham. That didn't prevent employers from forcing me to keep using Websphere/WAS because "they paid for that and by god they're going to use it!" Meanwhile it was totally obsolete as docker containers just swept them all by the wayside.

I wonder what "Webshere admins" are doing these days? That was once a lucrative role to be able to manage those Jython configs, lol.

Orygin 4 days ago | parent | prev [-]

Plus it seems hopeful to think you'll be only working with "New java" paradigm when most enterprise software is stuck on older versions. Just like python, in theory you can make great new green field project but 80% of the work in the industry is on older or legacy components.

lock1 4 days ago | parent | next [-]

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.

gf000 4 days ago | parent | prev | next [-]

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.

vips7L 3 days ago | parent | prev [-]

> 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.

imiric 4 days ago | parent | prev | next [-]

That may be true, but navigating 30 years of accumulated cruft, fragmented ecosystems and tooling, and ever-evolving syntax and conventions, is enough to drive anyone away. Personally, I never want to deal with classpath hell again, though this may have improved since I last touched Java ~15 years ago.

Go, with all its faults, tries very hard to shun complexity, which I've found over the years to be the most important quality a language can have. I don't want a language with many features. I want a language with the bare essentials that are robust and well designed, a certain degree of flexibility, and for it to get out of my way. Go does this better than any language I've ever used.

gf000 4 days ago | parent [-]

I can reasonably likely run a 30 years old compiled, .jar file on the latest Java version. Java is the epitome of backwards and forward-compatible changes, and the language was very carefully grown so the syntax is not too indifferent, someone hibernated since Java 7 will probably have no problem reading Java 25 code.

> Go, with all its faults, tries very hard to shun complexity

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

And Go goes the low end of the spectrum, of not giving enough features to manage that complexity -- it's simplistic, not simple.

I think the optimum as actually at Java - it is a very easy language with not much going on (compared to, say, Scala), but just enough expressivity that you can have efficient and comfortable to use libraries for all kind of stuff (e.g. a completely type safe SQL DSL)

dosethree 4 days ago | parent | next [-]

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

gf000 4 days ago | parent [-]

Well, spring is a whole framework that gives you a lot of stuff, but sure, complexity has to live somewhere - fundamentally so.

Without it, you either write that complexity yourself or fail to even recognize why is it necessary in the first place, e.g. failing to realize the existence of SQL injections, Cross-Site Scripting, etc. Backends have some common requirements and it is pretty rare that your problem wouldn't need these primitives, so as a beginner, I would advice.. learning the framework as well, the same way you would learn how to fly a plane before attempting it.

For other stuff, there is no requirement to use Spring - vanilla java has a bunch of tools and feel free to hack whatever you want!

Mawr 3 days ago | parent | prev | next [-]

> 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/

gf000 3 days ago | parent [-]

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

Go already has a breaking change.

> Java 8

Yes

imiric 4 days ago | parent | prev [-]

> 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.

skybrian 3 days ago | parent | prev | next [-]

That’s great, but are you still using Maven and Gradle? I’d want to see a popular package manager that doesn’t suck before I’d consider going back.

(Similar to how Python is finally getting its act together with the uv tool.)

gf000 3 days ago | parent [-]

There is Mill, which is pretty cool, but it is quite small.

Though Gradle is more than fine with the Kotlin DSL nowadays.

lisbbb 3 days ago | parent | prev | next [-]

My criticism of the JVM is that it is no longer useful because we don't do portability using that mechanism anymore. We build applications that run in containers and can be compiled in the exact type of environment they are going to run inside of and we control all of that. The old days of Sun Microsystems and Java needing to run on Solaris, DEC, HP, maybe SGI, and later Linux, are LOOOOOOONG gone. And yet here we still are with portability inside our portability for ancient reasons.

gf000 3 days ago | parent [-]

If you believe that's the reason for the JVM (and that it's a "VM" in the traditional sense), you are greatly mistaken. It's like saying C is no longer needed because there is only Arm and x86..

The JVM is a runtime, just like what Go has. It allows for the best observability of any platform (you can literally connect to a prod instance and check e.g. the object allocations) and has stellar performance and stability.

cogman10 9 hours ago | parent [-]

I don't think that's a mistake. Besides the promise of memory management the "write once run everywhere" promise was a huge selling point of the JVM. So much so that Bill gates famously was terrified of it.

"I am literally losing sleep over this issue since together with a move to more server based applications it seems like it could make it easy for people to do competitive operating systems." [1]

[1] https://www.joyk.com/dig/detail/1672957813119759#gsc.tab=0

EFreethought 4 days ago | parent | prev | next [-]

There are still a LOT of places running old versions of Java, like JDK 8.

Java is great if you stick to a recent version and update on a regular basis. But a lot of companies hate their own developers.

gf000 3 days ago | parent [-]

60% is in newer than 8, though. So I wouldn't write down the platform.

clumsysmurf 4 days ago | parent | prev [-]

Being able to create a self contained Kotlin app (JVM) that starts up quickly and uses the same amount of memory as the equivalent golang app would be amazing.

gf000 4 days ago | parent [-]

Graal native Image does that (though the compile time is quite long, but you can just run it on the JVM for development with hot reload and whatnot, and only do a native compile at release)

clumsysmurf 3 days ago | parent [-]

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.

cogman10 3 days ago | parent [-]

Still an issue. The main problem is for native compilation you have to declare your reflection targets upfront. That can be a headache if your framework doesn't support it.

You can get a large portion of what graal native offers by using AppCDS and compressed object headers.

Here's the latest JEP for all that.

https://openjdk.org/jeps/483

gf000 3 days ago | parent [-]

Only those reflection targets that are not "visible" from straight forward code. If you have code that accesses the "stringLiteral" field of a class, then it will be auto-registered for you. But if you access it based on user input, then you have to register it manually.

Also, quite a few libraries have metadata now denoting these extra reflection targets.

But nonetheless you are right in general, but depends on your use case.

theshrike79 4 days ago | parent | prev | next [-]

The comparative strictness and simplicity of Go also makes it a good option for LLM-assisted programming.

Every single piece of Go 1.x code scraped from the internet and baked in to the models is still perfectly valid and compiles with the latest version.

danenania 3 days ago | parent [-]

Yep, and Go’s discouragement of abstraction and indirection are also good qualities for LLM coding.

gf000 4 days ago | parent | prev | next [-]

> And there still barely is - the only real competitor that sits in a similar space is Java with the new virtual threads

Which Google uses far more commonly than Go, still to this day.

nasretdinov 3 days ago | parent [-]

Well Google isn't really making a ton of new (successful) services these days, so the potential to introduce a new language is quite small unfortunately :). Plus, Go lacks one quite important thing which is ability to do an equivalent of HotSwap in the live service, which is really useful for debugging large complex applications without shutting them down.

gf000 3 days ago | parent [-]

Google is 100% writing a whole load of new services, and Go is 13 years old (even older within Google), so it surely has had ample opportunities to take.

As for hot swap, I haven't heard it being used for production, that's mostly for faster development cycles - though I could be wrong. Generally it is safer to bring up the new version, direct requests over, and shut down the old version. It's problematic to just hot swap classes, e.g. if you were to add a new field to one of your classes, how would old instances that lack it behave?

nasretdinov 3 days ago | parent [-]

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 :)

positron26 4 days ago | parent | prev | next [-]

Count Rust. From what I can see, it's becoming very popular in the microservices landscape. Not hard to imagine why. Multithreading is a breeze. Memory use is low. Latency is great.

tayo42 4 days ago | parent | next [-]

Some language with rust features minus memory and lifetime management and gos gc and stdlib would be possibly the language I've been waiting for.

the_duke 4 days ago | parent | prev [-]

Rust async makes it quite easy to shoot yourself in the foot in multiple ways.

Most users writing basic async CRUD servers won't notice, but you very much do if you write complex , highly concurrent servers.

That can be a viable tradeoff, and is for many, but it's far from being as fool-proof as Go.

4 days ago | parent | prev | next [-]
[deleted]
zwnow 4 days ago | parent | prev | next [-]

What modern language is a better fit for new projects in your opinion?

aloukissas 4 days ago | parent | next [-]

Elixir, with types

pmarreck 4 days ago | parent | next [-]

I love Elixir but you cannot compile it into a single binary, it is massively concurrent but single-threaded slow, and deployment is still nontrivial.

And lists are slower than arrays, even if they provide functional guarantees (everything is a tradeoff…)

That said, pretty much everything else about it is amazing though IMHO and it has unique features you won’t find almost anywhere else

sarchertech 4 days ago | parent | prev | next [-]

That doesn’t exist yet. Also Elixir is in no way a replacement for Go.

It can’t match it for performance. There’s no mutable array, almost everything is a linked list, and message passing is the only way to share data.

I primarily use Elixir in my day job, but I just had to write high performance tool for data migration and I used Go for that.

out_of_protocol 4 days ago | parent | prev | next [-]

My vote is for Elixir as well, but it's not a competitor for multiple important reasons. There are some languages in that niche, although too small and immature, like Crystal, Nim. Still waiting for something better.

P.S. Swift, anyone?

sarchertech 3 days ago | parent | next [-]

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

Degorath 3 days ago | parent | prev [-]

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

agos 4 days ago | parent | prev | next [-]

yeah, if the requirement is "makes it pretty straightforward to write reliable, highly concurrent services that don't rely on heavy multithreading", Elixir is a perfect match.

And even without types (which are coming and are looking good), Elixir's pattern matching is a thousands times better than the horror of Go error handling

zwnow 4 days ago | parent | prev [-]

This one i can get behind.

aeonik 4 days ago | parent | prev | next [-]

Clojure

jiehong 3 days ago | parent | prev | next [-]

Maybe weirdly I’d put swift in there.

vips7L 3 days ago | parent [-]

Swift is my hope for the next big server language. Great type system, great error handling.

Degorath 3 days ago | parent | next [-]

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).

gf000 3 days ago | parent | prev [-]

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).

zozbot234 3 days ago | parent | next [-]

> but still, tracing GCs have much better performance on server workloads

Good performance with traditional tracing GC's involves a lot of memory overhead. Golang improves on this quite a bit with its concurrent GC, and maybe Java will achieve similarly in the future with ZGC, but reference counting has very little memory overhead in most cases.

> Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive

Reference counting with a language like Rust only requires atomic inc/dec when independently "owning" references (i.e. references that can keep the object around and extend its lifecycle) are added or removed, which should be a rare operation. It's not really performing an atomic op on every access.

gf000 3 days ago | parent [-]

And memory is cheap, especially when we talk about backend workloads.

A tracing GCs can do the job concurrently, without slowing down the actual, work-bearing threads, so throughput will be much better.

> Golang improves on this quite a bit with its concurrent GC

Not sure what does it have to do with memory overhead. Java's GCs are at least generation ahead on every count, Go can just get away with a slower GC due to value types.

jiehong 3 days ago | parent | prev [-]

Tracing GC and their pauses on server workload is another tradeoff. They all have a tradeoff. You make a fair point.

gf000 3 days ago | parent [-]

Sure, though RC can't get away from pauses either - ever seen a C++ program seemingly hang at termination? That's a large object graph recursively running its destructors. And the worst thing is that it runs on the mutator thread (the thread doing the actual work).

Also, Java has ZGC that basically solved the pause time issue, though it does come at the expense of some throughput (compared to their default GC).

gf000 4 days ago | parent | prev [-]

For web frontend: js

For ML/data: python

For backend/general purpose software: Java

The only silver bullet we know of is building on existing libraries. These are also non-accidentally the top 3 most popular languages according to any ranking worthy of consideration.

tedk-42 4 days ago | parent | next [-]

I'd swap java with go any day of the week. I never liked how much 'code-padding' is required with java `public static void main`

kasperni 4 days ago | parent | next [-]

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!");
    }
  }
Second, we introduce a compact form of source file that lets developers get straight to the code, without a superfluous class declaration:

  void main() {
    System.out.println("Hello, World!"); 
  }
Third, we add a new class in the java.lang package that provides basic line-oriented I/O methods for beginners, thereby replacing the mysterious System.out.println with a simpler form:

  void main() {
    IO.println("Hello, World!");
  }
aatd86 3 days ago | parent [-]

so getting closer to Go's syntax, n'en déplaise à certains, apparently. :-)

gf000 3 days ago | parent [-]

Except for the extra 3 lines of if err for every statement..

aatd86 3 days ago | parent [-]

Perhaps that it is coming sooner than you think... It all started with adding Value types, now syntactic refinements à la Go... Who knows? :-) You'll be very happy.

edit: hold on wait, java doesn't have Value types yet... /jk

Capricorn2481 3 days ago | parent [-]

> syntactic refinements à la Go

An oxymoron if I've ever heard one.

aatd86 3 days ago | parent [-]

???!

refinement: the process of removing impurities or unwanted elements from a substance.

refinement: the improvement or clarification of something by the making of small changes.

public static void in a class with factory of AbstractFactoryBuilderInstances...? right..? Yes, say that again?

We are talking about removing unnecessary syntactic constructs, not adding as some would do with annotations in order to have what? Refinement types perhaps? :)

Capricorn2481 3 days ago | parent [-]

> public static void in a class with factory of AbstractFactoryBuilderInstances

That's not syntax. Factory builders have nothing to do with syntax and everything to do with code style.

The oxymoron is implying syntax refinements would be inspired by Go of all things, a language with famously basic syntax. I'm not saying it's bad to have basic syntax. But obviously modern Java has a much more refined syntax and it's not because it looks closer to Go.

wing-_-nuts 3 days ago | parent | prev | next [-]

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.

lenkite 4 days ago | parent | prev | next [-]

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.

gf000 4 days ago | parent | prev [-]

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

zwnow 4 days ago | parent | prev | next [-]

Java, lol. Enterprise lang with too many abstractions and wrongly interpreted OOP. Absolutely not.

myaccountonhn 4 days ago | parent | prev | next [-]

What about php/ruby for web?

gf000 4 days ago | parent [-]

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.

keb_ 4 days ago | parent | prev [-]

Absolutely no on Java. Even if the core language has seen improvements over the years, choosing Java almost certainly means that your team will be tied to using proprietary / enterprise tools (IntelliJ) because every time you work at a Java/C# shop, local environments are tied to IDE configurations. Not to mention Spring -- now every code review will render "Large diffs are not rendered by default." in Github because a simple module in Java must be a new class at least >500 LOC long.

gf000 4 days ago | parent | next [-]

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.

keb_ 4 days ago | parent [-]

> When did you last touch java, before 2000?

August 22, 2025.

Local environments are not literally tied to IDEs, but they effectively are in any non-trivially sized project. And the reason is because most Java shops really do believe "you are doing yourself a disservice if you don't use a decent IDE irrespective of language." I get along fine with a text editor + CLI tools in Deno, Lua, and Zig. Only when I enter Java world do the wisest of the wise say "yeah there is a CLI, but I don't really know it. I recommend you download IntelliJ and run these configs instead."

Yes Spring Boot is productive. So is Ruby on Rails or Laravel.

gf000 3 days ago | parent | next [-]

Any production-grade project will use either Maven or Gradle for builds. There are CI/CD pipelines, lints, etc, how would all these work if you could only build through an IDE?

Sure, there are some awfully dated companies that still send changed files over email to each other with no version control, I'm sure some of those are stuck with an IDE config, but to be honest where I have seen this most commonly were some Visual Studio projects, not Java. Even though you could find any of these for any other language, you just need to scale your user base up. A language that hasn't even hit 1.0 will have a higher percentage of technically capable users, that's hardly a surprise.

wing-_-nuts 3 days ago | parent | prev [-]

>Only when I enter Java world do the wisest of the wise say "yeah there is a CLI, but I don't really know it. I recommend you download IntelliJ and run these configs instead."

Then they obviously don't know their tooling well, and I would hesitate to call a jr 'the wisest of the wise'

mdaniel 3 days ago | parent | prev [-]

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)

keb_ 3 days ago | parent [-]

That's the community edition. Cute and snarky comment, though.

fabian2k 4 days ago | parent | prev [-]

There are real pain points with async/await, but I find the criticism there often overblown. Most of the issues go away if you go pure async, mixing older sync code with async is much more difficult though.

My experience is mostly with C#, but async/await works very well there in my experience. You do need to know some basics there to avoid problem, but that's the case for essentially every kind of concurrency. They all have footguns.