Unlike say, Rust. I do love Rust though.
Now with generics there's even less to complain about.
With C at least it's clear to me that it's literally (very literally) a 50 years old language, and I've gotten used to it after decades. It's far from ideal, but at least there's some deep familiarity, and that coupled with the fact that it's everywhere makes me feel more tolerant of it.
But learning a new language which is, in some ways, stuck in the same past as that established 50 years old language is not very pleasing.
When a language has some property that surprises you, consider whether it might have been designed that way on purpose, not simply because the creators were ignorant/lazy/negligent/drunk/lost a bet/etc.
This is not a well-intended comment, but then why didn't they add generics at the start? It's not like it was a surprise to anyone even remotely familiar with PLs that they will have to retrofit it sooner or later. Also, function-scoped defers instead of surrounding braces-based one? Come on...
There is zero point in postponing a feature so that you can build a community, which you will burn down later. It’s not a startup that has to be ready in X months or it will fail.
And while I can totally understand how that makes sense in the intended setting, I don't consider that pleasing at all. "Pleasing" for me implies that I like a thing because I like the thing itself, not because external constraints impose (perceived) limitations on other choices. Especially in this context, where we were talking about learning and using a programming language by choice, instead of assembling a team of programmers from an already common pool.
You are a new developer too. Everyone is. When it’s easy to learn something, it’s easy to relearn it, and it’s easy to learn things around it (because you don’t devote as much brain to the language).
All languages should target new, dumb devs, because all devs (including Rob pike) are new and dumb.
And I absolutely reject the notion that an easy to learn programming language is better. Especially so because Go was made “easier to learn” in large parts by its similarity to C, so it’s really easier for people already and only familiar with C, and that was explicitly stated by the creators.
It is simple enough to learn quickly so the investment isn't that demanding. I'd like to learn Rust but the learning curve is much steeper and it seemed to be subject to changes. I'm not shitting on it, just lazy with too many distractions to hunker down and do a real investment of time into it. Someday.
you just said you wanted to write SSH apps. is that not enough of a spark?
The problem is that sometimes the zero value is valid, but not special in any way and doesn't make sense as the default. Go has arbitrarily decided that one particular value is special without your blessing or the ability to override it. This leads to bugs in which the zero value shows up in places where you don't expect it, simply because there is some code which doesn't explicitly set it. That's a very easy mistake to make, which makes writing Go an error prone activity.
I shudder to think that there's probably some Go program that deals with money, and a user's balance might be cleared to zero simply because some operation forgot to explicitly set it in some struct.
In order to implement "optional" fields in Go where you want to distinguish between zero (a valid value) and none (a missing value), the common solution is to either put the integer behind a pointer (which can be null) or use some "sentinel" value like -1 to indicate that the value is missing (as long as that sentinel value isn't actually valid in the domain of discourse). These are terrible hacks, but exactly what you'd expect from programmers who spent the majority of their careers writing C.
This design also leads to another kind of issue: sometimes you don't want people to be able to construct values of a particular type without going through a constructor which ensures the relevant invariants hold. This concept ("smart constructors") is widely used in other programming languages, but it's impossible in Go because Go allows anyone to construct an inhabitant of any type simply by declaring a variable of that type.
A simple example of that kind of issue is pointers: in (safe) Rust, references are guaranteed to be non-null, and you use sum types to implement optionality. This is great because you can always dereference a reference and not worry about handling the null case. In Go, all pointer types have that nasty zero value (null), and there's nothing you can do about it. The billion dollar mistake.
I like the fact that Go encourages simplicity, and for the most part the language is fine. But I'm convinced that having every type be pointed rather than supporting proper sum types is actually more complex in terms of the implications it has on writing and reasoning about code. They have mistaken minimality for simplicity.
As an embedded firmware guy, I'll try not to be offended by that line :) I agree with you, though. C is a really good language when you consider its original purpose and the time period in which it was created. Ignoring 50 years of progress in type theory/category theory in the name of "simplicity" is inexcusable.
Writing C is an understatement given that Go and C were created by the same person (with help, of course).
I use both weekly, for different things. There are numerous people who don't use Go at all that are in Go specific forums. They read Go specific threads here on HN just to make their Rust points. I poke fun at them with my statement. You just gave me the hook.
:) smiley face for you