4 ms·

You make a fair point and I totally respect your opinion. I was ultimately looking for a versatile language that I could use for my personal projects outside o

You make a fair point and I totally respect your opinion. I was ultimately looking for a versatile language that I could use for my personal projects outside of work and thus I was indeed trying to find a single language that could do everything I wanted. Up until this point, that language has been Python. Go is clearly sufficient for many very successful and amazing projects (many of which I use daily, like Hugo, Terraform, Docker .etc), so developers can still produce excellent tools with its limitations. But in saying that, the language is not for me, and that's okay; if it works for someone else, then that's okay too. Go does lack various features that many developers want, including me. Fun fact, the blog post was generated by Hugo ... which is written in Go :) With regards to Nim, yes, my experience with Nim is limited and I am still hoping to learn it further and do a more thorough evaluation. Hopefully I'll spend a good amount of time with Nim in the future to give it more of a fair go.

fileeditview 8y ago
> Go [...], so developers can still produce excellent tools with its limitations. I really found "still" to be funny because I think for many Go devs (including me) the simplicity and lack of features especially enables us to create more easily. It's the opposite of standing in front of giant fridge shelves in the supermarket with 100+ kinds of yoghurt where you have a hard time deciding. You only have a few choices so you just go ahead and pick one/just do it. Forgive my bad analogy.
- fgimian 8y ago
  Totally fair point. Minimalism can be extremely liberating and in fact, it's something I apply to many other areas of my life. But when it came to Go, I personally found myself battling the language as a result, rather than being more productive with it. Ultimately if it makes you more productive, then that's awesome and that's all that matters.
- pjmlp 8y ago
  I program since 1986, had lots of fun around 1995 using Oberon system, one of Go's influences. So naturally I used many programming languages with Go's limited set of features, which doesn't mean I want to return to those days.
  - fileeditview 8y ago
    I'm not sure what your point is.. is it: "More features are better"? I started programming a few years later than you.. first on Atari ST (Basic) then later in DOS (Pascal). I often wish myself back to these systems when I see today's bloated stacks of crap (obviously this does not apply to everything). I don't think this is relevant for the original discussion though..
    - pjmlp 8y ago
      My point is ignoring features largely proven in mainstream languages is bad. Even the last version of Turbo Pascal for MS-DOS (7.0) was more feature rich, ignoring the lack of GC for a moment.
      - sriram_malhar 8y ago
        Wut?
        flavio81 8y ago
        What he said. Turbo Pascal 7 a better designed language than Go, for the most part.
        sriram_malhar 8y ago
        I'd like an example or two.
        pjmlp 8y ago
        Enumerations in Turbo Pascal type Colours = (Red, White, Blue); Enumerations in Go type Colours int const ( Red Colours = iota White Blue ) FFI in Turbo Pascal function Sin(const num: Integer): Double; external 'ext name'; FFI in Go (requires external help from a C compiler) // #include <stdio.h> // #include <errno.h> import "C" func Sin (num uint) float32 { return C.sin } Reference parameters in Turbo Pascal with null safety thanks type system procedure Swap(var a,b:Integer); var temp: Integer; begin temp:=a; a:=b; b:=temp end; Swap(x, y) Swap(nil, y) { compiler error: Got "Pointer" expected "SmallInt" } Reference parameters in Go (no type safety via type system, manual testing for nil required) func Swap (a *int, b*int) { var temp = *a *a = *b *b = temp } Swap(&x, &y) Swap(nil, &y) { runtime error: Invalid memory address or nil pointer dereference } I was also tempted to move the time scale from 1992 to 2009, but then I wouldn't be able to reproduce the generics from Object Pascal in Go. Ah, and Turbo Pascal 5.5 was compiling around 34 000 lines/minute in computers whose CPUs were maxed at about 30 MHZ, http://edn.embarcadero.com/article/20803 http://edn.embarcadero.com/article/20803
- patchguard 8y ago
  Assembly also lacks features.
- flavio81 8y ago
  >I really found "still" to be funny because I think for many Go devs (including me) the simplicity and lack of features especially enables us to create more easily. Yeah man, it must be so fun doing large-scale construction work with just a hammer and a shovel; so easy to use, so easy to learn. Who needs caterpillars, pneumatic drills and such. Last time I checked, Brainfuck is easier to learn than Go (more simplicity!!!, and runs in even more platforms.
  - ecnahc515 8y ago
    The Amish manage to build large barns entirely like this in much less time than it would take the average construction firm. It depends heavily on what you're building on if you actually need a lot of those tools. Just like if you're building a small tool to wrap another you might just choose to use bash over Java, it all comes down to what you need most commonly vs what would "be nice to have".
    - flavio81 8y ago
      >>large-scale construction work >build large barns entirely Not the same 'large-scale' construction work I had in mind.
  - deleted 8y ago
    [deleted]
  - fileeditview 8y ago
    Your reply seems a little emotional.. I wonder why. Nobody is forcing Go on you. You can do all large-scale construction work with greater tools like Lisp or Haskell as it is commonly done. I don't agree that Go has only "a hammer and a shovel". It has at least a saw in its toolbox too. On a more serious note.. fun is highly subjective and the brainfuck / simplicity argument is just useless.
kodablah 8y ago
I personally recommend choosing the language after you know the personal project you'll be working on. For instance, I hate Go's lack of expressiveness but ended up choosing it for a personal project due to the strength of its crypto libraries. Also, if you can spare the time, creating full blown, open projects in languages can help your well-roundedness. My comment was meant to be less about Go and more about dismissing languages outright. I'm hoping the next post is about how awesome Crystal is sans unfamiliarity of other options.

fileeditview 8y ago

> Go [...], so developers can still produce excellent tools with its limitations. I really found "still" to be funny because I think for many Go devs (including me) the simplicity and lack of features especially enables us to create more easily. It's the opposite of standing in front of giant fridge shelves in the supermarket with 100+ kinds of yoghurt where you have a hard time deciding. You only have a few choices so you just go ahead and pick one/just do it. Forgive my bad analogy.

fgimian 8y ago
Totally fair point. Minimalism can be extremely liberating and in fact, it's something I apply to many other areas of my life. But when it came to Go, I personally found myself battling the language as a result, rather than being more productive with it. Ultimately if it makes you more productive, then that's awesome and that's all that matters.
pjmlp 8y ago
I program since 1986, had lots of fun around 1995 using Oberon system, one of Go's influences. So naturally I used many programming languages with Go's limited set of features, which doesn't mean I want to return to those days.
- fileeditview 8y ago
  I'm not sure what your point is.. is it: "More features are better"? I started programming a few years later than you.. first on Atari ST (Basic) then later in DOS (Pascal). I often wish myself back to these systems when I see today's bloated stacks of crap (obviously this does not apply to everything). I don't think this is relevant for the original discussion though..
  - pjmlp 8y ago
    My point is ignoring features largely proven in mainstream languages is bad. Even the last version of Turbo Pascal for MS-DOS (7.0) was more feature rich, ignoring the lack of GC for a moment.
    - sriram_malhar 8y ago
      Wut?
      - flavio81 8y ago
        What he said. Turbo Pascal 7 a better designed language than Go, for the most part.
        sriram_malhar 8y ago
        I'd like an example or two.
        pjmlp 8y ago
        Enumerations in Turbo Pascal type Colours = (Red, White, Blue); Enumerations in Go type Colours int const ( Red Colours = iota White Blue ) FFI in Turbo Pascal function Sin(const num: Integer): Double; external 'ext name'; FFI in Go (requires external help from a C compiler) // #include <stdio.h> // #include <errno.h> import "C" func Sin (num uint) float32 { return C.sin } Reference parameters in Turbo Pascal with null safety thanks type system procedure Swap(var a,b:Integer); var temp: Integer; begin temp:=a; a:=b; b:=temp end; Swap(x, y) Swap(nil, y) { compiler error: Got "Pointer" expected "SmallInt" } Reference parameters in Go (no type safety via type system, manual testing for nil required) func Swap (a *int, b*int) { var temp = *a *a = *b *b = temp } Swap(&x, &y) Swap(nil, &y) { runtime error: Invalid memory address or nil pointer dereference } I was also tempted to move the time scale from 1992 to 2009, but then I wouldn't be able to reproduce the generics from Object Pascal in Go. Ah, and Turbo Pascal 5.5 was compiling around 34 000 lines/minute in computers whose CPUs were maxed at about 30 MHZ, http://edn.embarcadero.com/article/20803 http://edn.embarcadero.com/article/20803
patchguard 8y ago
Assembly also lacks features.
flavio81 8y ago
>I really found "still" to be funny because I think for many Go devs (including me) the simplicity and lack of features especially enables us to create more easily. Yeah man, it must be so fun doing large-scale construction work with just a hammer and a shovel; so easy to use, so easy to learn. Who needs caterpillars, pneumatic drills and such. Last time I checked, Brainfuck is easier to learn than Go (more simplicity!!!, and runs in even more platforms.
- ecnahc515 8y ago
  The Amish manage to build large barns entirely like this in much less time than it would take the average construction firm. It depends heavily on what you're building on if you actually need a lot of those tools. Just like if you're building a small tool to wrap another you might just choose to use bash over Java, it all comes down to what you need most commonly vs what would "be nice to have".
  - flavio81 8y ago
    >>large-scale construction work >build large barns entirely Not the same 'large-scale' construction work I had in mind.
- deleted 8y ago
  [deleted]
- fileeditview 8y ago
  Your reply seems a little emotional.. I wonder why. Nobody is forcing Go on you. You can do all large-scale construction work with greater tools like Lisp or Haskell as it is commonly done. I don't agree that Go has only "a hammer and a shovel". It has at least a saw in its toolbox too. On a more serious note.. fun is highly subjective and the brainfuck / simplicity argument is just useless.

kodablah 8y ago

I personally recommend choosing the language after you know the personal project you'll be working on. For instance, I hate Go's lack of expressiveness but ended up choosing it for a personal project due to the strength of its crypto libraries. Also, if you can spare the time, creating full blown, open projects in languages can help your well-roundedness. My comment was meant to be less about Go and more about dismissing languages outright. I'm hoping the next post is about how awesome Crystal is sans unfamiliarity of other options.