4 ms·

> I've worked on a large Scala program before, and because the team generally agreed not to let things get too crazy, it was very manageable. However, I've seen

by jahaja 6y ago

> I've worked on a large Scala program before, and because the team generally agreed not to let things get too crazy, it was very manageable. However, I've seen other programs in complex languages get out of hand. In my experience this kind of gatekeeping eventually breaks down due to deadlines and similar. There's also a slow rot that always creeps in, and unfortunately seniority doesn't always keep "clever" solutions and general over engineering out. But it looks like we'll have to agree to disagree here. > I've seen many instances where errors are ignored by mistake, e.g.: It's true that there's sometime bugs due to mistyping err != nil sometimes. But I have not noticed that it's too often or that it's somehow is such a large problem that it out-weigh the benefits of the clarity and simple flow brings. > At my employer, we use a monorepo and build with bazel. Hard to compare with an anecdote like that, I just haven't heard much complaints regarding compile times, if anything the opposite, and certainly not that it's a significant problem in a pros/cons comparison.

apta 6y ago
> In my experience this kind of gatekeeping eventually breaks down due to deadlines and similar. I don't disagree. That's why I said the sweet spot is much closer to Java/C#/Kotlin. > But I have not noticed that it's too often That's the problem though. Those silent difficult to detect bugs are what affect reliability and safety. With exceptions, you're going to have to explicitly ignore them, whereas with golang errors, it's much easier to misuse them. Not to mention the fact that golang errors are basically strings, which makes dealing with them very error prone. > Hard to compare with an anecdote like that, I just haven't heard much complaints regarding compile times, if anything the opposite, and certainly not that it's a significant problem in a pros/cons comparison. My guess is that most people don't use golang for large projects, and few who do don't care about the long compile times.

by jahaja 6y ago

apta 6y ago

> In my experience this kind of gatekeeping eventually breaks down due to deadlines and similar. I don't disagree. That's why I said the sweet spot is much closer to Java/C#/Kotlin. > But I have not noticed that it's too often That's the problem though. Those silent difficult to detect bugs are what affect reliability and safety. With exceptions, you're going to have to explicitly ignore them, whereas with golang errors, it's much easier to misuse them. Not to mention the fact that golang errors are basically strings, which makes dealing with them very error prone. > Hard to compare with an anecdote like that, I just haven't heard much complaints regarding compile times, if anything the opposite, and certainly not that it's a significant problem in a pros/cons comparison. My guess is that most people don't use golang for large projects, and few who do don't care about the long compile times.