[deleted]
One year after switching from Java to Go
401–410 of 503 posts
Re: One year after switching from Java to Go
#402I am sure Go has many benefits, but coming from .NET I don't see a big improvement in switching to Go. .NET feels less verbose, it's batteries included, has an AOT compiler, tons of libraries, starts fast, has very good tooling and performance wise it compares well to Go. Also, it can be used for more than web apps and command line tools. Where I see a benefit, though, is using go in a large greenfield project becaus…
The big change is cultural. The places I've seen using .NET felt like cults to me, a monoculture were everyone must run windows, swearing by how powershell is the shell of the gods, ms sql being the only true data store that's the best solution for 100% of every use cases, azure being the best cloud provider, and everyone forced to use vs code because of all its fancy integration with even the pm tools.
What are the mythical .NET cults which swear by Windows, PowerShell and MSSQL you speak of? Every other ".NET shop" I know nowadays deploys to Linux hosts/container images hosted wherever and develops on a variety of systems where the OS of choice has become mostly a non-factor.
Re: One year after switching from Java to Go
#403Earlier 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.
That is funny, because I was a Java developer for many years, then Scala for a few years, and these days I mainly write Python, but the last thing I go for is creating a class. That's generally only when a set of functions in a single responsibility module need to share / mutate some state, and it's more self-documenting than passing around dictionaries.
Re: One year after switching from Java to Go
#404Earlier quoted context omitted.
AFAIK, the basic issue is still open at https://github.com/golang/go/issues/33803 and https://github.com/golang/go/issues/59715 . You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs . Go 1.19 only had this in its notes for memory changes "...includes support for a soft memory limit. This memory limit includes the Go heap and all other me…
> ...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program" Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “…
Sorry, but no - putting the burden on the developer to detect whether they are running in a container or not and then determine and adjust to cgroup settings is far too high an encumbrance on the service developer. This is a demonstrative example of a fundamental responsibility that should always be delegated to the runtime as the default behavior.
Neither Go 1.19 nor any subsequent version has "solved" this issue.
Re: One year after switching from Java to Go
#405Start up time of the JVM is 8s? I would definitely say that it depends on how their service initialization work. I have seen service accesses database to warm cache, calling other services to initialize their configuration, or simply reading config files before fully serving. And all that take time! There is no way against that regardless of your PL or runtime.
A typical no network initialized service in Java would start under 500ms (a p90, give or take).
Re: One year after switching from Java to Go
#406Earlier quoted context omitted.
With a 1980's technology out of Xerox PARC, it is called IDE.
Exactly. Although from the reply I got above it seems to be alien tech to some.
There was a 'may' in my original comment. It is metaprogramming, so you can't see every usage automatically even with "alien tech" like IDEs, unlike in case of a normal type.
Especially that we are not even talking about own code, but third-party annotations with its third-party consumers. Also, grepping is a pretty standard term, it doesn't necessarily mean literal CLI grep, but go on with your advanced tooling as if no one else would be familiar with an IDE.
Re: One year after switching from Java to Go
#407Never quite understood the attraction of dependency injection frameworks. Sure pass in your dependencies as an interface via some sort of constructor, but why all the frameworks to do so? Why all the complexity with hard to debug magic strings, annotations and finding out what's missing from the classpath at runtime? Just seems as a very complicated way to avoid creating package c that brings together package a and d…
> Never quite understood the attraction of dependency injection frameworks.
Many years ago there was a running joke that a "dependency injection framework" in PHP was a single array with stuff in it.
Then it all became much more java-like.
Re: One year after switching from Java to Go
#408Earlier quoted context omitted.
To me the implication is that the culture at this company won't allow this team to master Go either, and in a few years there will be a post describing how they moved from Go to another language. Many people like to write about how Golang is so simple, but the drawback of that simplicity is that many features of other languages are either covered by additional dependencies or by inflating code size. It's just as poss…
Golang's standard library looks pretty complete to me and they will probably master it in a month.
The mindset that you can master any programming language in a month is exactly what I meant in my previous post. There's a veritable cottage industry of "golang pitfalls" blog posts out there that show there are absolutely a lot of footguns in Go.
For example, what do you think the following should print?
values := []int{4, 8, 15, 16, 23, 42}
for value := range values {
fmt.Println(value)
}
I also like the following one:
ch := make(chan int)
ch Golang is a fine language and simpler than most, but sadly "simpler" is not the same as "simple".
Re: One year after switching from Java to Go
#409Earlier quoted context omitted.
I don't see that as a problem at all, just like I don't see header files in C++ as a major problem, there are benefits as well and Java has the best IDEs of any language I've worked in except maybe SmallTalk.
Let me know when you can work on a medium-sized Java codebase in Emacs or Vim smoothly.
I more or less live in Emacs, but I wouldn't use it for drawing pictures or writing SmallTalk either. The right tool for the job.
Re: One year after switching from Java to Go
#410Earlier quoted context omitted.
Maybe go just isn’t for you? It really doesn’t need every feature of other languages. The error handling is ideal for me, better than any other language. You are always explicit, with every function call, about “what could happen if this fails?” Maybe passing it up the stack is the best way to handle it, but also maybe it’s better to handle it somewhere in the middle. The thing that always happens with exceptions in…
Exceptions are a terrible idea. However, I strongly prefer rust error handling to Go. go: (res, err) := foo() if err != nil return err (res, err) := bar(res) if err != … Equivalent rust: let res = bar(foo)?)?; I think go should add the ? sigil or something equivalently terse. Ignoring all the extra keystrokes, I write “if err == nil” about 1% of the time, and then spend 30 minutes debugging it. That typo is not possi…
> Exceptions are a terrible idea.
I hear people say this frequently, but don't ever hear people actually state the case.
My experience is that particularly for web back-end exceptions have been incredibly useful, but I'm interested in the counter view.