[deleted]
One year after switching from Java to Go
221–230 of 503 posts
Re: One year after switching from Java to Go
#222I 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 because Go is very easy to learn and you can attract Java, .NET, Python, Javascript and even C and C++ developers so you can assemble a team fast.
Though in a microservice context it might not be a large benefit.
Re: One year after switching from Java to Go
#223Depending on how Java application was devoped, the real benefit might be breaking free from the kingdom of nouns, land of design patterns, country of OOP.
Re: One year after switching from Java to Go
#224Earlier quoted context omitted.
The JVM starts in milliseconds Probably you're loading many thousands of classes...
It certainly tells me it does. i can hit 'run unit test', sit back in my chair and zone out for 5 seconds, then come back and read that the test took 22ms.
Thanks for bringing up some painful memories. Now I'm working in C and tests take about 100ms end-to-end (multicore, no frameworks). Sometimes I re-run them for no reason just to enjoy how fast everything is.
Re: One year after switching from Java to Go
#225Earlier quoted context omitted.
> Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work. > I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself. DI is the idea that you should create your dependencies outside of the module / class / function that uses it and pass it in. This makes it easy to swap imple…
If you're doing "dependency injection" by just passing arguments to functions/modules, you're not really doing dependency injection—you're doing "dependencies" without the "injection" part. I'm not saying that DI necessitates a ton of magic, but you need at least a small framework for specifying dependencies and injecting them into your modules dynamically.
Design patterns are independent of the implementation technology.
OO and virtual functions can be implemented in C by looking up function pointers in a table.
Reference counting can be done by manually incrementing and decrementing references.
At the end of the day everything is compiled to assembly and the CPU doesn't care what ideology was in the programmer's head, except however much a given paradigm abstracts too far away from the underlying machine.
Re: One year after switching from Java to Go
#2261) There is a perfectly working AOT compiler for JVM, namely Graal Native. Sub-second startup times are easily achieavble.
2) Dependency Injection does not require run-time reflection, I made one reflectionless DI for Scala and one for C#
3) Spring is not the best DI in the Java ecosystem
Re: One year after switching from Java to Go
#227The real win for this team isn’t just switching from Java to Go. It’s breaking free from the heavyweight framework ecosystem that the JVM all but forces on you. It’s not that the JVM is bad or that Go is a silver bullet, but Go does act as a forcing function, pushing teams to write simpler, more efficient code without layers of boilerplate, indirection, and unnecessary IO. You can still do inversion of control withou…
IoC isn't even DI. IoC is saying "I need to talk to a service that handles these account operations I care about" rather than "I need a MySql connection, a coupla s3 buckets and a folder on disk"
DI can support both the "I need" and "I orchistrate" patterns.
Obviously modulo leaky abstractions! You might want to known if that account code is in L1 cache or Timbuktu.
Re: One year after switching from Java to Go
#228Earlier quoted context omitted.
Having done a lot of Java and Go, Go has much better mechanical sympathy between the language, libraries, and vm than Java does. The JIT GC in Java are marvels of engineering, but they have to be. As an example, in Java, everything is a pointer, so pointer chasing all the time, which is not good for cpu cache, etc. In Go, there is first class support for composition. The other main adjustment, if coming from Java, is…
> As an example, in Java, everything is a pointer, so pointer chasing all the time, which is not good for cpu cache, etc Strictly speaking that's not true. It's everything is a pointer in theory to make it easier to reason with and JIT / JVM optimizing in the background. There are primitive types and there are lots of tricks in the JVM e.g. escape analysis that places objects on the heap/stack etc.
Despite all the advances in JIT, I've literally never seen it correctly optimize a HashMap (happy to be proven wrong). Hopefully the renewed focus on value types can finally bring some sanity.
Re: One year after switching from Java to Go
#229There's one simple argument to never touch Java: FactoryFactory produce ArgumentFactory, ArgumentFactory.builder().build(argument)
Re: One year after switching from Java to Go
#230Earlier quoted context omitted.
It certainly tells me it does. i can hit 'run unit test', sit back in my chair and zone out for 5 seconds, then come back and read that the test took 22ms.
haha well your test did take 22ms, but starting the JVM and loading all the classes and all your dependency injection stuff probably took 5s. You can test it yourself with a tiny hello world, it's pretty fast to start.
But that's our point - you're saying java is fast (and it is ripping fast once it gets going) and the startup is fast, unless it's not.