471–480 of 503 posts
Seems like they wrote slow memory hogging software and didn't make any attempt at optimizing it. E.g. there's no mention of AOT compilation for Java. No hints at what actually consumed 2GB of RAM. Greenfield projects are always more fun.
Probably it only uses 100mb of heap but they didn't check or tune the memory manager at all
Earlier quoted context omitted.
DI in its most fundamental form is common in Go via interfaces. People just declare that arguments to their functions must implement some interface, and the caller provides something that satisfies it. "DI" in the sense of having a more complex purpose-built DI container is less common. They exist, but I don't see them used a lot. If your application code has a ton of dependencies, the direct injection/low magic styl…
.NET's DI has constructor injection so I suppose this is similar; you just write your constructor saying "I need an `IDataProvider`" and it can come from DI or direct. Question I have for Go though. Without DI, what is the idiomatic way of supplying one of n implementations? An if-else block? Like if I had 5 possible implementations (AzureBlobStore, AwsBlobStore, GcpBlobStore, CFBlobStore, FSBlobStore) and I need to…
type BlobStore interface { /* methods */ }
// later, when initializing stuff
var foo BlobStore
switch {
case isAzure:
foo = AzureBlobStore{}
default:
foo = FSBlobStore{}
}
svc1 := NewSvc1(foo)
// Constructors are just functions and are totally
// convention/arbitrary. If the fields are public you
// can instantiate the struct directly.
svc2 := Svc2{ BlobStore: foo }The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safety... But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware software in the late 90s and early 2000s. It's cargo cult programming of the highest order. In the OP, the author…
I think we can sum it this way. The blog post writer's intuition was correct: if you write two equivalent Go and and JVM programs, the Go program would use less heap memory and have faster startup times. What they are incorrect about is the extent of these claims. It is obvious that most of the memory and startup overhead in their software comes from Spring, rather than the JVM. The JVM is probably not an ideal platf…
Earlier quoted context omitted.
> or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc). Why hasn't anyone written a good open source for this problem, now that Go has generics?
Don't know, every time I try to do anything beyond trivial using Go generics I run into some kind of issue. They haven't been around that long, it takes time for ideas to mature.
> anything beyond trivial using Go generics
Earlier quoted context omitted.
> I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze? So, replace cheap Java developers for expensive Rust devs to squeeze out some savings? It makes no sense to me.
well if the argument is cheaper, I can argue that JS/python dev would be more cheaper since there are more pool of talent
Earlier quoted context omitted.
> internal Google style guide Can we read this somewhere?
I'm not sure about Google style guild but Go's context package docs state: "Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions." https://pkg.go.dev/context Using context as a some sort of a mule is an antipattern.
> Using context as a some sort of a mule
Earlier quoted context omitted.
I'm not sure about Google style guild but Go's context package docs state: "Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions." https://pkg.go.dev/context Using context as a some sort of a mule is an antipattern.
> Using context as a some sort of a mule I never saw the term "mule" used in this way. Very succinct!
Earlier quoted context omitted.
Go can abort at any point as well. Also, ignoring an error condition (by either forgetting about it, or simply doing the nice and tidy if err dance with no real error handling in place, just a log or whatever) is much worse and can lead to silent data corruption.
>ignoring an error condition (by either forgetting about it We rely on linters to catch that, which is pretty easy to implement (no expensive intra-procedural analysis needed, which is the case with exceptions). >Go can abort at any point as well. Panics, unlike errors, are exceptional situations which generally should not be caught (a programming error, like index out of range). They're usually much rarer than error…
Earlier quoted context omitted.
Well no, startup is fast, period. You're probably just giving the class loader a ton of work on startup? I would start with checking that I think. It could also be when he's hitting "run test" it's actually "compile and run"...
> Well no, startup is fast, period. You're probably just giving the class loader a ton of work on startup? I would start with checking that I think. Ok, maybe I misspoke about the "JVM" startup. But the time between `mvn test` and it actually logging the first line of user code was in the region of 15 seconds. Every java project I've worked on has had startup time issues once they're bigger than a toy project. Saying…
Aren't Go's compile times about the same as Java's? Of course it depends on what tooling you use to package the jars.
Earlier quoted context omitted.
well if the argument is cheaper, I can argue that JS/python dev would be more cheaper since there are more pool of talent
Double agree. If Java was the right choice 10-15 years ago for cheap enterprise apps, then certainly NodeJS is the way to go today. There are heaps of cheap developers and the ecosystem is ginormous.