This is clearly a subjective matter, so I'm asking for your opinion on the topic if you have one.<p>For high level programming, is the value of simplicity really that important, realistically? I'm talking about manifestos like the [grug brained developer](https://grugbrain.dev/) and [harmful.cat-v.org](http://harmful.cat-v.org/software/java) where most rants point at Go as a better alternative. From my personal experience, Go is very nice to develop in exactly because of the focus on simplicity, but I'm struggling to find a realistic use for Go. Want to build a web-stack? Modern tools like Next.js, web workers, supabase etc. makes this process very easy, even though you have to write JS/TS which does not value simplicity as highly. New tech like Blazor and LiveWire lets you ditch the API pattern altogether when all you want to ship is a website. These techniques can reduce complexity in terms of how much code you need to write and maintain by ditching the frontend-backend bridge, but might introduce more complexity overall by having to use, say, C# for Blazor which is ever-growing with complexity and over-engineering. So, is it worth still sticking to Go and go with the good old fashion backend API + frontend pattern in your opinion?<p>When it comes to low level programming and simplicity, I struggle to find use cases for Go since we are often looking for real-time and highest performance (which Go compiler prefers speed over optimization). However, I think I'm starting to prefer C over Rust after writing a little C and previously a lot more Rust. Because I simply don't see the benefit of kinda-but-not-really-guaranteed safety with a lot of added complexity and cognitive load over the simplicity of Go or C for general purpose development. I.e. development where safety isn't a priority, because then I think Ada would be a better fit with stronger safety guarantees, no?<p>And sorry if it's controversial. I'm not looking to start a flame war, but I'm genuinely interested in learning different opinions on the matter.
Lunar went through a transition from Node/Typescript, to Java to Go and they seem to think it’s the “only” language worth building a back-end in. Which is obviously a wild statement, but having worked with C# and .Net as well as C++ for the past decade and now slowly moving into Node/Typescript I can sort of see why you would want to leave some of the “legacy” technologies like Java or C# behind.<p>Not because they aren’t excellent, but because they aren’t great to work with. C# and .Net has never been greater than they are now, and yet we increased our productivity by switching to Node/Typescript by around 20%, with the added benefit of having a single language across the stack. The latter was the primary reason for the switch and the increase in productivity came as a sort of surprise and we’re honestly still trying to figure out why our developers produce things which are measurably better at a faster pace with TS and for many a change of tech from something they’ve used for many years. I see some similar reflections and stories coming from the lunar team on why they switched from Java to Go.<p>That being said. Whatever works is always the best technology. If that’s C, C#, PHP or whatever, then that’s always going to be your best answer. I don’t think there is really any reason to “pick” the right technology from the get go, you can always worry about that when/if it becomes a problem. We didn’t switch to TS from C# because we disliked it, we did it to share our resources better. Eventually if/when we grow enough, we’re likely going to have to change things. Though maybe not. Lego seems to be doing fine on mainly Node and I doubt will reach their size any time soon.
I think you've defined the use case for Go away. Without more context, you seem to be taking use cases where you only have business logic in web apps as a consideration.<p>There's lots of other places where a developer might want something that's quite fast, but doesn't drag along a lot of dependencies. Any microservice system debugging or performance analysis might fall in that category. Incident response for kubernetes or even data center racks of servers might, too.<p>A lot of microservices that are horizontally scaled would fit that, too. You don't want huge containers with detailed configurations, because that's hard to get correct, slow to load and probably has a lot of attack surface. A minimal container would make it harder for an attacker to use access to gain further access. Sprawling Java apps are the opposite of that.
It’s never worth it to use anything other than Python. It’s just reached a point where even very complex problems are easy to “fix” in Python then “learn” in another language. I believe in 15 years all major companies will use it exclusively for web development.
for large systems, you really can't beat the implicit infra that Java and .NET bring to the table. I am dealing with 20 year old VB code that interops with new .NET core code just fine. Try saying the same for Python.<p>The larger issue with Go, which Go enthusiasts will downvote me for, is that it allows for writing absolutely garbage code that is impossible to read. Readibility is king in software development, and developers spend 80% time reading it. I won't go into the details here, but Go has no constraints for how code should be structured, leading to spaghetti code. I have first hand experience, and 30 years professional experience.
Responses to a "Why Go" question I asked a couple of weeks ago: <a href="https://news.ycombinator.com/item?id=38126816">https://news.ycombinator.com/item?id=38126816</a>
What’s wrong with Java and the JVM really, particularly when Java has concise lambdas, pattern matching, virtual threads not to mention real threads that <i>really</i> work?