3 ms·

So, you enjoy spending months ramping up new developers in your language of choice? That's not a task that falls to managers, it falls to the other developers

by NateDad 12y ago

So, you enjoy spending months ramping up new developers in your language of choice? That's not a task that falls to managers, it falls to the other developers on the team. There's still ramp up on the codebase, but at least I don't have to ramp people up on the basics of the language itself. That's a huge win. If you think team productivity only matters to managers, that's kind of sad.

pjmlp 12y ago
No, because in our projects only developers skilled in the required technologies get hired.
- NateDad 12y ago
  Then you're narrowing your hiring pool. Hiring is hard. Hiring really good people is really hard. Removing the requirement of "has 10 years of $LANGUAGE" is pretty awesome. It means we can hire someone because they're GOOD, not because their last job chose the same language we're using.
lmm 12y ago
I'm willing to spend time ramping up if it means greater productivity in the long run. I can see that go's a kind of lowest-common-denominator language - you don't spend any time learning its fancy error-handling facilities because it doesn't have any - but I don't see that as a win.
- NateDad 12y ago
  You should use Go for a while. It's very productive. Lean and mean and gets out of the way of the developer. People call it a lowest common demoninator language as a way to dismiss it, but it's actually incredibly well thought out by a lot of really smart people, several of whom have been writing code for longer than most people on HN have been alive. The error handling works the way it does, because errors are not special. They're just values, and you can use the whole programming language to handle them just as you would any other value that gets returned.
  - lmm 12y ago
    > The error handling works the way it does, because errors are not special. They're just values, and you can use the whole programming language to handle them just as you would any other value that gets returned. Sure, I actually like that. But I need a type system that's sophisticated enough to let me handle them nicely; there are times when I need eithers or validations or the like. More than that, there are enough cases where I need one or the other that I need to write code that can handle any kind of context generically. It's funny because despite the reputation Scala (my language of choice) is actually very simple at the language level. But what you can do with those simple pieces can become very complex, and the range of patterns that are possible takes a while to learn. It's not learning the language that takes ramp-up time, it's the library code. I predict that if Go is successful it will acquire its own scalaz-equivalent; it pretty much has to, because there are patterns in the way you do things like error handling that it would be stupid to just repeat in every project. I mean, you know what else was a small simple language? Java, which is why it acquired the massive frameworks it's best known for. (That's not the worst possibility though; that would at least make Go a useful language. But with a type system noticeably worse than Java's, I'm not sure it will be possible to build these things in Go, and a type system isn't something you can bolt-on in a library.)

by NateDad 12y ago

pjmlp 12y ago

No, because in our projects only developers skilled in the required technologies get hired.

NateDad 12y ago
Then you're narrowing your hiring pool. Hiring is hard. Hiring really good people is really hard. Removing the requirement of "has 10 years of $LANGUAGE" is pretty awesome. It means we can hire someone because they're GOOD, not because their last job chose the same language we're using.

lmm 12y ago

I'm willing to spend time ramping up if it means greater productivity in the long run. I can see that go's a kind of lowest-common-denominator language - you don't spend any time learning its fancy error-handling facilities because it doesn't have any - but I don't see that as a win.

NateDad 12y ago
You should use Go for a while. It's very productive. Lean and mean and gets out of the way of the developer. People call it a lowest common demoninator language as a way to dismiss it, but it's actually incredibly well thought out by a lot of really smart people, several of whom have been writing code for longer than most people on HN have been alive. The error handling works the way it does, because errors are not special. They're just values, and you can use the whole programming language to handle them just as you would any other value that gets returned.
- lmm 12y ago
  > The error handling works the way it does, because errors are not special. They're just values, and you can use the whole programming language to handle them just as you would any other value that gets returned. Sure, I actually like that. But I need a type system that's sophisticated enough to let me handle them nicely; there are times when I need eithers or validations or the like. More than that, there are enough cases where I need one or the other that I need to write code that can handle any kind of context generically. It's funny because despite the reputation Scala (my language of choice) is actually very simple at the language level. But what you can do with those simple pieces can become very complex, and the range of patterns that are possible takes a while to learn. It's not learning the language that takes ramp-up time, it's the library code. I predict that if Go is successful it will acquire its own scalaz-equivalent; it pretty much has to, because there are patterns in the way you do things like error handling that it would be stupid to just repeat in every project. I mean, you know what else was a small simple language? Java, which is why it acquired the massive frameworks it's best known for. (That's not the worst possibility though; that would at least make Go a useful language. But with a type system noticeably worse than Java's, I'm not sure it will be possible to build these things in Go, and a type system isn't something you can bolt-on in a library.)