Live data from Hacker News

Ask HN: Is Go simplicity worth it?

news.ycombinator.com

11–20 of 21 posts

Re: Ask HN: Is Go simplicity worth it?

#11
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.

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.

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.

Re: Ask HN: Is Go simplicity worth it?

#12
post #9

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.

Interesting take! Although, writing client sided code is not really suited at all in Python due to the horrendous performance. That can be accepted when we're waiting for IO anyways behind a server, or when a new developer is learning to program, but apart from that, it's not really optimal at all.

I’ve found the performance to be good. If you ever see slow client side performance there’s never an excuse for that in any language. JavaScript community are just bad programmers who add bloat to things unnecessarily. Anyone who’s actually benchmarked Python in the browser with real applications knows it’s impossible to see any actual difference in performance.

Re: Ask HN: Is Go simplicity worth it?

#13

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. 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 kubernet…

Good point! I want to enjoy Go, but I haven't really found the places for it... I usually come back to C# and C++ for high level and lower level problems after exploring and using modern/hyped alternatives like Go and Rust for a while. They might not be cool or idealistic, but they are very pragmatic.

Re: Ask HN: Is Go simplicity worth it?

#14
post #5

Earlier quoted context omitted.

Good point regarding .NET! The .NET CLR / VM is clever in that way. Regarding your experience with readability in Go, I have to agree in some way because the known (and controversial) explicit error handling, but what you may realize sooner or later is that handling both the happy path and erroneous path is actually a net positive. That's the difference between seeing `if err != nil {` as code pollution or actual log…

This older reply is pretty exhaustive. Go leaves critical readability structuring to devs (a bad idea). https://news.ycombinator.com/item?id=38128698

Fair points

Re: Ask HN: Is Go simplicity worth it?

#15
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.

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.

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.

Re: Ask HN: Is Go simplicity worth it?

#16
post #15

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. Not because they are…

Do you think that the 20% productivity boost might be solely because you now just have one language to work with? That's what I'm thinking, and that's why I'm personally keen to learn and use Blazor instead of the usual JS frontend.

After looking around at the current popular solutions, I've yet to find something that is as ergonomic and productive as the .NET stack in regards to creating a web-based product. You have one of the most solid backend frameworks (ASP.NET) with lots of great tools like EF Core for ORM, SignalR for real-time, now Blazor for frontend, easy authentication and authorization, etc. That just makes everything so performant.

However, that is a very high level focused development path, while I feel Go is slightly lower level where you still have pointers and such. I see it as great for CLI apps and very specific server needs where you'd want great performance and CSP threading in combination with a very easy syntax for new developers, but I don't think that's a very common use case to be honest. Even though I love Go for its focus on simplicity, it just isn't the most suitable lang for high-level work, nor is it very suitable for low-level work at the same time.

Regarding your switch from C# to TS, I understand it made sense in the last couple of years. It simplified the stack via reducing language context switching, which can be a good productivity boost depending on your team and team size. However, if you would've tested Blazor today and found it would have satisfied your frontend needs, I actually think a full C# stack will be better than TypeScript to be honest, due to the better tooling and better runtime that exists for C# compared to Node.js/Bun/Deno. I still think TS is better in the frontend department than Blazor, but that's simply because JS/TS has been the only language for frontend in a long time. I hope Blazor will gain traction as a real alternative.

Re: Ask HN: Is Go simplicity worth it?

#17
post #15

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. Not because they are…

Switching from C# to TS (especially in combination with Node which is much, much slower and has ecosystem known for vulnerabilities) is the most bizarre (if true at all) choice I have ever seen in the industry.

Re: Ask HN: Is Go simplicity worth it?

#18
post #15

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. Not because they are…

Switching from C# to TS (especially in combination with Node which is much, much slower and has ecosystem known for vulnerabilities) is the most bizarre (if true at all) choice I have ever seen in the industry.

It’s not like Nuget hasn’t had its share of supplychain attacks. I don’t disagree with you, but we don’t use external packages unless we have too (as in React) and we vet every update. So in that sense there is really no security issues compared to any other language we use.

As far as performance goes, all our heavy computation happens in C++ and for everything else the performance difference between the .Net vm and Node is negligible at our scale.

You may think it’s odd, but we’re hardly the only organisation doing it. Lego did it a few years back to great success.

Re: Ask HN: Is Go simplicity worth it?

#19
post #16
post #15

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. Not because they are…

Do you think that the 20% productivity boost might be solely because you now just have one language to work with? That's what I'm thinking, and that's why I'm personally keen to learn and use Blazor instead of the usual JS frontend. After looking around at the current popular solutions, I've yet to find something that is as ergonomic and productive as the .NET stack in regards to creating a web-based product. You hav…

If Blazor turns out to be good, we may reconsider. Like I said, I’ve worked with C# for a decade and I’m not personally convinced Blazor will even exist as a non-abandoned option in a couple of years. To be fair, I’m more convinced post .Net 8 than before, but it’s still Microsoft and their changing ways. As far as using it goes, we’ve done a few proof of concepts and found it extremely inferior to React, but it’s hardly a fair comparison given its age and lack of real adoption.

The productivity gains come somewhat in spite of using a single language and sharing resources. On one had this will play out nicely over time, but on the other hand we had to transition a lot of developers and tax others to help the process along. I can’t tell you exactly why we’re seeing it. The general consensus is that it’s just “nicer to work with Typescript” but I suspect it’s also because our internal developer tools are just better for Typescript. Not so much because we couldn’t have made them for C# but because we, had, to make them for Typescript.

Re: Ask HN: Is Go simplicity worth it?

#20
post #18

Earlier quoted context omitted.

Switching from C# to TS (especially in combination with Node which is much, much slower and has ecosystem known for vulnerabilities) is the most bizarre (if true at all) choice I have ever seen in the industry.

It’s not like Nuget hasn’t had its share of supplychain attacks. I don’t disagree with you, but we don’t use external packages unless we have too (as in React) and we vet every update. So in that sense there is really no security issues compared to any other language we use. As far as performance goes, all our heavy computation happens in C++ and for everything else the performance difference between the .Net vm and…

I don't know what world you live in but it must be a parallel to the one the rest of the industry lives in.

There have been very few instances of vulnerabilities with nuget. If you compare the numbers to npm, they might as well be a rounding error.

Perhaps your experience was shaped by poorly written ancient codebase specific to your company (or, as I strongly assume, also influenced by select few niche libraries you personally dislike), but it just does not translate to the experience of other developers (of whom you can read numerous testimonies here on HN). I pity the devs who had to suffer moving away from C# to TS and possibly C++, where especially the latter has migraine-inducing build system, and overall is a significant user experience downgrade.

Post reply on HN