4 ms·

Golang isn't a language for the person writing code today—it's a language for the person who has to come along and take over their codebase after they leave. T

Golang isn't a language for the person writing code today—it's a language for the person who has to come along and take over their codebase after they leave. The farther away I get from "fresh CS grad", actually, the less I give a shit about catering to the person writing the code and helping them express themselves optimally, and the more I care about how much hair I'll lose trying to figure out someone's meta programming or shoehorned-in-because-it's-fashionable functional crap. Either of which I can write just fine, thank you very much, but god knows I'm sick of inheriting such codebases, to the point that these days I basically just won't do that anymore. You have a Rails "app" that's been through three development teams? Cool, good luck with that, next opportunity, thanks. You're not only using React, but your codebase is purely functional (I mean, your functions are objects, you know, but that's quibbling, OK, sure, it's purely functional conceptually-speaking) top-to-bottom and you've got all kinds of supporting libraries to make Javascript contort into kinda-halfway working for this pattern? And you're thinking about porting to Purescript so you can better express yourselves with types? That sounds very nice, but I'm sure it's just too smart for me, thanks for the offer. You're using Go, Typescript where you have to, and your mobile apps are boring, straightforward native code? Oh thank god. When do I start?

pjmlp 6y ago
Not sure if TypeScript, Kotlin, Java, Objective-C and Swift aren't too way over their head for the typical Go user.
- gh-throw 6y ago
  Of those only Java (and, by association, Kotlin, since you'll likely be interacting with Java) strikes me as often-hard-to-read, mostly because of the cultural love of using ten layers to do what two or three layers could. But the tools are good enough that it makes it merely annoying, rather than productivity-torpedoing.
  - pjmlp 6y ago
    Given that they are PhD level languages from Go developers point of view, maybe tooling alone won't be enough.
    - throwaway34241 6y ago
      What's so hard to understand? Go combines static typing, green threads, garbage collection, and lower-level control over memory [1]. These aren't new ideas. It could have been more ambitious. But it's the only mainstream-enough-to-be-useful language that offers that combination of things, making it useful for certain classes of problems (obviously not your problems). To compare to the "PhD level languages", last I checked: Kotlin: no green threads or low-level memory control Swift: no GC, green threads, reflection TypeScript: no threads of any kind or low-level memory control Objective-C: I've used this extensively. It was even more verbose than Go, the non-C parts were less efficient, and it even had a similar primitive type system (although it got a few more features at the end of its life). Also no GC or green threads. I get that you hate using Go, but your Go-developers-are-just-idiots take that you post every thread is basically just flamebait at this point. It's currently a useful tool for problems where Kotlin is too high level but don't need C++. In a few years the JVM will probably have value types and fibers, and Go will have generics, and maybe then it will be possible to compare apples-to-apples. [1] value types, explicit pointers, default buffer/list type that can refer to arbitrary memory ranges, etc
      - pjmlp 6y ago
        I am just following the teachings of the master: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1" "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2" Sources: https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Panel-Systems-Programming-Languages-in-2014-and-Beyond https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa... https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
aranchelk 6y ago
In JS functions are objects, yeah, most frontend functional languages still require some amount of FFI so we haven’t totally lost touch with reality. One could make the argument that JS was one of the first truly mainstream languages with significant FP features, first-class functions, lambdas, and closures, so why the hell are there people out there modeling everything in objects? JS is a multi-paradigm language, my feeling is as long as you're meeting the needs of the business and users, the paradigm you use should really be up to the engineers. I’m sure there are people who do functional programming who fit your description and I'm sure I would also find them quite annoying, but as far as the community goes, I believe them to be on the fringes. I don't see them at FP conferences, meet-ups, or in chatrooms. Many of us are motivated by the same reasons you stated, we want code and test suites that we find straightforward and easy to maintain. I'm not sure how fashionable these languages really are, even talking to experienced engineers, when I say I prefer to work in Haskell, often they've never heard of it and think I've said "Pascal".
dnautics 6y ago
> it's a language for the person who has to come along and take over their codebase after they leave. Hard disagree. I'll grant that in the trivial case , basic cli apps that have to do one thing, the maintainability of go is high, maybe even a very simple microservice. But once you get something more inherently complex, especially if it must do concurrency in all but the most trivial of things (especially as you get concurrent requests that must handle faults, say from a crappy network or a 3rd party system) the language is far, far less easy to get a mental model of, much less debug in anger (or with a system in prod), or even write tests. In my experience, go tests are terribly illegible, often my go coworkers just don't write them, which is worse. Maybe I've just been spoiled by elixir (relevant given the OP topic). And for the record, I've inherited a codebase that has gone through three-ish teams. I work on my corner and I can be fairly sure that the changes I make, features I build are isolated and safe. And this is even with parts of the codebase that I cringe at (and over time I gradually refactor them, with confidence). I have all the tools to ameliorate the team code, and even for the crap parts, reading isn't hellish, and refactoring feels good.

pjmlp 6y ago

Not sure if TypeScript, Kotlin, Java, Objective-C and Swift aren't too way over their head for the typical Go user.

gh-throw 6y ago
Of those only Java (and, by association, Kotlin, since you'll likely be interacting with Java) strikes me as often-hard-to-read, mostly because of the cultural love of using ten layers to do what two or three layers could. But the tools are good enough that it makes it merely annoying, rather than productivity-torpedoing.
- pjmlp 6y ago
  Given that they are PhD level languages from Go developers point of view, maybe tooling alone won't be enough.
  - throwaway34241 6y ago
    What's so hard to understand? Go combines static typing, green threads, garbage collection, and lower-level control over memory [1]. These aren't new ideas. It could have been more ambitious. But it's the only mainstream-enough-to-be-useful language that offers that combination of things, making it useful for certain classes of problems (obviously not your problems). To compare to the "PhD level languages", last I checked: Kotlin: no green threads or low-level memory control Swift: no GC, green threads, reflection TypeScript: no threads of any kind or low-level memory control Objective-C: I've used this extensively. It was even more verbose than Go, the non-C parts were less efficient, and it even had a similar primitive type system (although it got a few more features at the end of its life). Also no GC or green threads. I get that you hate using Go, but your Go-developers-are-just-idiots take that you post every thread is basically just flamebait at this point. It's currently a useful tool for problems where Kotlin is too high level but don't need C++. In a few years the JVM will probably have value types and fibers, and Go will have generics, and maybe then it will be possible to compare apples-to-apples. [1] value types, explicit pointers, default buffer/list type that can refer to arbitrary memory ranges, etc
    - pjmlp 6y ago
      I am just following the teachings of the master: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1" "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2" Sources: https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Panel-Systems-Programming-Languages-in-2014-and-Beyond https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa... https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article

aranchelk 6y ago

In JS functions are objects, yeah, most frontend functional languages still require some amount of FFI so we haven’t totally lost touch with reality. One could make the argument that JS was one of the first truly mainstream languages with significant FP features, first-class functions, lambdas, and closures, so why the hell are there people out there modeling everything in objects? JS is a multi-paradigm language, my feeling is as long as you're meeting the needs of the business and users, the paradigm you use should really be up to the engineers. I’m sure there are people who do functional programming who fit your description and I'm sure I would also find them quite annoying, but as far as the community goes, I believe them to be on the fringes. I don't see them at FP conferences, meet-ups, or in chatrooms. Many of us are motivated by the same reasons you stated, we want code and test suites that we find straightforward and easy to maintain. I'm not sure how fashionable these languages really are, even talking to experienced engineers, when I say I prefer to work in Haskell, often they've never heard of it and think I've said "Pascal".

dnautics 6y ago

> it's a language for the person who has to come along and take over their codebase after they leave. Hard disagree. I'll grant that in the trivial case , basic cli apps that have to do one thing, the maintainability of go is high, maybe even a very simple microservice. But once you get something more inherently complex, especially if it must do concurrency in all but the most trivial of things (especially as you get concurrent requests that must handle faults, say from a crappy network or a 3rd party system) the language is far, far less easy to get a mental model of, much less debug in anger (or with a system in prod), or even write tests. In my experience, go tests are terribly illegible, often my go coworkers just don't write them, which is worse. Maybe I've just been spoiled by elixir (relevant given the OP topic). And for the record, I've inherited a codebase that has gone through three-ish teams. I work on my corner and I can be fairly sure that the changes I make, features I build are isolated and safe. And this is even with parts of the codebase that I cringe at (and over time I gradually refactor them, with confidence). I have all the tools to ameliorate the team code, and even for the crap parts, reading isn't hellish, and refactoring feels good.