331–340 of 503 posts
I work at a company that is based on a large java application. The main app takes around 20-30 seconds to startup and while it probably does a lot of stupid shit that have accumulated over the years I believe this is more common in javaland. The culture around java is kind of enterprise, do everything unnecessary complex with strange patterns you've never heard of etc etc which makes the everything unnecessary slow a…
Earlier quoted context omitted.
At work we work on a Java code base 20 years old and it is written like C. No dependency injection or other Java Web development like shenanigans. Almost every lib etc has been built in-house. It runs an MMO, it's fast. Its just way more productive/faster to work and implement something in the Java codebase than a C++ codebase that we have. Someone shared a Job posting which asked for "no java experience". It was fun…
It's kinda understandable. I've seen "Java coders" write Python for example. The first thing they do is create a class and maybe even a Factory or Interface. You can see instantly where their experience is from and it's hard to unlearn.
Currently trying to modernize a python project that doesn't use modules, just executable python files that import each other with custom sys.path hackery, which is also used for globals, no type annotations, GLib used for everything including math and string to int parsing.
Earlier quoted context omitted.
Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase. In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.
In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own. In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc…
I just now used https://start.spring.io/ to generate a project using Spring web, Spring security and Spring data JPA (Hibernate).
It generated a JAR that is 52MB.
This looks like one of the typical "we switched from A to B, whithout actually mastering A, so B is alright" kind of posts. Just on the monitoring part, Go has nothing even close to VisualVM, Flight Recorder, JRebel, VM agents, JMX. No mention of AOT compilers, JIT caches, and so forth.
And it's fine. Why continue using something you don't master? Yes you could try to master it, but it takes years. If another tool compensates your lack of mastery, why not use it?
As an example, the Go runtime does not honor container resource limits. You would think this would be one of the very first fundamental features supported out of the box by an advertised "cloud native" language.
Earlier quoted context omitted.
At work we work on a Java code base 20 years old and it is written like C. No dependency injection or other Java Web development like shenanigans. Almost every lib etc has been built in-house. It runs an MMO, it's fast. Its just way more productive/faster to work and implement something in the Java codebase than a C++ codebase that we have. Someone shared a Job posting which asked for "no java experience". It was fun…
If you write Java just like you would write Go - meaning, no reflection shenanigans, use Jigsaw to cut out unneeded JVM stuff, or use GraalVM and compile natively (which you will be able to, because you did not use any of JVM reflection magic), Java will absolutely be competitive.
Earlier quoted context omitted.
Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase. In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.
In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own. In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc…
Spring (besides itself being modular, so you only "pay" for what you use) will solve all of that for me, so I only have to write the small amount of business-relevant code and be on my way. Later on, some other developer who knows spring can join the project and feel ready at home.
Compare it to a buggy, slow to develop, slow to onramp home-grown half-solution, and it's quite a clear tradeoff, unless there are very specific requirements that make the usage of frameworks a no-go.
Earlier quoted context omitted.
To each their own. I'm not going to claim to be an expert, but as somebody who's been coding since the 80s it was a breath of fresh air to see Go do what I wanted languages to do all long instead of ramming exceptions down my throat. I have problems with Go (examples: slice behavior and nil type interfaces) but error handling is not one of them.
What challenge did you run into with exception handling? I'm curious because I've never felt it being onerous nor felt like there was much friction. Perhaps because I've primarily built web applications and web APIs, it's very common to simply let the exception bubble up to global middleware and handle it at a single point (log, wrap/transform). Then most of the code doesn't really care about exceptions. The only cas…
All you can do is what you've described - catch all exceptions at the top level and log them. It's a valid strategy so long as you don't mind your service going down at 3am because someone didn't realize that the call to Foo() on line 5593 could in fact throw exception Bar.
Explicit error handling would make it obvious that Foo() can error, allowing the programmer to do whatever's appropriate, say implement a retry loop. Said programmer would then be sound asleep at 3am instead of playing whack-the-exception.
Earlier quoted context omitted.
So the community influences the language, not the language that influence the community that explains everything
Well, it's a bit of both. Java is of course very influential, and because it uses a framework for web applications, many languages/communities started imitating that (Ruby/Rails, PHP/Laravel, JS/[Framework_of_the_day] etc.). Then Go came along with its back-to-basics approach and its standard library which is "batteries included" but definitely not a framework, and for some this is a breath of fresh air, while for ot…
Earlier quoted context omitted.
The idiomatic way to write Go is as naively as possible after you fully understand how it works. Otherwise it'll just feel like Java with shitty ergonomics. If you're ever writing Go and wish you had real classes instead of this deconstructed "mess" with struct types, methods, and interfaces, you're writing Go totally wrong.
That is certainly one way to write Go, but I wouldn't call it "idiomatic" when evil the Google Best Practices guide recommends against it[1][2]. I'll wager you'll probably find it in most other Go style guides. This is how the Go standard library itself works. While you can use http.Get() if you want to use the default HTTP client for simple apps, the library provides you the http.Client struct, where you can also ov…