I think it's boring, overly simplistic, and ignores the last couple of decades of PL research.
Boring is actually what a lot of people look for.
Yep. I use Go precisely because it's boring.
Ask HN: Go programming language is over ten years old. What do you think of it?
131–140 of 310 posts
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#132Great tool, two big negatives. First, checking result values is dumb. It adds 50% more code. Add exception handling. Second, the way imports work is obviously due to some internal google kitschy-ness. Remote import paths are so dumb. People set up entire domains and CDN's just to host some code. The import path has to have a specific format, you can't have three levels. github.com/me/sub1/module won't work, so everyo…
A super important principal for large code base is locality. I should be able to look at a function and understand everything about its possible code paths. Exceptions make this impossible (most of my experience with exceptions coming from C++ and Python). People that think like me would forbid exceptions every where.
return values don't say anything about possible code paths. If you are saying the function should document what could go wrong when it is called, Java solved this 24 years ago when each method lists the exceptions they throw. If you need to know what the back trace/call stack was when the error happened, well that is stored in the exception.
People that use return codes simply don't check every possible value, otherwise they would see that it increases program length by at least 50% and makes the code unreadable. A common pattern in Go is this
if (err == MY_ERROR) { log my error; notify user; return MY_ENCAPSULATING_ERROR_CODE }
for high quality code this has to occur for every function call in the entire codebase. So you'll get huge functions which are mostly 'if' statements checking error codes, logging the results, and returning another error code that has to be checked again one step up the call stack.
moving from c++ to java 20 years ago it was clear that the c/c++ community didn't really know what they were doing in this regard. A lot of c/c++ dogma boilerplate code was holding it back. Too bad some of it made it into golang.
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#133Insert standard whinge about the lack of generics and the presence of garbage collection. Generally, a type system at least as strong as Hindley-Milner is table stakes for a new language in the 21st century; its omission from Go is a glaring fault that cannot be ignored. And the RAII pattern beats GC in 90% of cases; for the rest, reference counting may be employed. GC is obsolete, and better technologies to supersede it have been around since the 90s.
That said, Go is fun to work in, and is great for constructing microservices that are truly "micro" in terms of small footprint of code and dependencies. Today, enterprise development shops that embrace the microservice pattern hew stickler-like to the "do one thing" bit of Unix philosophy, but slack off on the "do it well" bit, bringing in dozens of dependencies to serve, say, a list of employee names and IDs out of a table. Go's opinionated minimalism helps to mitigate this trend, but Go has also proven itself up to large-ish development tasks like Kubernetes as well.
So that's Go -- capable, but not ideal. A worthy choice if you want to get something out there without fighting the borrow checker -- though you may wish to consider that time spent satisfying rustc now is more than paid for by maintenance time saved later.
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#134I find myself reaching for it over other languages when I want to build small servers with a bit of in-memory state or a bit of heavy processing. For little search-engines, Go is perfect. While writing servers in Flask + Python is much more convenient, I still prefer Go because I don't run into the limits that Python has. The development process is fluid enough that I wish the language was suited to more usecases. Wh…
OCaml is good for handling abstract syntax trees (strong typing, pattern matching) and its mix of imperative and functional programming don't require using borrow-checker nor monads. You can also consider Reason, if you prefer a more C-like syntax.
Also consider F#! In some ways it is more limited (no first class modules) but in others it is arguably better (operator overload, C# ecosystem, a slick take on do-notation).
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#135Wow! 10 years already. I'm the founder of HashiCorp and I'd love to share my thoughts. Credentials: I started using Go around 9 years ago and since then I've built a company of over 1,000 employees with ~250 engineers that write Go full time. We maintain dozens of open source projects and libraries (Terraform, Vault, etc. etc.) all written in Go. We've shipped commercial products that are used by a significant percen…
Knock wood man. Just shared this with my terraform but also Java team. Also thanks for terraform. It’s no golang to use, but I can read the nice go code and understand what json-ish declarative assembly-language-ish stuff to type to get the weird Jacky deployment thing I want in AWS. And then everyone can repeat it (with or without modification) as needed.
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#136I haven't enough experience to talk about any things I don't like but my limited experience with it on a couple of small personal projects has been positive. All of this is subjective of course but these are my impressions:
- It's fast - given I work with PHP for a living it's no fair comparison really, transposing a processor-intensive algorithm into Go is like lifting a veil. In one instance I think Go ended up being ~100 times faster, and that was without splitting computation across multiple cores.
- Getting async multi-core concurrency feels smooth with golang, it's not that much of a stretch to transfer concepts from my experiences with async JavaScript / nodejs applications, only that it feels more natural dealing with flow control, race conditions, and shared resources in Go - JS tools have improved in recent years but being single threaded they only really approximate the experience of concurrency in Go and that can sometimes bite hard.
- It's fairly intuitive to pick up and use. I used to be a big fan of C#'s syntax, and prior to working with PHP I learned development with C-style languages (including C/C++) so anything with a similar syntax feels natural to me. Golang feels to me like JavaScript got in bed with C# and made a baby.
tl;dr: I'd definitely welcome the opportunity for some professional work using Go, and will certainly consider implementing some of my future projects with it to gain experience.
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#137I have used Go for a good 5 years when performance and maintainability are the necessary trade offs. It has the unique feature that all the code sorta looks the same style, across users. So the readability remains high during maintenance. I don’t think it is the best at building rest or graphql APIs, or for highly complex data centric systems. For that I would reach for a language with better generic programming support and many libraries available - like TypeScript.
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#138Go is one of my favorite languages. I love that I can build things quickly with just the standard library (my personal website uses no external packages).
There are other "sexier" languages that I sometimes enjoy even more (Elixir, Rust), but Go is rock solid, easy to use, and has never let me down in production.
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#139Earlier quoted context omitted.
A super important principal for large code base is locality. I should be able to look at a function and understand everything about its possible code paths. Exceptions make this impossible (most of my experience with exceptions coming from C++ and Python). People that think like me would forbid exceptions every where.
return values don't say anything about possible code paths. If you are saying the function should document what could go wrong when it is called, Java solved this 24 years ago when each method lists the exceptions they throw. If you need to know what the back trace/call stack was when the error happened, well that is stored in the exception. People that use return codes simply don't check every possible value, otherw…
Explain the Java services that only ever return an HTTP 200 and either return the proper XML response or a java stack trace formatted into HTML.
And my point is those if statement are wanted by the people that write high reliability software in C. There just isn’t a substitute for thinking about errors. Even well done exception throwing systems will specific “this layer can throw, this middle layer won’t worry about errors, then this higher layer will restart or retry or whatever”. And in go within one layer you can usually have all those steps in one function and for error cases with the same handling just check for if err != nil. When I read code without explicit error handling I worry. I guess this debate is probably an aesthetic debate, and different type of code have different urgency. The extra check for error return is like the check for parameter correctness at the top of a function, which is common in robust C code. You can’t trust the callers too much and better to log an error than terminate the process.
Re: Ask HN: Go programming language is over ten years old. What do you think of it?
#140I love it, and consider it surprisingly and even “unreasonably” effective.
My favorite feature is its simplicity. It imposes very little cognitive load, allowing you to spend more time thinking about the problem you are trying to solve and less time on language gymnastics. I am way “over” being impressed with that kind of cleverness. I am much more impressed with what a program does than with cleverness at the code level.
Go mostly picks the right features and avoids those that just add complexity, and it mostly gets that right.
It doesn’t get everything right. I am disappointed with channels and I do think it needs generics, though I hope the latter do not add much complexity and are not overused.