6 ms·
Golang or Rust. If it’s a web service or microservice: Golang hands down. If it’s a desktop software or game engine, rust. If you just want to typescript your w
by gabereiser 3y ago
Golang or Rust. If it’s a web service or microservice: Golang hands down. If it’s a desktop software or game engine, rust. If you just want to typescript your way to success, deno and vite.
If you’re too introverted for Rust, Zig.
Java, whether it be spring, micronauts, jee, whatever, is wasting CPU and Memory in the cloud costing you and/or your enterprise money.
- riku_iki 3y ago> Golang golang is probably a good contender for business logic code where Java is widely used, but I feel ecosystem (libs, integrations) is not comparable to Java, so you take some risks while choosing golang.
- mongol 3y agoI have not used Go generics, but it's viability as a business logic language would depend on that.
- riku_iki 3y agothey have generics now, but there are other conceptual shifts: - no inheritance - error codes with explicit handling everywhere
- mongol 3y agoYes those are also drawbacks
- ArandomAccount2 3y ago[dead]
- gabereiser 3y agono inheritance but there are interfaces to be able to provide alternate implementations. Similar to traits in Rust. If it quacks like a duck, has feathers like a duck, swims like a duck… Go just assumes if you satisfy the interface, you’re good.
- riku_iki 3y agomaybe, it is just some effort for someone who coded in classic OO for last 20 years to wrap head around this new concept fast and judge if it will satisfy all/most use cases.
- Kamq 3y agoWait, what? Generic programming is a perfectly valid style, but are you saying it's essential to implement business logic? Because, like, the last 3 languages that got adopted as the default business logic language didn't have them (Java pre 1.5, C, and Cobol).
- riku_iki 3y agoand during last 20 years consensus has converged to the view point that generics are essential.
- Kamq 3y agoHuh. Guess I'm heterodox, then. I mean, don't get me wrong. It's quite useful once in a while, especially when working with containers, but I don't think of it as essential. But I'm fine with it as long as people don't overdo it.
- rerdavies 3y agoRolling your own containers really really sucks. Sucks enough to the point that it is essential, in my books.
- Kamq 3y agoMaybe I should be more clear. This thread was in the context of go generics, which generally means go 1.18, when user defined generics were added to the language. Go always had support for a minimal number of containers, I've never rolled my own when working in the language. Go had special compiler support for slices, maps, and channels before then, and they got used as the default containers for everything. Using those was annoying when you needed to do the same thing to, say, a slice of strings and a slice of ints, but if you aren't using a generic heavy style, it actually comes up surprisingly rarely. And, if I'm being honest, I'd consider most of the uses of generics I've seen the average enterprise dev use to be mistakes.
- mongol 3y ago
- kaba0 3y agoAnd it is much more verbose, it is not even comparable in observability and on real world big applications (especially enterprise) you can't get away with value types and slowing down the threads to let the GC keep up with them -- Java definitely shines in these kind of conditions (GC-wise the only competition Java has is different Java GCs, really).
- riku_iki 3y ago> you can't get away with value types and slowing down the threads to let the GC keep up with them I am not Go expert, but to me this is Go's big advantage: you can chose you want to have object GC controlled or be on stack and copied everywhere. GC controlled objects add lots of overhead, because malloc is expensive, and require lots of memory per object to track state and synchronize between thread, and that's why JVM tries to adapt something similar: https://openjdk.org/jeps/8277163 https://openjdk.org/jeps/8277163
- kaba0 3y agoSure, value types are a good thing, but they are no panacea in and of itself. Also, any non-toy GC won't be using malloc, e.g. in Java's case allocating objects is barely more expensive than allocating them on the stack: they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it, and clearing the buffer.
- riku_iki 3y ago> they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it yeah, all these logics still have significant overhead, especially memory wise, it is hard to reason when JVM decides to kick that or another optimization or not kick anything at all. With value objects you have full control and bare-metal-native performance without compromises.
- za3faran 3y agogolang is a simplistic language which lacks the modeling capability of Java, so it won't do well in large business code.
- imetatroll 3y agoTIL that projects like terraform are - apparently - not "large business code".
- za3faran 3y agoYou can write basically anything in any Turing complete language, doesn't mean it's a good idea.
- memefrog 3y ago[dead]