4 ms·

> Golang is a pragmatic crowd Why do people keep on saying that? Would people say javascript is for the pragmatic crowd because jsfiddle exists ? no Go is a b

by aikah 11y ago

> Golang is a pragmatic crowd Why do people keep on saying that? Would people say javascript is for the pragmatic crowd because jsfiddle exists ? no Go is a badly designed language period. the type system forces devs to write runtime type assertions which should be the job of the compiler thanks to parametric types, if go designers knew one or 2 things about types. The fact that Go dismisses 30+ years of type theory isn't pragmatism. It's ignorance. Nobody would call PHP pragmatic yet even PHP is more expressive.

dmacvicar 11y ago
I had the same opinion as you until I started some code with it. The true is that I had never been so productive writing code. The friction from what is in your head and the code is almost 0. It is true that I ended writing a few functions that were there only because the lack of generics, the type system and other stuff being "built-in". But at the end, I think it was an order of magnitude less often than I was expecting it to. I was wrong.
- 72deluxe 11y ago
  Your comment is interesting, it has made me want to look at the language, so thanks. But I think that the "friction from what is in your head to code" probably betrays that you weren't settled in a previous language? I only say this because I have zero friction writing C++, and have to think mildly backwards when it comes to C# or Java, and definitely Objective-C. Even PHP is like simplified C++ to me, so I write everything like it is a dumbed-down dialect of C++. I suppose it is just what some people find comfortable.
  - sacado2 11y ago
    > But I think that the "friction from what is in your head to code" probably betrays that you weren't settled in a previous language? I had the same feeling as the user you're answering to. And I have used quite a bunch of languages I've been quite productive with (C, C++, PHP, Python, Java, Ada), but I've never felt with these languages as little "friction" as with Go. I mean, that language is so dumb that you don't have to think about the right way to do stuff. It's obvious. Boring, sometimes verbose, but obvious. It doesn't stand in the way between me and the problem.
    - 72deluxe 11y ago
      That's really good that it's so dumb that you don't need to jump through hoops to think of the way to do it. Clever! Just code and go!
      - dmacvicar 11y ago
        It is not unicorns either. * Transforming a collection means doing boring for loops instead of one-liners. * interfaces/duck typing is great. But hey, []interface{} does not fit into interface{}. * Structs with fields are encouraged, but there is no uniform Uniform access principle and that sucks. * etc But definitely, my own "science" confirms that it turned to be out less of a problem (for my own usage) compared to better languages with more friction.
        sacado2 11y ago
        Yep. I've been bored by the fact that putting an []int into an []interface{} doesn't work, too (although the reason is obvious).
    - dmacvicar 11y ago
      I was following Rust very entusiastically. But at some point the language was getting itself in the way of the problem I was solving. I am not only talking about the strict compile checks. I am talking about that extra thinking in the ten ways you can design it and how it should be done in "proper" Rust. And the friction is not only in the language, but also in the standard library. A language that comes with XML/json marshal/unmarshal plus a quite decent http client/server framework covers most of what I need to do. I am sure if Rust had included in the standard package http/xml/json it would be far more popular. I understand the voices that say "It does not belong there", "the language is not targeted at that". Fine. But then I found myself having not much user for the language, even if I loved the idea/theory behind it, plus that I could not get comfortable thinking in it.
Manishearth 11y ago
[I'm a Rust user, and not particularly fond of Go, but...] Not having great static typing doesn't make it not pragmatic. Given Go's purpose, it is extremely pragmatic. One of the reasons Google uses Go is because their employees are often fresh out of college and might not be familiar with the depths of type systems. If you look at most professional Java/C++ code (starting to see this with Rust too), the features of the language are used to their full extent to create really convoluted APIs (to an outsider not familiar with the language). So, to work on it, one must first become familiar with the intricacies of these languages (this is not as easy as picking up a book, you need experience), and then with how the language is used in context, which is another time consuming thing. Instead, go trades off some higher level features for compilation speed and ease of learning. After programming in Go for a week I was able to pick up any Go code -- ranging from the standard library to various other applications, and know what was going on. I cannot say the same about Java or C++ or Rust; generics/templates/virtual/friend/advanced typesystem gymnastics all are used to great extents in the code for a standard library or some large application. one may be able to use the language for your own stuff after a week of learning and hacking, but one will need much more time before they're well suited to contribute significantly to existing codebases. A course I took recently was taught by a PL aficionado. He knew Rust, Nim, and Go, along with many older languages. Go, Rust, and Erlang, among others, would have worked beautifully for the project topic (concurrent stuff). He made everyone write in Go because he wanted a uniform language for project evaluation, and because Go is something students could reasonably pick up in a week without constraints on their background. ========================= At the same time, the Go community is pretty awesome. There is a "go way" of doing things, and while it is pretty rigid, that doesn't make it not pragmatic. From my (admittedly limited) discussions with them, they do seem to think practically/pragmatically. There are good reasons for wanting to use Go. These folks know those boundaries, and think practically within them.
- Dewie3 11y ago
  Though there might be much to say about the different implementations of generics, I've found them to be easy to understand and use in languages. No type theory required. That has been more like "Oh, so that's the name for that thing/aspect, neat". If I don't have a problem with that, those coveted master race Google developers should have absolutely no problem with it.

by aikah 11y ago

dmacvicar 11y ago

I had the same opinion as you until I started some code with it. The true is that I had never been so productive writing code. The friction from what is in your head and the code is almost 0. It is true that I ended writing a few functions that were there only because the lack of generics, the type system and other stuff being "built-in". But at the end, I think it was an order of magnitude less often than I was expecting it to. I was wrong.

72deluxe 11y ago
Your comment is interesting, it has made me want to look at the language, so thanks. But I think that the "friction from what is in your head to code" probably betrays that you weren't settled in a previous language? I only say this because I have zero friction writing C++, and have to think mildly backwards when it comes to C# or Java, and definitely Objective-C. Even PHP is like simplified C++ to me, so I write everything like it is a dumbed-down dialect of C++. I suppose it is just what some people find comfortable.
- sacado2 11y ago
  > But I think that the "friction from what is in your head to code" probably betrays that you weren't settled in a previous language? I had the same feeling as the user you're answering to. And I have used quite a bunch of languages I've been quite productive with (C, C++, PHP, Python, Java, Ada), but I've never felt with these languages as little "friction" as with Go. I mean, that language is so dumb that you don't have to think about the right way to do stuff. It's obvious. Boring, sometimes verbose, but obvious. It doesn't stand in the way between me and the problem.
  - 72deluxe 11y ago
    That's really good that it's so dumb that you don't need to jump through hoops to think of the way to do it. Clever! Just code and go!
    - dmacvicar 11y ago
      It is not unicorns either. * Transforming a collection means doing boring for loops instead of one-liners. * interfaces/duck typing is great. But hey, []interface{} does not fit into interface{}. * Structs with fields are encouraged, but there is no uniform Uniform access principle and that sucks. * etc But definitely, my own "science" confirms that it turned to be out less of a problem (for my own usage) compared to better languages with more friction.
      - sacado2 11y ago
        Yep. I've been bored by the fact that putting an []int into an []interface{} doesn't work, too (although the reason is obvious).
  - dmacvicar 11y ago
    I was following Rust very entusiastically. But at some point the language was getting itself in the way of the problem I was solving. I am not only talking about the strict compile checks. I am talking about that extra thinking in the ten ways you can design it and how it should be done in "proper" Rust. And the friction is not only in the language, but also in the standard library. A language that comes with XML/json marshal/unmarshal plus a quite decent http client/server framework covers most of what I need to do. I am sure if Rust had included in the standard package http/xml/json it would be far more popular. I understand the voices that say "It does not belong there", "the language is not targeted at that". Fine. But then I found myself having not much user for the language, even if I loved the idea/theory behind it, plus that I could not get comfortable thinking in it.

Manishearth 11y ago

[I'm a Rust user, and not particularly fond of Go, but...] Not having great static typing doesn't make it not pragmatic. Given Go's purpose, it is extremely pragmatic. One of the reasons Google uses Go is because their employees are often fresh out of college and might not be familiar with the depths of type systems. If you look at most professional Java/C++ code (starting to see this with Rust too), the features of the language are used to their full extent to create really convoluted APIs (to an outsider not familiar with the language). So, to work on it, one must first become familiar with the intricacies of these languages (this is not as easy as picking up a book, you need experience), and then with how the language is used in context, which is another time consuming thing. Instead, go trades off some higher level features for compilation speed and ease of learning. After programming in Go for a week I was able to pick up any Go code -- ranging from the standard library to various other applications, and know what was going on. I cannot say the same about Java or C++ or Rust; generics/templates/virtual/friend/advanced typesystem gymnastics all are used to great extents in the code for a standard library or some large application. one may be able to use the language for your own stuff after a week of learning and hacking, but one will need much more time before they're well suited to contribute significantly to existing codebases. A course I took recently was taught by a PL aficionado. He knew Rust, Nim, and Go, along with many older languages. Go, Rust, and Erlang, among others, would have worked beautifully for the project topic (concurrent stuff). He made everyone write in Go because he wanted a uniform language for project evaluation, and because Go is something students could reasonably pick up in a week without constraints on their background. ========================= At the same time, the Go community is pretty awesome. There is a "go way" of doing things, and while it is pretty rigid, that doesn't make it not pragmatic. From my (admittedly limited) discussions with them, they do seem to think practically/pragmatically. There are good reasons for wanting to use Go. These folks know those boundaries, and think practically within them.

Dewie3 11y ago
Though there might be much to say about the different implementations of generics, I've found them to be easy to understand and use in languages. No type theory required. That has been more like "Oh, so that's the name for that thing/aspect, neat". If I don't have a problem with that, those coveted master race Google developers should have absolutely no problem with it.