6 ms·
Go has its fair share of flaws but I still think it hits a sweet spot that no other server side language provides. It’s faster than Node or Python, with a bett
by SkepticalWhale 1y ago
Go has its fair share of flaws but I still think it hits a sweet spot that no other server side language provides.
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”.
Am I missing a language that does this too or more? I’m not a Go fanatic at all, mostly written Node for backends in my career, but I’ve been exploring Go lately.
- rsyring 1y agoMaybe Nim. But it's not really caught on and the ecosystem is therefore relatively immature.
- ecshafer 1y ago> 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 1y agoJava 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.
- gadflyinyoureye 1y agoAnd they will trip over the remains 20% percent for the rest of their days.
- bob1029 1y agoJust 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/program-structure/top-level-statements https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
- acedTrex 1y agoI 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 1y agoAny 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.
- slipperydippery 1y agoThe 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.
- gf000 1y agoJava is a very tiny language. I don't buy that it would take significantly longer to learn.
- acedTrex 1y agoNow throw in spring on top of it, which is the standard in large java web codebases. Its very very daunting
- gf000 1y agoWell, 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.
- ramenmeal 1y agoJava 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.
- SkepticalWhale 1y agoI 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 1y agoBut 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.
- vips7L 1y agoWhat are Javas 2 different paradigms?
- gf000 1y agoThere 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.
- ricardobeat 1y ago"Simple syntax with usually only one way to do things" is pretty much the exact opposite of Java.
- bccdee 1y agoYeah the big problem is that most languages have their fair share of rough edges. Go is performant and portable* with a good runtime and a good ecosystem. But it also has nil pointers, zero values, no destructors, and no macros. (And before anyone says macros are bad, codegen is worse, and Go has to use a lot of codegen to get around the lack of macros). There are languages with fewer warts, but they're usually more complicated (e.g. Rust), because most of Go's problems are caused by its creators' fixation with simplicity at all costs.
- kragen 1y agoI thought it was obvious that codegen was better than macros—at least, textual macros. You can't tell me Ken Thompson omitted macros from the Golang design because he didn't have experience using languages with macro systems! Even AST-based macro systems have tricky problems like nontermination and variable capture. It can be tough to debug why your compiler is stuck in an infinite macro expansion loop. Macro systems that solve these problems, like the R⁵RS syntax-rules system, have other drawbacks like very complex implementations and limited expressive power. And often there's no easy way to look at the code after it's been through the macro processor, which makes bugs in the generated code introduced by buggy macros hard to track down. By contrast, if your code generator hangs in an infinite loop, you can debug it the same way you normally debug your programs; it doesn't suffer from tricky bugs due to variable capture; and it's easy to look at its output.
- bccdee 1y agoI would say more or less equivalent to textual macros. Unfortunately, as far as I can tell, the idiomatic way to write Go codegen (having skimmed some codegen repos and written some codegen tooling myself) is with the text/template package. Even battle-tested tools like protoc-gen-go are effectively built with printf statements rather than any sort of AST builder. AST macros are complicated, yeah, and I agree that any half-decent macro system needs a convenient way to dump generated code and so forth. I'm not saying any macro system is better than codegen. But a decent macro system will give you hygenic tools to modify an AST, whereas codegen really forces you to hack something together. I'll grant that there's some worse-is-better charm to codegen, but I don't think that saves it from being ultimately worse.
- genshii 1y agoMaybe this is a bit pedantic, but it bothers me when people refer to "Node" as a programming language. It's not a language, it's a JavaScript runtime. Which to that you might say "well when people say Node they just mean JavaScript". But that's also probably not accurate, because a good chunk of modern Node-executed projects are written in TypeScript, not JavaScript. So saying "Node" doesn't actually say which programming language you mean. (Also, there are so many non-Node ways to execute JavaScript/TypeScript nowadays) Anyway, assuming you're talking about TypeScript, I'm surprised to hear that you prefer Go's type system to TypeScript's. There are definitely cases where you can get carried away with TypeScript types, but due to that expressiveness I find it much more productive than Go's type system (and I'd make the same argument for Rust vs. Go).
- SkepticalWhale 1y agoMy intent was just to emphasize that I’m comparing Go against writing JavaScript for the Node runtime and not in the browser, that is all, but you are correct. Regarding Typescript, I actually am a big fan of it, and I almost never write vanilla JS anymore. I feel my team uses it well and work out the kinks with code review. My primary complaint, though, is that I cannot trust any other team to do the same, and TS supports escape hatches to bypass or lie about typing. I work on a project with a codebase shared by several other teams. Just this week I have been frustrated numerous times by explicit type assertions of variables to something they are not (`foo as Bar`). In those cases it’s worse than vanilla JS because it misleads.
- VeejayRampay 1y agoit is pedantic, everyone knows what "node" means in this context
- genshii 1y agoApparently not, because I first assumed that he was talking about TypeScript considering that JavaScript doesn't have much of type system to compare to.
- andrewmcwatters 1y ago
- andrewmcwatters 1y agoIt definitely hits a sweet spot. There is basically no other faster, widely used programming language in production used predominantly for web services than Go. You can argue Rust, but I just don't see it in job listings. And virtually no one is writing web services in C or C++ directly.
- viccis 1y ago>with a better type system than either Given Python's substantial improvements recently, I would put it far ahead of the structural typing done in Go, personally.
- diarrhea 1y agoYes, Python is massively ahead there. The largest wart is that types can be out of sync with actual implementation, with things blowing up at runtime -- but so can Go with `any` and reflection. Python, for a number of years at this point, has had structural (!) pattern matching with unpacking, type-checking baked in, with exhaustiveness checking (depending on the type checker you use). And all that works at "type-check time". It can also facilitate type-state programming through class methods. Libraries like Pydantic are fantastic in their combination of ergonomics and type safety. The prime missing piece is sum types, which need language-level support to work well. Go is simplistic in comparison.
- kragen 1y agoAs long as none of the code you wrote ten years ago is worth anything, and you don't expect to want to use the code you're writing today ten years from now. Python is useful for prototyping.
- Too 1y agoThis. Both Typescript and Python type systems are way far ahead, with structural typing, exhaustive checks and much more.
- slipperydippery 1y agoPython with a library like Pydantic isn't bad—I wouldn't rate base Python as being near Go's level, at all, though you can get it up to something non-painful with libraries. Go (and lots of other languages...) wreck it on dependency management and deployment, though. :-/ As the saying goes, "it was easier to invent Docker than fix Python's tooling".
- viccis 1y ago
- mervz 1y agoI find Go's type system to be extremely lackluster.
- SkepticalWhale 1y agoOk can you elaborate?
- deleted 1y ago[deleted]
- tomjen3 1y agoI have a deep hatred of Go for all the things it doesn't have, including a usable type system (if I cannot write SomeClass<T where T extends HorsePlay> or similiar, the type system is not usable for me). For NodeJS development, you would typically write it in Typescript - which has a very good type system. Personally I have also written serverside C# code, which is a very nice experience these days. C# is a big language these days though.
- bccdee 1y agoFYI, newer versions of Go do support the following type HorsePlay interface { Neigh() } type SomeClass[T HorsePlay] struct { players []T } func (sc SomeClass[T]) NeighAll() { for _, p := range sc.players { p.Neigh() } } type Horse struct{} func (h Horse) Neigh() { fmt.Println("neigh!") } func main() { sc := SomeClass[Horse]{players: []Horse{{}, {}, {}}} sc.NeighAll() }
- ghthor 1y agoThe real cream is that there barely any maintenance. The code I wrote 15years ago still works That’s the selling point for me. If I’m coming to a legacy code as that no one working wrote, I pray it is go because then it just keeps working through upgrading the compiler and generally the libraries used.
- chamomeal 1y agoI’ve only used Go for a little toy project but I’m surprised to hear the opinion that it has a better type system than Node, a runtime for which the defacto type system is typescript! Agree on node/TS error handling. It’s super whack