4 ms·

As have already been pointed out most of these points ARE being addressed by the Go community, but it kinda reminded why I look towards Go 2.0 with some dread.

As have already been pointed out most of these points ARE being addressed by the Go community, but it kinda reminded why I look towards Go 2.0 with some dread. Most of these things that he is asking for are things that will make the language harder to read, Generics and Exceptions (and not least this weird chimera that they have come up with in to Go 2 proposal last time I checked), will undoubtedly create popular libraries, which are almost impossible to understand for the uninitialised. The main strengths of Go is that it's easy to pick up for almost anyone with basic programming skills and be productive. The rigidity of the style, and the relative simplicity means that I can get a very fair idea about how almost any 3rd party library on Github works in an hour, and probably tweak the bits I may need to tweak. (The obvious exception to this is any library using a lot of reflection which can fulfill anyone's deepest desires to make code unreadable). C++ (which is my other main work language), have all these advanced features (often added in haphazard fashion late in the language specs), and I love writing C++ code, but I dread looking at other peoples code, because it can be almost impossible to figure out what is going on. I am tempted, when I see all these complaints about Go and comparing them to languages with different feature sets, to tell people that in that case they should use those. Of course, you might have the language dictated by an employer, but in that case there was probably a rationale behind choosing Go, and trying to change the language into being a clone of every other language will probably just result in someone else coming up with a new simple, statically typed compiled language, because I honestly believe the world needs that.

dnautics 8y ago
> The main strengths of Go is that it's easy to pick up for almost anyone with basic programming skills and be productive. This is passed around like gospel, but as a counterpoint my intern started this week at 30 hours a week. I taught him elixir from scratch, and today he finished writing a web server that serves GET and POST requests (which he didn't know) and stores states correctly. Also with low touch; he did much of the documentation reading himself and I was able to finish up about 1500 lines of code for a demo tomorrow. I feel like pretty much all modern languages except maybe rust are reasonably easy to pick up.
- spicyusername 8y ago
  > I taught him elixir from scratch, and today he finished writing a web server that serves GET and POST requests This is an anecdotal sample size of 1. If something is "gospel" there is usually a real truth behind it that one should try to understand. > I feel like pretty much all modern languages except maybe rust are reasonably easy to pick up Simply not true for most of the industry. Perhaps in some corners of the silicon valley monoculture machine, but most of software engineering is comprised of a diverse range of people with diverse backgrounds and skill sets for which mastering a new programming language is time consuming.
  - deleted 8y ago
    [deleted]
- eitland 8y ago
  Hehe, I haven't tried Elixir, so I cannot say. FWIW I taught a 16 y.o. intern enough perl and vba to automate what was a very non trivial reporting job. He did it in 14 days, after hours only (attending school at week days) and he only asked me a few times. Doesn't mean I'll say perl is easy (I cannot even understand my own perl code from back then anymore), only I got a really really bright intern. It might be the same in your case but I obviously cannot say for sure since I've never programmed Elixir or met your intern :-)
xg15 8y ago
> ... often added in haphazard fashion late in the language specs Agreeing with this point. I feel, there seems to be a vicious cycle in "pragmatic" language design that goes something like this: 1) Let's design language n. It will be like language n-1 in spirit but much more lightweight and without all the historical baggage! 2) In particular, let's leave out generics. They have been a never-ending source of bugs and confusion in n-1 development, with all the gotchas and awkward special cases you need to remember - and we can't really think of any compelling real-world use-cases for them anyway... (... some years later ...) 3) Sigh... the community keeps pestering us about generics... so alright, we'll think about some way to add generics to the language so you guys finally stop complaining. 4) Behold: We made n', a language extension to n with generics. However, because all of our existing ecosystem is written in the old way, without generics, we had to prioritize backwards compatibility over all else during the design. That's why you'll have to live with counter-intuitive behavior A, awkward special case B and arbitrary-looking restriction C when using them. We're sorry, guys! 5) Let's design language n+1. It will be like language n in spirit but much more lightweight and without all the historical baggage! Especially generics! How about for a change designing a language where generics are part of the initial design instead of just getting bolted on later?
- SideburnsOfDoom 8y ago
  > How about for a change designing a language where generics are part of the initial design instead of just getting bolted on later? Muttering about Rust at this point. Exactly. Generics being there from the get-go makes a difference to the language design. The most visible example being how values are returned from functions, when the result is tuple return for success case or error case. Bolting that on later is unlikely to work well. https://doc.rust-lang.org/std/result/ https://doc.rust-lang.org/std/result/
- eitland 8y ago
  Well, C# and TypeScript both seems to have gotten a whole lot more right (I'll cut TypesScript some extra slack here since it has to take extra care not to step on JavaScripts toes now or in the future.)

dnautics 8y ago

> The main strengths of Go is that it's easy to pick up for almost anyone with basic programming skills and be productive. This is passed around like gospel, but as a counterpoint my intern started this week at 30 hours a week. I taught him elixir from scratch, and today he finished writing a web server that serves GET and POST requests (which he didn't know) and stores states correctly. Also with low touch; he did much of the documentation reading himself and I was able to finish up about 1500 lines of code for a demo tomorrow. I feel like pretty much all modern languages except maybe rust are reasonably easy to pick up.

spicyusername 8y ago
> I taught him elixir from scratch, and today he finished writing a web server that serves GET and POST requests This is an anecdotal sample size of 1. If something is "gospel" there is usually a real truth behind it that one should try to understand. > I feel like pretty much all modern languages except maybe rust are reasonably easy to pick up Simply not true for most of the industry. Perhaps in some corners of the silicon valley monoculture machine, but most of software engineering is comprised of a diverse range of people with diverse backgrounds and skill sets for which mastering a new programming language is time consuming.
- deleted 8y ago
  [deleted]
eitland 8y ago
Hehe, I haven't tried Elixir, so I cannot say. FWIW I taught a 16 y.o. intern enough perl and vba to automate what was a very non trivial reporting job. He did it in 14 days, after hours only (attending school at week days) and he only asked me a few times. Doesn't mean I'll say perl is easy (I cannot even understand my own perl code from back then anymore), only I got a really really bright intern. It might be the same in your case but I obviously cannot say for sure since I've never programmed Elixir or met your intern :-)

xg15 8y ago

> ... often added in haphazard fashion late in the language specs Agreeing with this point. I feel, there seems to be a vicious cycle in "pragmatic" language design that goes something like this: 1) Let's design language n. It will be like language n-1 in spirit but much more lightweight and without all the historical baggage! 2) In particular, let's leave out generics. They have been a never-ending source of bugs and confusion in n-1 development, with all the gotchas and awkward special cases you need to remember - and we can't really think of any compelling real-world use-cases for them anyway... (... some years later ...) 3) Sigh... the community keeps pestering us about generics... so alright, we'll think about some way to add generics to the language so you guys finally stop complaining. 4) Behold: We made n', a language extension to n with generics. However, because all of our existing ecosystem is written in the old way, without generics, we had to prioritize backwards compatibility over all else during the design. That's why you'll have to live with counter-intuitive behavior A, awkward special case B and arbitrary-looking restriction C when using them. We're sorry, guys! 5) Let's design language n+1. It will be like language n in spirit but much more lightweight and without all the historical baggage! Especially generics! How about for a change designing a language where generics are part of the initial design instead of just getting bolted on later?

SideburnsOfDoom 8y ago
> How about for a change designing a language where generics are part of the initial design instead of just getting bolted on later? Muttering about Rust at this point. Exactly. Generics being there from the get-go makes a difference to the language design. The most visible example being how values are returned from functions, when the result is tuple return for success case or error case. Bolting that on later is unlikely to work well. https://doc.rust-lang.org/std/result/ https://doc.rust-lang.org/std/result/
eitland 8y ago
Well, C# and TypeScript both seems to have gotten a whole lot more right (I'll cut TypesScript some extra slack here since it has to take extra care not to step on JavaScripts toes now or in the future.)