7 ms·

After switching to ML languages for most development tasks, I don’t think I could face using a language with so few features. Is most of the hype from a dev op

After switching to ML languages for most development tasks, I don’t think I could face using a language with so few features. Is most of the hype from a dev ops perspective? Go looks tiresome to program in.

coldtea 8y ago
Well, there's some blub paradox (PG) at play. As Go team found out, it's not like people go from C++, OcamL or other full featured languages to Go. For Python/Ruby etc programmings coming to Go, the lack of features feels exciting, because it makes them think they're programming closer to the metal (what with types, and static compilation, and contiguous arrays, and pointers).
- blub 8y ago
  Go does have some benefits. In my case, cross-compiling into one binary means it could be the easiest way to build and deploy on an embedded platform where I normally use a quite complex to set up C++ toolchain. At the same time Go's a typical "sidekick" language, because it's really good only at a few things, unlike C++ or Java which are useable for almost everything.
- laumars 8y ago
  I've written stuff in C++ as well as Python. The simplicity of Go appeals to me because it means the code is generally more readable (eg people aren't abusing advanced features quite so much). Anecdotally I've found reading other peoples Go code far easy than I've found reading other peoples code in pretty much any other language. YMMV though
  - adgasf 8y ago
    That can happen. However, when you do not have the proper language features (e.g. pipe operator) then code can become much less readable because it is more verbose and the control flow is unclear. I think that simple languages only lead to more readable code when the problem domain is also simple.
    - laumars 8y ago
      Not really no. The relationship between verbosity and readability of control flow isn't as clear cut as you describe. For example Java is often praised in threads regarding Go yet that is far more verbose. C++ has all the features you described yet is still more verbose (overall) and less readable than Go. Plus your post reads as if complex problems doesn't also decrease the readability in more descriptive languages but my experience is complex logic will be inherently harder to read regardless of the language. I suspect what is actually happening here is your familiarity with language X means you find it easier to read code in language X - and that has nothing to do with verbosity, "proper" language features or whatever else. Personally, however, after 30 years of development on well over a dozen different languages (even some I'd be embarrassed to admit to), Go has consistently been up there for me as one of the easiest to read.
      - adgasf 8y ago
        I don't see exactly how my comment connects with yours, so I will just try to clarify / expand on it. * Java is often hard to read because it is verbose and lacks language features. For example, without operator overloading vector math does not read well. * C++ (14 upwards) can be made very readable or it can be made very unreadable because it has so many features. I don't think it is obvious that C++ is less readable than Go. Are we talking about the worst case? the best case? the average case? * The connection between control-flow clarity and verbosity is IMO due to features like the pipe operator and do-notation. These allow you to have code that reads linearly even when the execution is not. The alternative is something with many explicit function calls and nesting that jumps all over the place. Take a look at a Node.js program that uses async/await vs without and you will see what I mean. * A complex problem domain will lead to harder to read code than a simple domain, but this is not relevant. My point is that an implementation for a complex problem in a language with features to manage complexity will be more readable than an implementation for a complex problem in a simpler language. * It sounds like we have both extensively used multiple programming languages but reached different conclusions.
        laumars 8y ago
  - coldtea 8y ago
    >Anecdotally I've found reading other peoples Go code far easy than I've found reading other peoples code in pretty much any other language At the micro level yes. At the macro level though, it's easier to understand 10 lines of dense code than the 200 lines Go forces you to write for the same thing. At least you can see them in your screen all at once (and usually express the intent more directly).
    - laumars 8y ago
      For you, perhaps. However for me I completely disagree. What you're failing to understand is that this is an entirely subjective rather than objective matter. What works for you isn't proof that it's the same for everyone else. This is why I've said "The simplicity of Go appeals to me", "Anecdotally I've found" and "YMMV" to made it clear in my post that the subject you're discussing is actually a matter of personal taste.
      - coldtea 8y ago
        >What you're failing to understand is that this is an entirely subjective rather than objective matter. I don't think it is subjective. It's just that as an industry we don't have large scale research into such things. >What works for you isn't proof that it's the same for everyone else. No, but our brains co-developed evolutionary for millions of years for some of us to be widely different than others in how they work.
        laumars 8y ago
        > I don't think it is subjective. The very fact that we disagree on what we find readable should be evidence enough that it's subjective. > It's just that as an industry we don't have large scale research into such things. I don't need large scale research to tell me what I, personally, find easier or harder to read. Research would tell us what the general rule of thumb is but that's very different to saying there's a definitive rule that applies to everyone uniformly. > No, but our brains co-developed evolutionary for millions of years for some of us to be widely different than others in how they work. Forgive me if I'm missing your point here but some people like fast cars and some people like to cycle. Some people want kids while others do not. Some people enjoy working in IT while others want to be gardeners, carpenters, mechanics, doctors, lawyers, etc. Even specifically to HN, we have enough arguments on here about emacs vs vi; CLI vs GUI; and tiled window managers vs dynamic / overlapping windows to demonstrate that personal preference is alive and well in the field of IT. Yet it's strange how you consider it not to be applicable when it comes to language preferences. I suggest that's failing of imagination on your part.
- sacado2 8y ago
  Maybe you're taking the blub paradox backwards. People think Go is worse than other languages because they look at it from a PL theory point of view, ignoring the practical aspects. "Compilation speed? Trivial cross-compilation and deployment? Consistent coding style accross projects? Ability to recruit junior developers/maintainers? Warnings-as-errors? Who needs that?"
  - coldtea 8y ago
    >Maybe you're taking the blub paradox backwards. People think Go is worse than other languages because they look at it from a PL theory point of view That's not the canonical version of the blub paradox though. In the canonical description it's the increased expression (due to advanced PL features like macros and closures) of the language that can't be appreciated by the blub programer. So, Go is the one that lacks those things. One could make a case that the other things you mention (compilation speed, cross compilation ease, etc) are also important and should be appreciated, but that wouldn't be the blub paradox. Besides, other languages can have those as well while keeping their advanced features (compilation speed aside, the rest are more about tooling work, which is orthogonal to the language. And D, for one, can compile as fast as Go, while still having Generics). https://digitalmars.com/d/archives/digitalmars/D/D_compilation_speed_vs._go_108831.html https://digitalmars.com/d/archives/digitalmars/D/D_compilati...
    - pjmlp 8y ago
      > And D, for one, can compile as fast as Go, while still having Generics And Delphi, Eiffel,...
      - sacado2 8y ago
        Not the experience I had with Eiffel back then (but it was decades ago).
        pjmlp 8y ago
        Were you generating native code all the time via C export instead of using MELT?
suprfnk 8y ago
Which ML do you mostly use for "general development"? Like simple tools, small web API's, etc? And what's the development/deployment story, compared to Go's (i.e. single .go file, easy (cross)compilation, single binary, pretty fast out of the box)? I'm currently mainly using Go for these kinds of things, but I'm very interested in trying out an ML for this. I've tried Haskell but it seems very complex in a lot of cases.
- nestorD 8y ago
  F# might be a good fit: it is mature, has modern tooling and, in my experience, people tend to get productive quickly.

coldtea 8y ago

Well, there's some blub paradox (PG) at play. As Go team found out, it's not like people go from C++, OcamL or other full featured languages to Go. For Python/Ruby etc programmings coming to Go, the lack of features feels exciting, because it makes them think they're programming closer to the metal (what with types, and static compilation, and contiguous arrays, and pointers).

blub 8y ago
Go does have some benefits. In my case, cross-compiling into one binary means it could be the easiest way to build and deploy on an embedded platform where I normally use a quite complex to set up C++ toolchain. At the same time Go's a typical "sidekick" language, because it's really good only at a few things, unlike C++ or Java which are useable for almost everything.
laumars 8y ago
I've written stuff in C++ as well as Python. The simplicity of Go appeals to me because it means the code is generally more readable (eg people aren't abusing advanced features quite so much). Anecdotally I've found reading other peoples Go code far easy than I've found reading other peoples code in pretty much any other language. YMMV though
- adgasf 8y ago
  That can happen. However, when you do not have the proper language features (e.g. pipe operator) then code can become much less readable because it is more verbose and the control flow is unclear. I think that simple languages only lead to more readable code when the problem domain is also simple.
  - laumars 8y ago
    Not really no. The relationship between verbosity and readability of control flow isn't as clear cut as you describe. For example Java is often praised in threads regarding Go yet that is far more verbose. C++ has all the features you described yet is still more verbose (overall) and less readable than Go. Plus your post reads as if complex problems doesn't also decrease the readability in more descriptive languages but my experience is complex logic will be inherently harder to read regardless of the language. I suspect what is actually happening here is your familiarity with language X means you find it easier to read code in language X - and that has nothing to do with verbosity, "proper" language features or whatever else. Personally, however, after 30 years of development on well over a dozen different languages (even some I'd be embarrassed to admit to), Go has consistently been up there for me as one of the easiest to read.
    - adgasf 8y ago
      I don't see exactly how my comment connects with yours, so I will just try to clarify / expand on it. * Java is often hard to read because it is verbose and lacks language features. For example, without operator overloading vector math does not read well. * C++ (14 upwards) can be made very readable or it can be made very unreadable because it has so many features. I don't think it is obvious that C++ is less readable than Go. Are we talking about the worst case? the best case? the average case? * The connection between control-flow clarity and verbosity is IMO due to features like the pipe operator and do-notation. These allow you to have code that reads linearly even when the execution is not. The alternative is something with many explicit function calls and nesting that jumps all over the place. Take a look at a Node.js program that uses async/await vs without and you will see what I mean. * A complex problem domain will lead to harder to read code than a simple domain, but this is not relevant. My point is that an implementation for a complex problem in a language with features to manage complexity will be more readable than an implementation for a complex problem in a simpler language. * It sounds like we have both extensively used multiple programming languages but reached different conclusions.
      - laumars 8y ago
- coldtea 8y ago
  >Anecdotally I've found reading other peoples Go code far easy than I've found reading other peoples code in pretty much any other language At the micro level yes. At the macro level though, it's easier to understand 10 lines of dense code than the 200 lines Go forces you to write for the same thing. At least you can see them in your screen all at once (and usually express the intent more directly).
  - laumars 8y ago
    For you, perhaps. However for me I completely disagree. What you're failing to understand is that this is an entirely subjective rather than objective matter. What works for you isn't proof that it's the same for everyone else. This is why I've said "The simplicity of Go appeals to me", "Anecdotally I've found" and "YMMV" to made it clear in my post that the subject you're discussing is actually a matter of personal taste.
    - coldtea 8y ago
      >What you're failing to understand is that this is an entirely subjective rather than objective matter. I don't think it is subjective. It's just that as an industry we don't have large scale research into such things. >What works for you isn't proof that it's the same for everyone else. No, but our brains co-developed evolutionary for millions of years for some of us to be widely different than others in how they work.
      - laumars 8y ago
        > I don't think it is subjective. The very fact that we disagree on what we find readable should be evidence enough that it's subjective. > It's just that as an industry we don't have large scale research into such things. I don't need large scale research to tell me what I, personally, find easier or harder to read. Research would tell us what the general rule of thumb is but that's very different to saying there's a definitive rule that applies to everyone uniformly. > No, but our brains co-developed evolutionary for millions of years for some of us to be widely different than others in how they work. Forgive me if I'm missing your point here but some people like fast cars and some people like to cycle. Some people want kids while others do not. Some people enjoy working in IT while others want to be gardeners, carpenters, mechanics, doctors, lawyers, etc. Even specifically to HN, we have enough arguments on here about emacs vs vi; CLI vs GUI; and tiled window managers vs dynamic / overlapping windows to demonstrate that personal preference is alive and well in the field of IT. Yet it's strange how you consider it not to be applicable when it comes to language preferences. I suggest that's failing of imagination on your part.
sacado2 8y ago
Maybe you're taking the blub paradox backwards. People think Go is worse than other languages because they look at it from a PL theory point of view, ignoring the practical aspects. "Compilation speed? Trivial cross-compilation and deployment? Consistent coding style accross projects? Ability to recruit junior developers/maintainers? Warnings-as-errors? Who needs that?"
- coldtea 8y ago
  >Maybe you're taking the blub paradox backwards. People think Go is worse than other languages because they look at it from a PL theory point of view That's not the canonical version of the blub paradox though. In the canonical description it's the increased expression (due to advanced PL features like macros and closures) of the language that can't be appreciated by the blub programer. So, Go is the one that lacks those things. One could make a case that the other things you mention (compilation speed, cross compilation ease, etc) are also important and should be appreciated, but that wouldn't be the blub paradox. Besides, other languages can have those as well while keeping their advanced features (compilation speed aside, the rest are more about tooling work, which is orthogonal to the language. And D, for one, can compile as fast as Go, while still having Generics). https://digitalmars.com/d/archives/digitalmars/D/D_compilation_speed_vs._go_108831.html https://digitalmars.com/d/archives/digitalmars/D/D_compilati...
  - pjmlp 8y ago
    > And D, for one, can compile as fast as Go, while still having Generics And Delphi, Eiffel,...
    - sacado2 8y ago
      Not the experience I had with Eiffel back then (but it was decades ago).
      - pjmlp 8y ago
        Were you generating native code all the time via C export instead of using MELT?

suprfnk 8y ago

Which ML do you mostly use for "general development"? Like simple tools, small web API's, etc? And what's the development/deployment story, compared to Go's (i.e. single .go file, easy (cross)compilation, single binary, pretty fast out of the box)? I'm currently mainly using Go for these kinds of things, but I'm very interested in trying out an ML for this. I've tried Haskell but it seems very complex in a lot of cases.

nestorD 8y ago
F# might be a good fit: it is mature, has modern tooling and, in my experience, people tend to get productive quickly.