Sorry to disagree, but you can not judge a whole programming language in one day (no matter what your skills and experience in other languages are).
Most likely what made you lose interest in Go are simply things you did not grasp yet in one day.
> Most likely what made you lose interest in Go are simply things you did not grasp yet in one day
It doesn’t take a day of use to be frustrated by go’s warts - like having nullable pointers everywhere, the lack of sum types and the awkward error handling. I think it takes more than a day to get used to those problems and work around them. And who knows if the juice is worth the squeeze?
Rust is the same. It takes less than a day to start fighting the borrow checker. Whether the language is worth the discomforts it brings is a question nobody can answer for you.
I think dismissing these criticisms by saying the poster just didn’t understand the language is overly dismissive. These criticisms are real and legitimate.
One day is not enough to even get a superficial understanding of any language.
People tend to always exaggerate how little time it takes to learn a language to a meaningful degree. Sure, the first day I tried Go I was able to accomplish something useful, but it took me a few months to develop a basic understanding of how you use Go in an idiomatic manner. I'd say it took at least a couple of years before I could say I "knew" Go.
And it wasn't exactly love at first sight. My initial impression of Go was that it was a bit too much like C, and, coming from Java, I was a bit confused about how you structure things. That takes time to figure out for any language. What sold me on Go eventually was that for my uses (writing multi-protocol server applications that run on multiple architectures), it resulted in code that was very readable and productivity more than doubled because Go is a lot less fussy to work in than Java. Both in terms of encouraging more minimal designs and having a lot less fragility.
I disagree; you can learn 90% of Go in an afternoon. However, you also do have a point; the power of Go is not apparent in an afternoon, but in longer term and larger projects spanning years or decades, and hundreds or thousands of developers. It was made by and for Google to solve Google's problems, which include millions of LOC written and read by thousands of engineers over the span of decades.
So while at first you think "eww, err != nil everywhere", at least in a decade of reading your own or someone elses' code you'll know exactly what's going on.
How many languages are similar? I feel like a lot of languages in the past decade have had a steady migration in things like error handling, so 10 year old Java code is incomparable to today's Java. Whether that's a good thing (the language has evolved and is now more ergonomic) or a bad thing (I no longer know what's going on here) is the big debate.
> I disagree; you can learn 90% of Go in an afternoon.
Learning a language only starts with knowing the formal spec. Then you have to learn how to express yourself efficiently and in mechanical sympathy with the language. That takes time. Worse yet, a significant portion of developers can't do it without a lot of help.
The lack of true exceptions are annoying, but what kind of environment are you writing in that it's so expressly prohibitive to quit after a day? I've written error matching functions (and now there's errors.Is()) that mostly achieve the same things exceptions do, so I'm struggling to match being so overwhelmed by textual errors that you ignore every other improvement with the language over others.
> what kind of environment are you writing in that it's so expressly prohibitive to quit after a day?
I think it’s admirable to try other languages for a day. I’ve spent less than a day noodling with dozens of languages that seem interesting. I’ve never tried dart, kotlin, elm or Scala. Why not? Is it prohibitively expensive? No. I just haven’t taken the time and the initiative.
More people should spend a day with go, even if they don’t stay around it’s still nice to learn something new!
I can understand why you felt the need to share that, but if you only used it for about a day, aren’t you just reporting your initial impressions? If I used Rust for about a day, I would probably complain about the borrow checker. And if I used Python for about a day, I would have no idea what people are talking about when they complain about package management in Python.
That's true, but the flip side is selecting heavily for public commentary from people who are already invested in—or at least generally open to—the tool in question. But, of course, that means selecting heavily against the people who see immediate, significant problems!
I've run into this problem repeatedly on Goodreads where wholly mediocre works get high ratings because of aggressive selection bias. I generally like fantasy, but I've stumbled on some painful stinkers thanks to this dynamic.
It's doubly reasonable to value first opinions on languages like Go since they intentionally aren't doing anything fundamentally novel. With a handful of exceptions, Go is a remix of ideas from mainstream languages that we've all seen before. It is about as far from a new paradigm for programming as you can get, and that's the point! Hell, that's the main thing people praise about the language: "I could pick Go up immediately, without needing to learn anything new"...
It's immediately clear (to me at least) what benefits you get from the 'pain' of borrow checking. I'm not sure what benefits you get from null pointer exceptions.
It's pretty clear what the payoff is for the investment in using a borrow checker, and it's quite big. Less so for writing if err != nil on every. other. line. That's just an unnecessary nuisance.
The payoff is the same: you do more work up front, but have fewer weird, hard-to-track-down bugs later. Even rust's "?" operator nudges you towards "just pass the error on up", rather than actually thinking about what you want to do if an error happens each time.
