431–440 of 555 posts
Earlier quoted context omitted.
Yes, one is a command line command, the other is a part of a build description file, so false equivalents.
Is this a joke? Or you didn't really get the simple point that build description file is not mandatory or even required for other mentioned languages.
Earlier quoted context omitted.
How does a language favor copy/pasting? Do you mean it makes code reuse harder?
> How does a language favor copy/pasting? It favors as a culture. A little copying is better than a new dependency Just like Java has culture to setup a single http endpoint one typically adds 50-60 little jar files of Spring Boot starter.
No, you add a single annotation..
Earlier quoted context omitted.
A first class citzen would have support for MAUI, and something better than VSCode like macOS gets VS4Mac.
Does Java even have a MAUI equivalent? There are other open source frameworks for GUI apps. This feels like goal post shifting.
Earlier quoted context omitted.
I think there are still a few changes in the pipe before Java is quite what it could be in terms of performance. Project Valhalla, and the foreign function and memory APIs in particular.
For non-trivial problems GC performance will be much more important, and Java will beat out go in that category with flying colors.
This is use case for writing GC benchmarks developers not for typical enterprise CRUD developers.
Earlier quoted context omitted.
I've timed it, it's very slow because it uses reflection to generate the model. The annotation processor doesn't let you avoid this step unfortunately. Native images do.
But that step only has to run as part of building it. It doesn’t have to run at every invocation. How did you try to run it? From the documentation: > The picocli-codegen module includes an annotation processor that can build a model from the picocli annotations at compile time rather than at runtime. > Enabling this annotation processor in your project is optional, but strongly recommended. Use this if you’re intere…
See here:
https://github.com/remkop/picocli/issues/539
Although looking over that issue, it looks like maybe reflection was never proven to be the source of the slowdowns.
Earlier quoted context omitted.
I wrote Java code for 20+ years and I can tell you exactly why I prefer Go: it produces native binaries. I mean, it’s also less verbose, easier to start a new project, faster to startup, has far fewer configuration knobs, has native dependency management, is far easier to build CI/CD for, compiles more quickly, has very few NPEs gotchas, has value types, and avoids idiomatic boilerplate. Go is far from perfect, but i…
That was one reason I liked Go as well, it's no longer the case though, you can produce native binaries with GraalVM.
Earlier quoted context omitted.
Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice. Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything. Third, it depends. You can set up a HTTP server in two or…
To be clear, you think this (using the web server built into the JDK): HttpServer server = HttpServer.create(new InetSocketAddress(8000), 0); server.createContext("/test", http -> http.sendResponseHeaders(200, -1)); server.start(); Contains too much magic?
Earlier quoted context omitted.
As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 fo…
Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".