14 ms·
I personally don't like Go, and it has many shortcomings, but there is a reason it is popular regardless: Go is a reasonably performant language that makes it
by the_duke 1y ago
I personally don't like Go, and it has many shortcomings, but there is a reason it is popular regardless:
Go is a reasonably performant language that makes it pretty straightforward to write reliable, highly concurrent services that don't rely on heavy multithreading - all thanks to the goroutine model.
There really was no other reasonably popular, static, compiled language around when Google came out.
And there still barely is - the only real competitor that sits in a similar space is Java with the new virtual threads.
Languages with async/await promise something similar, but in practice are burdened with a lot of complexity (avoiding blocking in async tasks, function colouring, ...)
I'm not counting Erlang here, because it is a very different type of language...
So I'd say Go is popular despite the myriad of shortcomings, thanks to goroutines and the Google project street cred.
- zwnow 1y agoWhat modern language is a better fit for new projects in your opinion?
- aloukissas 1y agoElixir, with types
- sarchertech 1y agoThat doesn’t exist yet. Also Elixir is in no way a replacement for Go. It can’t match it for performance. There’s no mutable array, almost everything is a linked list, and message passing is the only way to share data. I primarily use Elixir in my day job, but I just had to write high performance tool for data migration and I used Go for that.
- zwnow 1y agoThis one i can get behind.
- pmarreck 1y agoI love Elixir but you cannot compile it into a single binary, it is massively concurrent but single-threaded slow, and deployment is still nontrivial. And lists are slower than arrays, even if they provide functional guarantees (everything is a tradeoff…) That said, pretty much everything else about it is amazing though IMHO and it has unique features you won’t find almost anywhere else
- agos 1y agoyeah, if the requirement is "makes it pretty straightforward to write reliable, highly concurrent services that don't rely on heavy multithreading", Elixir is a perfect match. And even without types (which are coming and are looking good), Elixir's pattern matching is a thousands times better than the horror of Go error handling
- out_of_protocol 1y agoMy vote is for Elixir as well, but it's not a competitor for multiple important reasons. There are some languages in that niche, although too small and immature, like Crystal, Nim. Still waiting for something better. P.S. Swift, anyone?
- Degorath 1y agoSwift on Linux has been a fairly horrible experience, but the language looks promising.
- sarchertech 1y agoLast I checked Crystal’s compile time was too slow for me to deal with for anything beyond toy projects.
- gf000 1y agoFor web frontend: js For ML/data: python For backend/general purpose software: Java The only silver bullet we know of is building on existing libraries. These are also non-accidentally the top 3 most popular languages according to any ranking worthy of consideration.
- zwnow 1y agoJava, lol. Enterprise lang with too many abstractions and wrongly interpreted OOP. Absolutely not.
- tedk-42 1y agoI'd swap java with go any day of the week. I never liked how much 'code-padding' is required with java `public static void main`
- gf000 1y agoIt's rich to complain about verbosity coming from Go. Nonetheless, Java has eased the psvm requirements, you don't even have to explicitly declare a class and a void main method is enough. [1] Not that it would matter for any non-script code. [1] https://openjdk.org/jeps/495 https://openjdk.org/jeps/495
- kasperni 1y agoFor Java 25 which is planned to be released in a couple of weeks: ----- https://openjdk.org/jeps/512 https://openjdk.org/jeps/512 ----- First, we allow main methods to omit the infamous boilerplate of public static void main(String[] args), which simplifies the Hello, World! program to: class HelloWorld { void main() { System.out.println("Hello, World!"); } } Second, we introduce a compact form of source file that lets developers get straight to the code, without a superfluous class declaration: void main() { System.out.println("Hello, World!"); } Third, we add a new class in the java.lang package that provides basic line-oriented I/O methods for beginners, thereby replacing the mysterious System.out.println with a simpler form: void main() { IO.println("Hello, World!"); }
- aeonik 1y agoClojure
- jiehong 1y agoMaybe weirdly I’d put swift in there.
- vips7L 1y agoSwift is my hope for the next big server language. Great type system, great error handling.
- gf000 1y agoI haven't followed swift too closely, but ref counting is not a good fit for typical server applications. Sure, value types and such take off a lot of load from the GC (yes, ref counting is a GC), but still, tracing GCs have much better performance on server workloads. (Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive).
- jiehong 1y agoTracing GC and their pauses on server workload is another tradeoff. They all have a tradeoff. You make a fair point.
- gf000 1y agoSure, though RC can't get away from pauses either - ever seen a C++ program seemingly hang at termination? That's a large object graph recursively running its destructors. And the worst thing is that it runs on the mutator thread (the thread doing the actual work). Also, Java has ZGC that basically solved the pause time issue, though it does come at the expense of some throughput (compared to their default GC).
- zozbot234 1y ago> but still, tracing GCs have much better performance on server workloads Good performance with traditional tracing GC's involves a lot of memory overhead. Golang improves on this quite a bit with its concurrent GC, and maybe Java will achieve similarly in the future with ZGC, but reference counting has very little memory overhead in most cases. > Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive Reference counting with a language like Rust only requires atomic inc/dec when independently "owning" references (i.e. references that can keep the object around and extend its lifecycle) are added or removed, which should be a rare operation. It's not really performing an atomic op on every access.
- simon_void 1y agoKotlin! personal disclosure: I'm a Kotlin fan boy. (If performance is important then Rust, but Kotlin is more ergonomic.)
- gf000 1y ago> And there still barely is - the only real competitor that sits in a similar space is Java with the new virtual threads Which Google uses far more commonly than Go, still to this day.
- nasretdinov 1y agoWell Google isn't really making a ton of new (successful) services these days, so the potential to introduce a new language is quite small unfortunately :). Plus, Go lacks one quite important thing which is ability to do an equivalent of HotSwap in the live service, which is really useful for debugging large complex applications without shutting them down.
- gf000 1y agoGoogle is 100% writing a whole load of new services, and Go is 13 years old (even older within Google), so it surely has had ample opportunities to take. As for hot swap, I haven't heard it being used for production, that's mostly for faster development cycles - though I could be wrong. Generally it is safer to bring up the new version, direct requests over, and shut down the old version. It's problematic to just hot swap classes, e.g. if you were to add a new field to one of your classes, how would old instances that lack it behave?
- nasretdinov 1y agoHotSwap is really useful to be able to make small adjustments, e.g. to add a logging statement somewhere to test your hypothesis. It's probably not safe to use to change the behaviour significantly, certainly not in production :)
- fabian2k 1y agoThere are real pain points with async/await, but I find the criticism there often overblown. Most of the issues go away if you go pure async, mixing older sync code with async is much more difficult though. My experience is mostly with C#, but async/await works very well there in my experience. You do need to know some basics there to avoid problem, but that's the case for essentially every kind of concurrency. They all have footguns.
- cogman10 1y agoSlowly but surely, the jvm has been closing the go gap. With efforts like virtual threads, zgc, lilliput, Leyden, and Valhalla, the jvm has been closing the gap. The change from Java 8 to 25 is night and day. And the future looks bright. Java is slowly bringing in more language features that make it quite ergonomic to work with.
- theshrike79 1y agoI'm still traumatised by Java from my earlier career. So many weird patterns, FactoryFactories and Spring Framework and ORMs that work 90% of the time and the 10% is pure pain. I have no desire to go back to Java no matter how much the language has evolved. For me C# has filled the void of Java in enterprise/gaming environments.
- arethuza 1y agoTo be fair those "weird patterns" weren't really Java itself but the crazy culture that grew up around it when it became "enterprise".
- Orygin 1y agoPlus it seems hopeful to think you'll be only working with "New java" paradigm when most enterprise software is stuck on older versions. Just like python, in theory you can make great new green field project but 80% of the work in the industry is on older or legacy components.
- positron26 1y agoCount Rust. From what I can see, it's becoming very popular in the microservices landscape. Not hard to imagine why. Multithreading is a breeze. Memory use is low. Latency is great.
- the_duke 1y agoRust async makes it quite easy to shoot yourself in the foot in multiple ways. Most users writing basic async CRUD servers won't notice, but you very much do if you write complex , highly concurrent servers. That can be a viable tradeoff, and is for many, but it's far from being as fool-proof as Go.
- tayo42 1y agoSome language with rust features minus memory and lifetime management and gos gc and stdlib would be possibly the language I've been waiting for.
- theshrike79 1y agoThe comparative strictness and simplicity of Go also makes it a good option for LLM-assisted programming. Every single piece of Go 1.x code scraped from the internet and baked in to the models is still perfectly valid and compiles with the latest version.
- danenania 1y agoYep, and Go’s discouragement of abstraction and indirection are also good qualities for LLM coding.
- deleted 1y ago[deleted]