13 ms·

I have been writing Go, Node.js and PHP for quite a while now. I don't think golang is overhyped; nor it's a silver bullet. There are systems like Kubernetes, e

I have been writing Go, Node.js and PHP for quite a while now. I don't think golang is overhyped; nor it's a silver bullet. There are systems like Kubernetes, etcd, and so on that are implemented in Golang and they work really well. I think problem is people trying to use Golang for EVERYTHING! There are so many things I would disagree with in the article; but I won't disagree with the fact that if you want language with dynamic nature (Ruby, PHP, JS) and you expect to find those conveniences in Golang you are flat out wrong. Reading original article this is the exact feeling I get, somebody was like "look look a cool new toy" and the herd followed.

edem 9y ago
If you look for an oop or fp language you are also out of luck. You are only happy if you look for a better C which most people aren't.
- fileeditview 9y ago
  Even then you can go wrong. I've learned that first hand while trying to write some lower level networking stuff in Go. Also OOP in Go is perfectly fine.. it's just by composition only and without inheritance.
  - lloeki 9y ago
    Many people were taught OOP the UML and Java way†, to which the concept of prototype-based inheritance is completely alien, while composition is not even on their radar. † Although they have their fair share of issues, this is not a jab at UML nor Java themselves, but the way things have been taught, terribly, for so many.
    - fileeditview 9y ago
      Yes that's true. When I was at university we learned about the concept of composition but the reference language for this 'software engineering' course was C++. The whole composition idea felt contrived at that point. Some time later I learned Lua for fun and almost instantly understood what this whole prototype based programming / composition was about :) TLDR: While I learned about composition at university, they failed to really show how it is used and what it is good for..
      - barrkel 9y ago
        JS mixin / Ruby module / C++ mixin style composition are less than excellent, mind - throwing all the methods from multiple locations into a single scope is a recipe for implicit dependencies. There's an assumption that you won't define any methods that the mixins also define, not only today, but in the future; and even more, you assume that a same-named method won't be defined in multiple mixins, not only today, but in the future. IMO it's much better to explicitly reference all mixins, and compose by reference rather than by direct inclusion, unless the composition has strong reliance on the identity of 'this' / 'self' in its implementation.
        clover-lab 9y ago
        Which bring us to old school has-a relationship. Nothing wrong with that.
    - exikyut 9y ago
      What would you consider solid references to learn sane OOP? I have a vague working model of object orientation but a lot of the finer details go straight over my head.
      - deleted 9y ago
        [deleted]
      - CamTin 9y ago
        While Lisp is usually associated with FP practices, the CLOS (Common Lisp Object System) really helped me with getting OOP to click as a concept. Part of it is that, CLOS is just Lisp, so all of the concepts of OO programming are there with none of the syntax generally added in other OO languages. Also, the method/function names clearly name all the concepts instead of using opaque notation: SLOT-VALUE instead of dot, arrow, or double-colon notation, DEFCLASS does what it says on the tin instead of the vaguer "class ClassName { }" of C++/Java/etc. I feel like this makes it clearer what is happening. A good overview of CLOS is chapters 16 and 17 of /Practical Common Lisp/ (http://www.gigamonkeys.com/book/ http://www.gigamonkeys.com/book/) I've heard other people speak similarly of learning Perl's MOOSE after already being familiar with non-OO Perl. This probably is no coincidence since MOOSE is heavily inspired by CLOS.
      - jerf 9y ago
        I'm being very serious here, with no sarcasm: Using a language that has an alternate model of OO that either simply doesn't have inheritance, or makes it relatively hard. IMHO it doesn't matter much how much you read about the differences, until you get in there it won't do much good. This is a good place to have a throwaway project on hand, because your first try is likely to be a very big mess. If you know an inheritance model and a non-inheritance model, you'll be well on your way to understanding the nuances because you'll have the experience in the field. (For reference, my personal definition of OO is pretty much any language where you can write object.method(arguments), some kind of polymorphism is made available on that, and that is either the primary or a very important element of design in the language. It's a very expansive definition because I find that having massive definition debates about what OO is to be nothing more than useless flamewars.)
      - 9y ago
- pjmlp 9y ago
  That is basically Go’s niche, the revival of Limbo, compiled instead of using the Dis VM. Which took C’s place for user space applications on Inferno, the last Plan 9 iteration.
  - PeachPlum 9y ago
    Inferno was sold to Vita Nuova Holdings Ltd in March 2000. Other licensed versions exist, I was working on one until 2007. Plan9 3rd edition was released June 7, 2000 Plan9 4th edition was released in 2002 This version went into continuous improvement mode, the latest commit in the tree was Apr 29 2017
- cies 9y ago
  > You are only happy if you look for a better C which most people aren't. I'd argue Rust is the "better" C. Go is a "simpler" C, at the expense of expressiveness, features, speed (only noticable in very low level usecases) and applicability for certain domains (Go is primarily for networked apps). In the same way Java wanted to be a simpler C++ (which came with it's own drawbacks). And for me Go is more of a competitor to Java (as Java is mostly used for networked applications) than it is to C.
  - jchw 9y ago
    To me, Rust is like C++, Go is like C. Rust loves zero cost abstractions, and isn't afraid to be complicated. It gives the programmer as much power as possible. Go is simple and actually very fast. The garbage collector is probably the biggest hurdle for performance and it's still best in class. Definitely higher level than C, but not enormously so.
    - cies 9y ago
      > Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that corner. Go obviously isn't.
      - jchw 9y ago
        >C was also king of the zero cost abstractions. C++ has static dispatch classes, templates, constexpr, and macros. C just has macros. Any other abstraction costs machine code. C++ also offers a lot of low cost abstraction like RAII-style scoping. >C sure is not afraid to be complicated. Not sure in what sense you're talking. C is not complicated. It's low level. It's exposing complications in the underlying model of a computer. Example: pointers in C are not complicated. Understanding how they work may be for beginners, but that just reflects how hard it is to understand what's going on in a computer. C is accidentally complicated where it is flawed; the non-orthogonal behavior with arrays and the syntax for function pointers are examples. Go fixes some of these flaws, which is unsurprising since it was informed by people close to the origins of UNIX and C (y'know, like, Rob Pike?) >I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). Sounds a lot like C++. It isn't accidental or coincidental that it is a favorite for high performance but complicated stuff like game and browser development. This is no surprise since Mozilla wrote it to replace usages of C++ for memory safety and concurrency, not because C++ didn't offer enough. C++ is flawed in ways Rust isnt, but that doesn't mean the two don't share a lot of traits, and it was Not by accident. Complexity is one of them. >C, C++, Rust are all in that corner. > >Go obviously isn't. Since you've offered no reasons for why this would be true, I can't actually refute it. But it doesn't make a ton of sense. Go and Rust both let you shoot yourself in the foot literally as much as you want. Go directly facilitates assembly code and allows direct memory access with unsafe. Rust also does this. Go tries to be memory safe and provide concurrency primitives. Rust goes about this in a different way. I don't see where they significantly differ. Rust differs most in it's superior memory safety model and low cost abstractions. Go differs most in it's simplicity and built-in concurrency. But they both feel close to their own origins.

edem 9y ago

If you look for an oop or fp language you are also out of luck. You are only happy if you look for a better C which most people aren't.

fileeditview 9y ago
Even then you can go wrong. I've learned that first hand while trying to write some lower level networking stuff in Go. Also OOP in Go is perfectly fine.. it's just by composition only and without inheritance.
- lloeki 9y ago
  Many people were taught OOP the UML and Java way†, to which the concept of prototype-based inheritance is completely alien, while composition is not even on their radar. † Although they have their fair share of issues, this is not a jab at UML nor Java themselves, but the way things have been taught, terribly, for so many.
  - fileeditview 9y ago
    Yes that's true. When I was at university we learned about the concept of composition but the reference language for this 'software engineering' course was C++. The whole composition idea felt contrived at that point. Some time later I learned Lua for fun and almost instantly understood what this whole prototype based programming / composition was about :) TLDR: While I learned about composition at university, they failed to really show how it is used and what it is good for..
    - barrkel 9y ago
      JS mixin / Ruby module / C++ mixin style composition are less than excellent, mind - throwing all the methods from multiple locations into a single scope is a recipe for implicit dependencies. There's an assumption that you won't define any methods that the mixins also define, not only today, but in the future; and even more, you assume that a same-named method won't be defined in multiple mixins, not only today, but in the future. IMO it's much better to explicitly reference all mixins, and compose by reference rather than by direct inclusion, unless the composition has strong reliance on the identity of 'this' / 'self' in its implementation.
      - clover-lab 9y ago
        Which bring us to old school has-a relationship. Nothing wrong with that.
  - exikyut 9y ago
    What would you consider solid references to learn sane OOP? I have a vague working model of object orientation but a lot of the finer details go straight over my head.
    - deleted 9y ago
      [deleted]
    - CamTin 9y ago
      While Lisp is usually associated with FP practices, the CLOS (Common Lisp Object System) really helped me with getting OOP to click as a concept. Part of it is that, CLOS is just Lisp, so all of the concepts of OO programming are there with none of the syntax generally added in other OO languages. Also, the method/function names clearly name all the concepts instead of using opaque notation: SLOT-VALUE instead of dot, arrow, or double-colon notation, DEFCLASS does what it says on the tin instead of the vaguer "class ClassName { }" of C++/Java/etc. I feel like this makes it clearer what is happening. A good overview of CLOS is chapters 16 and 17 of /Practical Common Lisp/ (http://www.gigamonkeys.com/book/ http://www.gigamonkeys.com/book/) I've heard other people speak similarly of learning Perl's MOOSE after already being familiar with non-OO Perl. This probably is no coincidence since MOOSE is heavily inspired by CLOS.
    - jerf 9y ago
      I'm being very serious here, with no sarcasm: Using a language that has an alternate model of OO that either simply doesn't have inheritance, or makes it relatively hard. IMHO it doesn't matter much how much you read about the differences, until you get in there it won't do much good. This is a good place to have a throwaway project on hand, because your first try is likely to be a very big mess. If you know an inheritance model and a non-inheritance model, you'll be well on your way to understanding the nuances because you'll have the experience in the field. (For reference, my personal definition of OO is pretty much any language where you can write object.method(arguments), some kind of polymorphism is made available on that, and that is either the primary or a very important element of design in the language. It's a very expansive definition because I find that having massive definition debates about what OO is to be nothing more than useless flamewars.)
    - 9y ago
pjmlp 9y ago
That is basically Go’s niche, the revival of Limbo, compiled instead of using the Dis VM. Which took C’s place for user space applications on Inferno, the last Plan 9 iteration.
- PeachPlum 9y ago
  Inferno was sold to Vita Nuova Holdings Ltd in March 2000. Other licensed versions exist, I was working on one until 2007. Plan9 3rd edition was released June 7, 2000 Plan9 4th edition was released in 2002 This version went into continuous improvement mode, the latest commit in the tree was Apr 29 2017
cies 9y ago
> You are only happy if you look for a better C which most people aren't. I'd argue Rust is the "better" C. Go is a "simpler" C, at the expense of expressiveness, features, speed (only noticable in very low level usecases) and applicability for certain domains (Go is primarily for networked apps). In the same way Java wanted to be a simpler C++ (which came with it's own drawbacks). And for me Go is more of a competitor to Java (as Java is mostly used for networked applications) than it is to C.
- jchw 9y ago
  To me, Rust is like C++, Go is like C. Rust loves zero cost abstractions, and isn't afraid to be complicated. It gives the programmer as much power as possible. Go is simple and actually very fast. The garbage collector is probably the biggest hurdle for performance and it's still best in class. Definitely higher level than C, but not enormously so.
  - cies 9y ago
    > Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that corner. Go obviously isn't.
    - jchw 9y ago
      >C was also king of the zero cost abstractions. C++ has static dispatch classes, templates, constexpr, and macros. C just has macros. Any other abstraction costs machine code. C++ also offers a lot of low cost abstraction like RAII-style scoping. >C sure is not afraid to be complicated. Not sure in what sense you're talking. C is not complicated. It's low level. It's exposing complications in the underlying model of a computer. Example: pointers in C are not complicated. Understanding how they work may be for beginners, but that just reflects how hard it is to understand what's going on in a computer. C is accidentally complicated where it is flawed; the non-orthogonal behavior with arrays and the syntax for function pointers are examples. Go fixes some of these flaws, which is unsurprising since it was informed by people close to the origins of UNIX and C (y'know, like, Rob Pike?) >I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). Sounds a lot like C++. It isn't accidental or coincidental that it is a favorite for high performance but complicated stuff like game and browser development. This is no surprise since Mozilla wrote it to replace usages of C++ for memory safety and concurrency, not because C++ didn't offer enough. C++ is flawed in ways Rust isnt, but that doesn't mean the two don't share a lot of traits, and it was Not by accident. Complexity is one of them. >C, C++, Rust are all in that corner. > >Go obviously isn't. Since you've offered no reasons for why this would be true, I can't actually refute it. But it doesn't make a ton of sense. Go and Rust both let you shoot yourself in the foot literally as much as you want. Go directly facilitates assembly code and allows direct memory access with unsafe. Rust also does this. Go tries to be memory safe and provide concurrency primitives. Rust goes about this in a different way. I don't see where they significantly differ. Rust differs most in it's superior memory safety model and low cost abstractions. Go differs most in it's simplicity and built-in concurrency. But they both feel close to their own origins.