5 ms·

> Sure but do those same studies look at code with the same character count (ie longer but fewer lines) or are they just subtracting characters via subtracting

by apta 8y ago

> Sure but do those same studies look at code with the same character count (ie longer but fewer lines) or are they just subtracting characters via subtracting lines. For most practical languages that are used day to day, this doesn't really matter. How often do you see Java or C# programs that have very long FP style lines? As a matter of fact, I keep running into cases where golang code is both longer in terms of line length, and line count compared to code written in Java with map/filter/takeWhile/etc. You can have a multi line approach and use if expressions, and get both readability (which is kind of subjective), and not needing to assign to the same variable in each branch. golang just chose to go with the most verbose and most error prone option. var a = if foo() { bar() } else if baz() { qux() } else { corge() }

deleted 8y ago
[deleted]
laumars 8y ago
I totally agree Go has its warts but you talk as if this is a unique property to Go. If we are going to handpick our examples then I could easily cite instances where Go requires less boilerplate code than Java and C#. So ultimately it does balance out. I agree it would be nice if Go was more expressive but I dont agree with your points about it being more error prone nor less readable. In your example there isnt any errors that you could do in Go that you couldn’t accidentally do in the subjectively better code aside forgetting to assign to the variable, which the Go compiler would catch that anyway. Plus all the examples of readability in this discussion are really just a few small percentages either way. If a developer can’t competently read either example then they shouldn’t be allowed near your code anyway. Having written a lot of Go and Java (admittedly very little C# though), I’ve definitely found myself far more productive in Go. Not just writing code, but compiling, testing and deploying said code too. And at the end of the day productivity matters more to me than creating works of art in my source code. Which is why I don’t mind some of Go’s uglier syntax. I’m sure other people might argue that they’re more productive in $LANGUAGE and I’m sure they’re also right too. The funny thing about productivity is it’s a case by case thing. Sometimes Go makes sense, sometimes it’s Java or C# or Rust or even C. Sometimes it’s a JIT language like JavaScript or Python. And some times I just need to hack something together quickly in Perl. This is why I think it pays to be agnostic rather than spending weeks of your life coming up with “reasons” to dislike programming languages.
- apta 8y ago
  > So ultimately it does balance out. That's not what I'm seeing from code bases of different projects I've been working on at my current employer. It's almost fully the case that any code base for a medium sized project would end up being shorter in Java or C#, and we didn't even discuss things like annotations for validation and similar things. > In your example there isnt any errors that you could do in Go that you couldn’t accidentally do in the subjectively better code It wouldn't catch this var a int if foo() { a = bar() } else { baz() } Or even assigning it to a different variable `b`. > in this discussion are really just a few small percentages either way They add up quite quickly in any sizeable project. It's not just one offs here and there, you end up with functions littered in the code base that distract from quickly getting to understand the code when debugging a bug or an outage. I found compile times for golang (building the entire project + unit tests) to be about the same as Java, meaning all this hype about fast compile times in golang to be just that. Not to mention that exceptions are far superior when debugging issues. I agree, depending on the situation some languages would do better than others depending on the task. The thing is, golang seems to be used just because it has Google as a name behind it, not for its technical merit (and the vast majority of critical infrastructure at Google almost surely is still C++ and Java). This shows up time and again, as people are not able to defend the technical choices behind it in any proper way, more like "the golang authors are smart and they decided to have it that way", which has already been shown several times that the golang authors are quite bad at defending their decisions, and they're not experienced at language design to begin with (C is a bad language by modern standards). Golang would probably be fine for some small tools here and there (even for that, Rust or AOT Java would be a consideration), for anything larger, a static JVM or .NET language is strictly superior.
  - laumars 8y ago
    > It wouldn't catch this True but you could forget to do that in your alternative example as well (albeit you'd get no instances of a assigned rather than sporadic instances - however the point of testing frameworks is they should catch that kind of human error regardless of the language or it's syntax) > Or even assigning it to a different variable `b`. Actually the compiler would catch that too. > They add up quite quickly in any sizeable project. It's not just one offs here and there, you end up with functions littered in the code base that distract from quickly getting to understand the code when debugging a bug or an outage. I guess it depends on what you're used to but I've always preferred code that abstracted away longer or more complex functions into smaller ones. I guess that's the FP habits in me transferring over to imperative languages. In any case, I've never had any issue debugging such code when under pressure during an outage. > The thing is, golang seems to be used just because it has Google as a name behind it, That's complete and utter BS. In fact I had already cited reasons I like Go. so please don't assume that because you don't like something then it's automatically a bad language that other people can't like either. > This shows up time and again, as people are not able to defend the technical choices behind it in any proper way, People have and they do though. The issue is that there is a hell of a lot of language elitism in the the different programming language cults so it doesn't matter what reasons we might give - you've already decided you don't like feature x and thus our reasons are wrong by default. You demonstrated just this kind of mentality when you argued that people use Go just because of Google in a reply to a post that lists why someone likes Go. > which has already been shown several times that the golang authors are quite bad at defending their decisions, and they're not experienced at language design to begin with The arrogance in that comment is overwhelming. I look forward to the day you create something worthy of recognition and the inevitable backlash on HN from kids who assume they're smarter then you are in every way. This isn't me putting Russ Cox et al on a pedestal - this is me pointing out that talk is cheap and most of the critics on HN are just average engineers at best. > Golang would probably be fine for some small tools here and there (even for that, Rust or AOT Java would be a consideration), for anything larger, a static JVM or .NET language is strictly superior. Clearly not everyone agrees with you there because a lot of successful important projects are now based on Go. You need to learn that features you prioritise are not going to be the same as features others might prioritise - and that having different priorities doesn't make one party wrong and another right.

by apta 8y ago

deleted 8y ago

[deleted]

laumars 8y ago

I totally agree Go has its warts but you talk as if this is a unique property to Go. If we are going to handpick our examples then I could easily cite instances where Go requires less boilerplate code than Java and C#. So ultimately it does balance out. I agree it would be nice if Go was more expressive but I dont agree with your points about it being more error prone nor less readable. In your example there isnt any errors that you could do in Go that you couldn’t accidentally do in the subjectively better code aside forgetting to assign to the variable, which the Go compiler would catch that anyway. Plus all the examples of readability in this discussion are really just a few small percentages either way. If a developer can’t competently read either example then they shouldn’t be allowed near your code anyway. Having written a lot of Go and Java (admittedly very little C# though), I’ve definitely found myself far more productive in Go. Not just writing code, but compiling, testing and deploying said code too. And at the end of the day productivity matters more to me than creating works of art in my source code. Which is why I don’t mind some of Go’s uglier syntax. I’m sure other people might argue that they’re more productive in $LANGUAGE and I’m sure they’re also right too. The funny thing about productivity is it’s a case by case thing. Sometimes Go makes sense, sometimes it’s Java or C# or Rust or even C. Sometimes it’s a JIT language like JavaScript or Python. And some times I just need to hack something together quickly in Perl. This is why I think it pays to be agnostic rather than spending weeks of your life coming up with “reasons” to dislike programming languages.

apta 8y ago
> So ultimately it does balance out. That's not what I'm seeing from code bases of different projects I've been working on at my current employer. It's almost fully the case that any code base for a medium sized project would end up being shorter in Java or C#, and we didn't even discuss things like annotations for validation and similar things. > In your example there isnt any errors that you could do in Go that you couldn’t accidentally do in the subjectively better code It wouldn't catch this var a int if foo() { a = bar() } else { baz() } Or even assigning it to a different variable `b`. > in this discussion are really just a few small percentages either way They add up quite quickly in any sizeable project. It's not just one offs here and there, you end up with functions littered in the code base that distract from quickly getting to understand the code when debugging a bug or an outage. I found compile times for golang (building the entire project + unit tests) to be about the same as Java, meaning all this hype about fast compile times in golang to be just that. Not to mention that exceptions are far superior when debugging issues. I agree, depending on the situation some languages would do better than others depending on the task. The thing is, golang seems to be used just because it has Google as a name behind it, not for its technical merit (and the vast majority of critical infrastructure at Google almost surely is still C++ and Java). This shows up time and again, as people are not able to defend the technical choices behind it in any proper way, more like "the golang authors are smart and they decided to have it that way", which has already been shown several times that the golang authors are quite bad at defending their decisions, and they're not experienced at language design to begin with (C is a bad language by modern standards). Golang would probably be fine for some small tools here and there (even for that, Rust or AOT Java would be a consideration), for anything larger, a static JVM or .NET language is strictly superior.
- laumars 8y ago
  > It wouldn't catch this True but you could forget to do that in your alternative example as well (albeit you'd get no instances of a assigned rather than sporadic instances - however the point of testing frameworks is they should catch that kind of human error regardless of the language or it's syntax) > Or even assigning it to a different variable `b`. Actually the compiler would catch that too. > They add up quite quickly in any sizeable project. It's not just one offs here and there, you end up with functions littered in the code base that distract from quickly getting to understand the code when debugging a bug or an outage. I guess it depends on what you're used to but I've always preferred code that abstracted away longer or more complex functions into smaller ones. I guess that's the FP habits in me transferring over to imperative languages. In any case, I've never had any issue debugging such code when under pressure during an outage. > The thing is, golang seems to be used just because it has Google as a name behind it, That's complete and utter BS. In fact I had already cited reasons I like Go. so please don't assume that because you don't like something then it's automatically a bad language that other people can't like either. > This shows up time and again, as people are not able to defend the technical choices behind it in any proper way, People have and they do though. The issue is that there is a hell of a lot of language elitism in the the different programming language cults so it doesn't matter what reasons we might give - you've already decided you don't like feature x and thus our reasons are wrong by default. You demonstrated just this kind of mentality when you argued that people use Go just because of Google in a reply to a post that lists why someone likes Go. > which has already been shown several times that the golang authors are quite bad at defending their decisions, and they're not experienced at language design to begin with The arrogance in that comment is overwhelming. I look forward to the day you create something worthy of recognition and the inevitable backlash on HN from kids who assume they're smarter then you are in every way. This isn't me putting Russ Cox et al on a pedestal - this is me pointing out that talk is cheap and most of the critics on HN are just average engineers at best. > Golang would probably be fine for some small tools here and there (even for that, Rust or AOT Java would be a consideration), for anything larger, a static JVM or .NET language is strictly superior. Clearly not everyone agrees with you there because a lot of successful important projects are now based on Go. You need to learn that features you prioritise are not going to be the same as features others might prioritise - and that having different priorities doesn't make one party wrong and another right.