181–190 of 816 posts
I don't quite get this sentiment. In my experience, the career opportunities come from solving worthy problems, as opposed to using a particular language. Plus, I don't believe that an engineer should be identified by a language, as in a Go programmer, or a Java programmer.
Earlier quoted context omitted.
Go tooling was relatively very good a decade ago but other languages have improved a lot since then, significantly because of its influence, and it's now about average. It's still better than python, and C or C++ of course. But about even with typescript, ruby, shit even php and ocaml have nearly caught up with their tooling. Go's is significantly worse than rust god help us and elixir has always made good excellent…
Go tooling is far better than Elixir and I would say above Rust. You should have a look what the go command can do.
Earlier quoted context omitted.
? It doesn't have exceptions, so it doesn't need exception handling. It has an error system / standard that isn't based on exceptions. I only know exceptions from Java myself, and in practice, what it calls exceptions are often... well, not exceptions at all. Files missing, SQL queries returning no errors, division by zero are not exceptional situations, but normal day to day events. And an exception generates a stac…
The whole idea of exception handling with try/catch comes from the fact that problems and error handling can all be standardised into one structure of patterns. Once you are here you can be sure the language(compiler) and tooling(IDE/Editor etc) will generate them for you and provide you with means to handle them. Nothing much has changed in terms of problems and interfaces. So the errors will remain the same. Now wh…
Sometimes it works out. Certainly encoding/json in the Go standard library shows that it's quite acceptable to use where appropriate – the programming tools are there to use, but it turns out that it is rarely appropriate. Which is also why most other languages are also trying their best to move away from the practice as a general rule, if it ever was adopted at all.
Earlier quoted context omitted.
Go tooling was relatively very good a decade ago but other languages have improved a lot since then, significantly because of its influence, and it's now about average. It's still better than python, and C or C++ of course. But about even with typescript, ruby, shit even php and ocaml have nearly caught up with their tooling. Go's is significantly worse than rust god help us and elixir has always made good excellent…
Go was explicitly designed for fast compile times, especially compared to C++, and I haven't heard anything to suggest that's no longer the case. It was also designed as a more modern and mature replacement for C, and I can't think of many application domains where C is still the better choice. Python is at such a different point in the design space I don't think you can really compare the two. Same with PHP, Ruby, J…
But even aside from that we were just talking about tooling at the moment.
Earlier quoted context omitted.
I argue: - The list comprehension is ever slightly more readable. (Small Positive) - It is a bit faster to write the code for the Python variant. (Small Positive) So this would be a small positive when using Python. Furthermore, I believe there is this "small positive" trade-off on nearly every aspect of Python, when compared to Go. It makes me wonder why someone might prefer Go to Python in almost any context. Some…
> The list comprehension is ever slightly more readable. I disagree - it's terse to the point of being hard to parse, particularly when you get smart ones like: [x for x in t if x not in s] > It is a bit faster to write the code for the Python variant. Code should be written to be read. Saving a few keystrokes vs time spent figuring out the `not in in not with` dance gives the the edge to Golang here. It's "high cont…
[word for word in sentence if word not in bannedWords]
I've been coding in Go for over five years. I like Go, but I don't love it. It's never my first choice, although I don't advocate for rewrites just to move away from it. The tooling is a mess. Go modules still feel like a 'first pass' implementation that never got finished. There's no consistency in formatting or imports (even though Go claims there is). Generics are a good step but are still very primitive (no gener…
Not sure what you're comparing to, but Go modules are probably the best dependency management system in any language.
IMO the biggest miss with Go modules is conflating the identity of a dependency with how you get it. This means that renaming a repo not only breaks the module itself (as you self-import other modules in the same source tree using the full path), but all of your dependencies. I've seen repos be renamed from github.com/foo/proj to github.com/bar/proj as part of organisational reshuffles, and then there's a big warning somewhere that says "never make a github.com/foo/proj repo or it'll break GitHub's automatic forwarding for renamed repos, and you'll break every package that depends on us."
There are workarounds like using replace directives. But that makes an even worse situation where you can read a source file and assume a dependency is at github.com/foo/proj but actually it's elsewhere. But ultimately a real fix involves touching every single file that imports your dependency. If Go modules left the way of pulling a dependency in go.mod alone it wouldn't.
You should use a Go modules proxy to solve this, and a custom import path. But by the time most orgs realise they need this it's too late and adopting one would be a huge change. So you end up with a patchwork of import issues.
Earlier quoted context omitted.
That attitude is still there because there is no compelling reason to move away from that. A lot of languages have been diseased by bolting on features for no other reason than different languages have them, and it's overcomplicated the languages and fragmented the codebases. Example, if you ask ten Scala developers to solve a problem, you'll get ten different solutions. That number drops quickly for less feature-ric…
I agree with that and Scala example, but also languages diseased by not evolving and not allowing new widely-accepted features. I wonder what would happen with Go if they never changed their mind and kept it without generics? My point is not about bringing all features other languages have (its just not possible unless its a lisp), but rather creating a new language and not understanding how vital something like gene…
Change their mind? What do you mean? Go always maintained it would get them, once the right design was found – which was echoed by Ian Lance Taylor actually working on them even before the first public release. He alone has, what, 8 different failed proposals?
The problem was always, quite explicitly, that nobody within the Go team had the full expertise necessary to create something that wasn't going to be a nightmare later. As you may recall, once they finally got budget approval to hire an outside domain expert, the necessary progress was finally made.
Being an open source project, you'd think the armchair experts on HN would have stepped in and filled in that gap, but I suppose it is always easier to talk big than to act.
Earlier quoted context omitted.
I think the hype has already peaked for Go. When we switched to Go 8-9 years ago I already felt the hype had died down. We were late to the party. And I saw that as a good thing. To me it suggested Go was going to stick around. And now, almost a decade later, we're still using it. Note that at my company, we're a bunch of grumpy old guys with about 30 years of experience each. If you dangle a new and shiny language i…
Go and Node have some significant overlap, but Go and Rust are barely even competitors. Of course there's a lot of programs that you can use either to write. There's a lot of programs where it hardly even matters which language you pick at all because they're all perfectly acceptable solutions, though, so that really isn't saying much. But if you map languages out by the programs where language choice matters at leas…
Among the people I know Go and Rust seem to be at the top of their list. Almost all people I know who program Rust also know Go. Not as many Go programmers I know program in Rust as well, but some know Rust and even more want to learn it. Which probably isn't too peculiar because Rust is more of a kerfuffle to program in.
I'm not denying your observation. I'm just reporting that from where I am, things look a bit different.
I agree that it mostly doesn't matter that much which language you choose -- as long as it is a language that can meet certain minimum standards. In my view there is only about a handful of languages to actually choose from.
The first is that it must be possible to produce proper binaries. For instance, Python is unacceptable to me since it tends to place a large burden on the user. Next, it has to be a somewhat mainstream language with a sufficiently large community. With that sorted the more technical stuff needs to be evaluated. Like its standard library, how ergonomic the tooling, what quality software/libraries the community produces is etc.
Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…
That's why I love Go so much. You want to write a very clever library using elegant abstraction and generics to have a cool innovative interface to solve your problem? Tough luck, you can't. So instead, you will just have to write a bog standard implementation with for-loops and good old functions which you will have to copy and tweak as needed where you really need something more complicated. It will work perfectly…
Earlier quoted context omitted.
It feels extremely strange to see Go described as a "hype" language. It was somewhat hyped around seven years ago, which is when I started using it almost exclusively. Before that, it had a strong hype peak about fourteen or fifteen years ago, just after it was born. However, it's not a young language any more. At this point I would actually submit the opposite criticism: it is a mature language which is perhaps star…
Count the number of posts with Go in the title, vs any other programming language. It easily beats out everything both here and on lobsters.
Today:
"written|built in Rust" 1113 (1036|77)
"written|built in Go/Golang" 1050 (889|25) / (119|17)
"written|built in Python": 452 (422|30)
"written|built in Javascript/JS" 286 (233|14) / (34|5)
"written|built in Java" 115 (109|6)
"written|built in TypeScript" 97 (89|8)
"written|built in C#" 46 (43|3)
"written|built in Stone" 13 (13|0)
"written|built in Go/Golang" 918 (792|17) / (102|7)
"written|built in Rust" 832 (790|42)
"written|built in Python": 390 (364|26)
"written|built in Javascript/JS" 269 (220|14) / (32|3)
"written|built in Java" 107 (101|6)
"written|built in TypeScript" 66 (61|5)
"written|built in C#" 41 (38|3)
"written|built in Stone" 10 (10|0)