- Type system sucks
- No decent package management system or dependency system
- No generics
- error handling is horrible.
... My fav lang right now is Typescript... You can do frontend stuff, backend stuff (with node). Great tool support, etc.
161–170 of 310 posts
- Type system sucks
- No decent package management system or dependency system
- No generics
- error handling is horrible.
... My fav lang right now is Typescript... You can do frontend stuff, backend stuff (with node). Great tool support, etc.
Being backed by Google contributes a big deal to its (relative) success. I think it is the most limited and ugliest of all the "modern" languages (Rust, D, Zig (never tried Swift)). And at the same time it seems to have the most significant output of all these (docker, kubernetes, gitea...).
I find it more important that it is backed by Rob Pike. He doesn't cancel things when he gets bored with them.
It’s a unique and different language that clearly hit some kind of niche. It’s great when a language has any users and this one has quite a bunch. That’s super cool! Personally I don’t like it. Not low level enough for when I need to go low level, not high level enough when I want to go high level. Also I would have wanted generics right from the start; that should be the norm for typed languages unless the types are…
To me it is a modern C with the lessons from Python learned. It is simple in the ways C is and the gotchas are all things i do naturally based on C. I like having structs and like having to check errors in each call. It forces one to concretize the idea that any reference to anything off of the CPU or the RAM might do anything. You have to have an error strategy for robust code. I don’t think people complain that Lin…
But, personally, C can get really tedious.
After 9 years of ruby, I finally switched to Go as my professional language 3 years ago, after a couple years of side projects with it. My feelings after building for that long : safety and productivity. I initially thought it was because of moving to compiler and type checking, but then I learned C for my personal use (an other thing passing through Go allowed for me), and was surprised to realize my C compiler was…
But the simplicity of the toolchain and breadth of the standard library makes it the most pragmatic major language for backends.
In July 2018, I decided to go all-in on Golang. I like how fast it is, I like that it forces me to pay attention to my types. I wish that error handling felt less like yak shaving, but I understand the rationale. I write task-oriented servers/daemons, and CLI tools mostly, and it's great because it compiles down into a single binary with zero dependencies (which none of my other languages can claim), and it's extremely fast. It compiles easily for a variety of OS/Arch combinations, and as someone who can follow instructions to compile C/C++ code, dependency management is FAR easier than having to track down which "dev" versions of packages I need to install from whatever flavor of Linux or on macOS (via Homebrew). Overall, it's the best of many worlds for producing something that's easy for other people to consume.
These days, I do a lot with AWS, Docker, Security, Terraform, etc. I'm also going back to my web roots a bit on the weekends and looking at building a GraphQL API on top of DGraph, and the tooling for Go is really good. Lots of static analysis and linting tools are available to help me write the best code I can, and teach me when I've done something poorly.
My only big complaint is when I'm parsing JSON of which I don't know the shape. I end up with this nested mess of `map[string]interface{}` types that I have to sift and cast over. Even when I know the shape ahead of time, I still need to do the work to model it as a struct before I can work with it sanely. This is something that JS, PHP, Python, and Ruby all do with far more ease.
I still write in multiple languages frequently, but Go has become my go-to for a lot of things over the past couple of years.
I use go (long term) in places where I need as part of my DR plan the ability to fix stuff without expert access. The toolchain is simple enough that I can maintain it in this scenario alone, and meanwhile the stdlib is complete enough as to be useful for solving a multitude of problems, while offering the ability to produce programs that run on many systems and integrate with them with sufficient efficiency. It's a…
Could you elaborate on why you think it doesn't scale well for teams?
I can usually understand everything happening in Go with a single pass without jumping around too much in the code.
I have no interest in Go because it is so limited, more limited than other languages that I have already moved beyond, such as C#. I am far more interested in cutting edge languages such as Rust (borrow checker) or Idris (dependent types) or even C++ 20 (template madness), since these will allow me to express things that I cannot express in other languages. What does Go bring to the table? Note that my perspective is…
> What does Go bring to the table? A still maintainable code base 5 years along.
* useful, not shiny. No new framework every year, just for the sake of it. An actually readable spec. Changes heavily thought through before being introduced. A programming language isn't a place to move fast and break things, as changes often cannot be undone.
* Readable code. You can figure out what a piece of code does pretty easily. Even if you can't do so at first glance, you know where to look next.
* Simplicity. I personally like having full understanding of things. This applies both to the language itself, as well as to the tools (go test, go mod, go generate etc). This is pretty subjective.
* The formatter. As a screen reader user, aligning things with spaces so that they would form nice little tables is a hard task for me. I'm happy I don't have to do so.
* Compiling programs as single, static binaries, assets included.
Some small things I don't like (also in that order):
* No try macro[1]. IMO try was a better solution than exceptions, and I found the arguments against it not that compelling.
* Overrelliance on struct tags, which shouldn't exist at all IMO. I don't want to couple my business logic, storage and view layers. Options for i.e. JSON should be specifiable at call time.
* No generics, or, even better, zig-like comptimes. They're simpler and more powerful, though they wouldn't probably neatly fit into go2.
Overall, I'd give go about 8.5/10.
[1] https://github.com/golang/proposal/blob/master/design/32437-...