2 ms·
It's really hard, even with Go there are so many more differences than just types. e.g. in Python/Ruby I had a REPL and used it a lot. Go doesn't really have a
by arp242 3y ago
It's really hard, even with Go there are so many more differences than just types.
e.g. in Python/Ruby I had a REPL and used it a lot. Go doesn't really have a good REPL, so I tend to not use it so much. I probably pay some in productivity for that?
On the other hand, I type code like:
name:=fun("foo","bar");if name=="foo"{fmt.Println(name)}
And write and let gofmt sort it out. You can kind of do that in Ruby in theory (not sure if good formatters exist), but Python is more tricky (and I also think the auto-formatters for Python are bad and often make code worse).
The flexibility of things like Active{Record,Model} in Rails are great, and hard to emulate with Go. People have tried, and it just doesn't fit with the language very well.
Go's simple "just compile to a statically linked binary" distribution model probably saves me time, especially for distributing it to other people.
Probably other differences I can't think of right now.
So between all of that, how do you split out the productivity of "types" vs. anything else?
That's also my problem with the research on this, because you just can't, not really. What you need to do is compare e.g. Python with Mypy vs. without. I don't think anyone has done that(?) And even then you run in to the problems with differences in tasks, differences in programmer experience and ability, etc. which matter because for a lot of these studies n tends to be small.