Comment by gh-throw | Hacker News Reader

Comment by gh-throw | Hacker News Reader

Parent Full thread

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?

> 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.

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".

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

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.

Given that they are PhD level languages from Go developers point of view, maybe tooling alone won't be enough.

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

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/Pa...

https://talks.golang.org/2012/splash.article

Most of that could apply to Kotlin also (familiar from Java, etc). Go's relative lack of features seems more to do with their idiosyncratic programming philosophy [1]. The tone is a bit condescending, but they clearly consider it good enough for themselves and it's usually become their primary tool of choice when Go team members work on new projects.

Personally I can see some appeal of fewer features. When trying to solve some medium-sized problem in Go, I often end up working through in my head 5-10 ways to structure it with Go's existing features (and almost always one of them ends up being satisfactory). If I had a lot more features, I could work through 20+ ways, but what good would that do?

Of course, I'm looking forward to user-defined generics (although their absence hasn't been critical for me). I used them in C#, but I would run into limitations [2]. Although it's taken a long time to arrive, I'd prefer to work with the system that the Go team has designed (and now accepted). To me this doesn't make them look bad?

People complain about nullability etc, but I just don't spend a lot of time on those bugs...

Let's say I just don't understand other languages. What language should I use then? I need memory control (value types), reasonable perf, if GC < 2ms pauses, also cross platform. That seems to mostly leave Rust and C++... are the extra features really worth giving up GC over?

That isn't a rhetorical question by the way, that's how I ended up with Go.

If your position was "most projects should use Kotlin and not Go" I think that's defensible. But you constantly saying Go programmers just can't understand other languages (despite plenty of contrary evidence) gets tiresome.

[1] https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

[2] abstracting over float and double, blittable types, etc

Reply on news.ycombinator.com