[ecshafer]

> It’s faster than Node or Python, with a better type system than either. It’s got a much easier learning curve than Rust. It has a good stdlib and tooling. Simple syntax with usually only one way to do things. Error handling has its problems but I still prefer it over Node, where a catch clause might receive just about anything as an “error”.

I feel like I could write this same paragraph about Java or C#.

[acedTrex]

Java and C# are both languages with A LOT more features and things to learn. Go someone can pick 80% of the language up in a single day.

[bob1029]

Just because you can learn about something doesn't mean you need to. C# now offers top-level programs that are indistinguishable from python scripts at a quick glance. No namespaces, classes or main methods are required. Just the code you want to execute and one simple file.

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

[slipperydippery]

The benefit of the language being small and "normal" idioms mostly followed and the std library being good-enough that people rarely import another dep for something it can handle is that it's by far the easiest language in which to read my dependencies that I've ever used.

If I hit a point where I need to do that in pretty much any other language, I'll cast about for some way to avoid doing it for a while (to include finding a different dependency to replace that one) because it's almost always gonna be a time-suck and may end up yielding nothing useful at all without totally unreasonable amounts of time spent on it, so I may burn time trying and then just have to abandon the effort.

In go, I unhesitatingly hop right in and find what I need fast, just about every time.

It's the polar opposite of something like Javascript (or Typescript—it doesn't avoid this problem) where you can have three libraries and all three both read like a totally different language from the one you're writing, and also like totally different languages from one another. Ugh. This one was initially written during the "everything should be a HOF" trend and ties itself in knots to avoid ever treating the objects it's implicitly instantiating all over the place as objects... this one uses "class" liberally... this one extensively leans on the particular features of prototypal inheritance, OMG, kill me now... this one imports Lodash, sigh, here we go... et cetera.

[acedTrex]

I mean thats fine, but thats hardly applicable to the ease of throwing a new dev into a very large c# codebase and how quickly they can ramp up on the language.

[novok]

Any large codebase has a large ramp up time by virtue of being large. And the large codebase can have devex automation to get past the initial ceremony setup of larger languages like Java. It feels like the wrong thing to optimize for. As a better alternative to small services that would've been made in python or node, yes for sure, then the quick setup and simplicity of go makes sense. Which is why the biggest audience of people who use go and used another language previously is python engineers and people who want to make small network services.

At the larger codebase go company I worked at, the general conclusion was: Go is a worse Java. The company should've just used Java in the end.

[ramenmeal]

Java and C# have way to much baggage to compare them to Go. They nearly look like different languages depending on the version you're using.

[gadflyinyoureye]

And they will trip over the remains 20% percent for the rest of their days.

[gf000]

Java is a very tiny language. I don't buy that it would take significantly longer to learn.

[acedTrex]

Now throw in spring on top of it, which is the standard in large java web codebases. Its very very daunting

[gf000]

Well, you ain't adding together two numbers in Go either.

Give me an apples to oranges comparison. With routing, cookies, authN/authz, SQL injection, cross site scripting protection, etc.

[ricardobeat]

"Simple syntax with usually only one way to do things" is pretty much the exact opposite of Java.

[SkepticalWhale]

I mostly agree with you except the simple syntax with one way of doing things. If my memory serves me, Java supports at least 2 different paradigms for concurrency, for example, maybe more. I don’t know about C#. Correct me if wrong.

[mattmanser]

But that's only because they're older and were around before modern concurrent programming was invented.

In C#, for example, there are multiple ways, but you should generally be using the modern approach of async/Task, which is trivial to learn and used exclusively in examples for years.

[gf000]

There is no one paradigm for concurrency, no method is strictly better than the other. Channels are not the only primitive used in go either, so it's a bit moot point.

What's important is how good primitives you have access to. Java has platform and virtual threads now (the latter simplifying a lot of cases where reactive stuff was prevalent before) with proper concurrent data structures.

[vips7L]

What are Javas 2 different paradigms?