8 ms·

I have said it before and I will say it again - for all the deficiencies Go has, it is somehow highly compatible with the way my brain works. One point the art

by krylon 9y ago

I have said it before and I will say it again - for all the deficiencies Go has, it is somehow highly compatible with the way my brain works. One point the article does not mention is the documentation. I think Go's documentation is excellent, it does not overwhelm the reader with its volume, but mostly anything one might want to know about the syntax and semantic can be answered by carefully reading through the documentation that comes along with the development tools. Also, there are some pretty neat static analysis tools for Go out there, and since they are mostly developed in a development-environment-agnostic way, they tend to be usable from a relatively wide range of editors and IDEs. But even just using go vet and golint regularly goes a long way to rooting out all those tiny but tedious bugs and ensure a degree of consistency in naming conventions. I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores, but the fact that my code is laid out in the same way as that of third-party libraries means it is surprisingly easy to dive into somebody else's code and make sense of it. The fact the Go community tends to favor simplicity over brevity can get annoying at times, but when you have to read somebody else's code to figure out if it's buggy or you're using it wrong, it is priceless. There a many things Go could do better (or at all), but if there is no way to implement some feature without sacrificing simplicity, I prefer simplicity. I you want C++, as the saying goes, we know where to find it. ;-) (I'll admit though that the C# designers have done an impressive job at adding lots of features without the language collapsing under its own weight. So it's not like it's impossible.)

pavlov 9y ago
I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscore My taste is the opposite: I can't understand underscores in identifiers, it's like having hiccups inside every thought. But what saddens me is that we're still having this conversation in 2017. It would be trivial for editors to support either style, if only language designs included the concept of word separator inside identifiers, which could then be rendered at display/edit-time according to user preference. Somehow programming languages are extremely resistant to these kinds of improvements. ColorFORTH is the only example that comes to mind of a language designed beyond ASCII.
- krylon 9y ago
  > But what saddens me is that we're still having this conversation in 2017 It is a pointless but easy thing to debate about. I find Go's solution of de facto forcing a certain style on everyone a little harsh, but it is effective. > It would be trivial for editors to support either style Emacs has glasses-mode which displays underscores in camelCase identifiers without changing the source code. It's not the most elegant solution, and when I first heard about it and gave it a try I was working on a code base that used both camelCase and under_score, so glasses-mode actually made the code more confusing, because I never could be sure if the underscore I saw was actually there. But on a code base that uses camelCase consistently, it might help. My point, though, was that it does not really matter that much - if you come from an underscore_heavy_background, it takes some getting used to, but that is all. Once one is used to it, the consistency across not just my own code but the entire ecosystem really pays off. > the concept of word separator inside identifiers That sounds like a very interesting idea. But I think it is probably nearly impossible to introduce into an existing language without breaking a lot of stuff. Perl[56] maybe, there is a package to program Perl in Latin, and if that degree of craziness is supported, I am sure it's possible - it just won't be pretty. Lua comes to mind as well, because in Lua an identifier is just a string used as a key for hash table that holds the local environment. This is exposed to Lua scripts, with enough cleverness one might add something there, too. And there's probably a couple more that I missed. ;-? Has anyone actually done any experiments/research in this area?
- randallsquared 9y ago
  Nim allows either style in the language directly: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
jwilliams 9y ago
My background - self-taught in C, wrote BASIC to make money in High School, learned Java (and used professionally). Eventually ended up with Ruby (Rails). I developed my own LISP-like for many years. Now most of my hobby programming is in Go. I really like it's connection to C. You feel the connection through to lower level programming. I also like the emphasis Go both emphasizes data structures and is first-class with functions. The combination of the two are really easy for me to navigate, but extremely expressive too. It feels like a language that is very grounded in the fundamentals as I see them, but with a modern outlook and tooling. It feels amazing to write a web-based application with the power of C, but feeling confident you're not going to blow your own foot off every step of the way.
jerf 9y ago
"for all the deficiencies Go has, it is somehow highly compatible with the way my brain works." I have been tempted to write a blog post about "Why People Actually Can Write Real Programs In Go." To listen to HN complain about the language you'd think that it must be clearly impossible to ever write a program of any kind without massively copying and pasting everywhere, when in reality I find it's actually quite pleasant for a non-trivial subset of programs. The short answer is that it has a lot of features that people, generally not being used to them, work better than people may realize from the bullet points and often work together better than people realize. Favoring composition over inheritance is a legitimately good choice. Being able to declare interfaces that other objects I don't control conform to has a lot of little effects that you wouldn't anticipate in advance, to the point that while I understand the bondage&discipline impulse to require code to declare what interfaces it supports, I would consider that a legitimate mistake in most of the languages that do that. (In practice, it turns out the problem of "accidental satisfaction" basically doesn't exist. We learned that from the duck typing languages like Python and how they never really had a problem with that.) And while the grand concurrency stuff may seem neat, the little stuff can be nice too; just yesterday I wrote some code that takes a list of servers to query for some particular thing, and it was easy to write it to do them all simultaneously; that wasn't a Grand Architecture thing, it was just a function that casually did something that is a royal pain in many languages. (There are also languages that can do it better; I actually know many of them. Erlang would be roughly a tie here and Haskell could look really awesome if you put a bit of work into it. Elixir might beat Go, not sure, but I know Erlang itself doesn't.) And there's some other things like that. The other thing about Go is that I like it for work, but not necessarily for my hobby. The thing about all those restrictions in Go that apply to me is that they symmetrically apply to my coworkers. As much fun as a more powerful language can be, it becomes a lot less fun when you've got dozens of developers trying to work in one code base in those languages; what is power for you is power for them, too, and, well, let's just say they are not always going to be the most expert developers in the world. I've seen... things. And at times, I've even been the one who did the "... things". So even though I know how to use Haskell productively and generally correctly, I'm generally very uninterested in introducing it into the team environment that I have. This is, IMHO, a very important point that I don't hear discussed often enough. Basically, if you take HN's opinion of "Go is useless and should be wiped from the face of the Earth" as a scientific theory that predicts how useful it would be, the theory is falsified. It is useful and some of us even enjoy it for certain tasks. But I for one would never suggest it is useful for everything and actually frequently warn people off from certain tasks.
hota_mazi 9y ago
> I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores A lot comes down to preference and which language you're used to program, but here is an objective fact: having to reach for the underscore key with your pinky finger on shift is a hassle, especially when you have to do it so often. I suspect it accelerates exposure to carpal tunnel syndrome too. In contrast, the uppercase letters required for camel case can be done either with two hands or with one hand but without reaching as far as you need to to reach the underscore key.
kazinator 9y ago
> for all the deficiencies Go has, it is somehow highly compatible with the way my brain works Careful: that could be a deficiency-for-deficiency compatibility there rather than a good thing. Fix your brain and the compatibility goes away.
fnl 9y ago
Go is an alternative for C (for services), PHP, and server-side JS. I don't understand why people keep comparing it to languages like C++, C#, D, Java, Rust, or Scala. The problems these two sets of languages solve are fundamentally different.
- fauigerzigerk 9y ago
  >The problems these two sets of languages solve are fundamentally different. I'm afraid I fail this intelligence test. What problems are solved by C, Go, PHP and server-side JS but not by any of Java, C++, C#, D, Rust or Scala (and vice versa)? This seems like a completely arbitrary classification to me.
  - fnl 9y ago
    Sorry, I had thought that it was quite obvious: JS, PHP, and Go are almost exclusively used for web-related tasks. Yes, one can find other usage examples, but by and large, that's their main field of application. To expand on this, imagine building some complex application framework with these web-oriented languages. Without decent abstractions and insufficient typed programming support (see e.g. TypeScript to JS transpiling, or writing your own preprocessor macros to simulate generics in Go to avoid having interface{} everywhere, etc), and certainly no support for annotations, macros and other meta-programming techniques. Yes, not all of that high-level stuff is great and takes time to master, and so I understand the niche of Go & PHP & ss-JS: You need to quickly scale up your web services startup, which is often poorly paid work, and so you can't afford experienced developers. Having a simple, common, easy web services development language where you can hire any freshman and get them productive is great. So I'm not saying Go is bad or useless, but it only fits a (big - even, possibly the biggest in software engineering) specific case. ASP, PHP and Node.JS et al. are horrible compared to Go at that, but were the options you had before Go came along, so it's a godsend for web developers. I hope that explains why I don't see Go as comparable to complex, high-level languages - and in no way in competition with them, in fact.
    - fauigerzigerk 9y ago

by krylon 9y ago

pavlov 9y ago

I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscore My taste is the opposite: I can't understand underscores in identifiers, it's like having hiccups inside every thought. But what saddens me is that we're still having this conversation in 2017. It would be trivial for editors to support either style, if only language designs included the concept of word separator inside identifiers, which could then be rendered at display/edit-time according to user preference. Somehow programming languages are extremely resistant to these kinds of improvements. ColorFORTH is the only example that comes to mind of a language designed beyond ASCII.

krylon 9y ago
> But what saddens me is that we're still having this conversation in 2017 It is a pointless but easy thing to debate about. I find Go's solution of de facto forcing a certain style on everyone a little harsh, but it is effective. > It would be trivial for editors to support either style Emacs has glasses-mode which displays underscores in camelCase identifiers without changing the source code. It's not the most elegant solution, and when I first heard about it and gave it a try I was working on a code base that used both camelCase and under_score, so glasses-mode actually made the code more confusing, because I never could be sure if the underscore I saw was actually there. But on a code base that uses camelCase consistently, it might help. My point, though, was that it does not really matter that much - if you come from an underscore_heavy_background, it takes some getting used to, but that is all. Once one is used to it, the consistency across not just my own code but the entire ecosystem really pays off. > the concept of word separator inside identifiers That sounds like a very interesting idea. But I think it is probably nearly impossible to introduce into an existing language without breaking a lot of stuff. Perl[56] maybe, there is a package to program Perl in Latin, and if that degree of craziness is supported, I am sure it's possible - it just won't be pretty. Lua comes to mind as well, because in Lua an identifier is just a string used as a key for hash table that holds the local environment. This is exposed to Lua scripts, with enough cleverness one might add something there, too. And there's probably a couple more that I missed. ;-? Has anyone actually done any experiments/research in this area?
randallsquared 9y ago
Nim allows either style in the language directly: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

jwilliams 9y ago

My background - self-taught in C, wrote BASIC to make money in High School, learned Java (and used professionally). Eventually ended up with Ruby (Rails). I developed my own LISP-like for many years. Now most of my hobby programming is in Go. I really like it's connection to C. You feel the connection through to lower level programming. I also like the emphasis Go both emphasizes data structures and is first-class with functions. The combination of the two are really easy for me to navigate, but extremely expressive too. It feels like a language that is very grounded in the fundamentals as I see them, but with a modern outlook and tooling. It feels amazing to write a web-based application with the power of C, but feeling confident you're not going to blow your own foot off every step of the way.

jerf 9y ago

"for all the deficiencies Go has, it is somehow highly compatible with the way my brain works." I have been tempted to write a blog post about "Why People Actually Can Write Real Programs In Go." To listen to HN complain about the language you'd think that it must be clearly impossible to ever write a program of any kind without massively copying and pasting everywhere, when in reality I find it's actually quite pleasant for a non-trivial subset of programs. The short answer is that it has a lot of features that people, generally not being used to them, work better than people may realize from the bullet points and often work together better than people realize. Favoring composition over inheritance is a legitimately good choice. Being able to declare interfaces that other objects I don't control conform to has a lot of little effects that you wouldn't anticipate in advance, to the point that while I understand the bondage&discipline impulse to require code to declare what interfaces it supports, I would consider that a legitimate mistake in most of the languages that do that. (In practice, it turns out the problem of "accidental satisfaction" basically doesn't exist. We learned that from the duck typing languages like Python and how they never really had a problem with that.) And while the grand concurrency stuff may seem neat, the little stuff can be nice too; just yesterday I wrote some code that takes a list of servers to query for some particular thing, and it was easy to write it to do them all simultaneously; that wasn't a Grand Architecture thing, it was just a function that casually did something that is a royal pain in many languages. (There are also languages that can do it better; I actually know many of them. Erlang would be roughly a tie here and Haskell could look really awesome if you put a bit of work into it. Elixir might beat Go, not sure, but I know Erlang itself doesn't.) And there's some other things like that. The other thing about Go is that I like it for work, but not necessarily for my hobby. The thing about all those restrictions in Go that apply to me is that they symmetrically apply to my coworkers. As much fun as a more powerful language can be, it becomes a lot less fun when you've got dozens of developers trying to work in one code base in those languages; what is power for you is power for them, too, and, well, let's just say they are not always going to be the most expert developers in the world. I've seen... things. And at times, I've even been the one who did the "... things". So even though I know how to use Haskell productively and generally correctly, I'm generally very uninterested in introducing it into the team environment that I have. This is, IMHO, a very important point that I don't hear discussed often enough. Basically, if you take HN's opinion of "Go is useless and should be wiped from the face of the Earth" as a scientific theory that predicts how useful it would be, the theory is falsified. It is useful and some of us even enjoy it for certain tasks. But I for one would never suggest it is useful for everything and actually frequently warn people off from certain tasks.

hota_mazi 9y ago

> I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores A lot comes down to preference and which language you're used to program, but here is an objective fact: having to reach for the underscore key with your pinky finger on shift is a hassle, especially when you have to do it so often. I suspect it accelerates exposure to carpal tunnel syndrome too. In contrast, the uppercase letters required for camel case can be done either with two hands or with one hand but without reaching as far as you need to to reach the underscore key.

kazinator 9y ago

> for all the deficiencies Go has, it is somehow highly compatible with the way my brain works Careful: that could be a deficiency-for-deficiency compatibility there rather than a good thing. Fix your brain and the compatibility goes away.

fnl 9y ago

Go is an alternative for C (for services), PHP, and server-side JS. I don't understand why people keep comparing it to languages like C++, C#, D, Java, Rust, or Scala. The problems these two sets of languages solve are fundamentally different.

fauigerzigerk 9y ago
>The problems these two sets of languages solve are fundamentally different. I'm afraid I fail this intelligence test. What problems are solved by C, Go, PHP and server-side JS but not by any of Java, C++, C#, D, Rust or Scala (and vice versa)? This seems like a completely arbitrary classification to me.
- fnl 9y ago
  Sorry, I had thought that it was quite obvious: JS, PHP, and Go are almost exclusively used for web-related tasks. Yes, one can find other usage examples, but by and large, that's their main field of application. To expand on this, imagine building some complex application framework with these web-oriented languages. Without decent abstractions and insufficient typed programming support (see e.g. TypeScript to JS transpiling, or writing your own preprocessor macros to simulate generics in Go to avoid having interface{} everywhere, etc), and certainly no support for annotations, macros and other meta-programming techniques. Yes, not all of that high-level stuff is great and takes time to master, and so I understand the niche of Go & PHP & ss-JS: You need to quickly scale up your web services startup, which is often poorly paid work, and so you can't afford experienced developers. Having a simple, common, easy web services development language where you can hire any freshman and get them productive is great. So I'm not saying Go is bad or useless, but it only fits a (big - even, possibly the biggest in software engineering) specific case. ASP, PHP and Node.JS et al. are horrible compared to Go at that, but were the options you had before Go came along, so it's a godsend for web developers. I hope that explains why I don't see Go as comparable to complex, high-level languages - and in no way in competition with them, in fact.
  - fauigerzigerk 9y ago