3 ms·

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

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
    - throwaway34241 6y ago
      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-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti... [2] abstracting over float and double, blittable types, etc

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
  - throwaway34241 6y ago
    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-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti... [2] abstracting over float and double, blittable types, etc