From the very first item:
> Idiomatic Go uses shorter names like u, but I stopped using one-letter variables 35 years ago when I left TRS-80 Basic behind.
Ignorant snobbery. Skip.
Why I Don't Like Golang (2016)
161–170 of 297 posts
Re: Why I Don't Like Golang (2016)
#162Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in…
Can't say I got that feeling at all. Smalltalk is a tight design. So is Lisp. So is Forth. So is APL. C's design just feels like a pile of... stuff. Arrays are almost but not quite the same as pointers. You can pass functions but not return them. There's a random grab-bag of control flow keywords, too many operators with their own precedence rules, and too many keywords given over to a smorgasbord of different intege…
C makes more sense if you read Ken Thompson's B manual.
Re: Why I Don't Like Golang (2016)
#163I created a new language [0] that is very similar to Go, but it fixes many things people often complain about, including all of the points in this article (except #2, but I don't think it's a drawback, really). It got lots of attention in a couple of months since the public release, and I often hear people say that they feel like this is "Go done right". It'll be open sourced by June 20. [0]: https://vlang.io
Options :) But generics :(
I'm really hopping that Golang finds a way to either not add generics, or add them in contrained ways. Your example code for generics are very hard to read for example.
Rust somehow tackles that with associated types, but since generics are still allowed it's not great imo.
Re: Why I Don't Like Golang (2016)
#164Earlier quoted context omitted.
Interesting. Do you have links? Or maybe a short summary why this is bad?
It becomes very annoying and tedious to refactor when you need to change visibility. Suddenly, a single line change (e.g. changing private to public) needs an IDE to refactor it and make sure it gets all instances (which is quite ironic given that golang proponents generally shun IDEs). Now depending on how many instances changed, you would need to split up your diff for readability, or clutter your diff with needles…
> a single line change (e.g. changing private to public) needs an IDE to refactor it
the language comes with a rewriting tool that rewrites arbitrary expressions.
gofmt -w -r 'thing -> Thing' *.go
Re: Why I Don't Like Golang (2016)
#165Earlier quoted context omitted.
Same here, people can complain but the reality is that more and more people find Golang a great language to use day-to-day. Honestly I think it's here to replace Java and to stay. Same as Rust replaced C and C++. That anyone would want to write C/C++ or Java today is absurd, except if they're old.
These are still very niche languages. Go has a better shot, albeit still long, with the weight of Google behind it, but there is an unbelievable amount of inertia. Rust certainly hasn't replaced C/C++ to any real degree yet. Maybe time will tell, but I'd lay money that there will be a lot of people still working on C, C++ and Java codebases in fifty years, just like there is a boatload of COBOL and even MUMPS softwar…
I'm not saying that these languages have replaced their older versions, but that one would be crazy if given the choice to choose to do Java/C/C++ for work :)
Re: Why I Don't Like Golang (2016)
#166Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in…
K&R C didn't have ‘undefined behaviour’, and I've become convinced that the original ANSI committee didn't intend to create the monster they did.
The reason is that Dennis Ritchie wrote a submission to the committee¹ that described the ‘noalias’ proposal as “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs”, and, that “[i]t negates every brave promise X3J11 ever made about codifying existing practices, preserving the existing body of code, and keeping (dare I say it?) ‘the spirit of C.’”
Those comments describe what ‘undefined behaviour’ turned in to. The only reason dmr and others didn't make the same objections to it is that nobody realized at the time what the committee wording implied.
¹ available here: https://www.lysator.liu.se/c/dmr-on-noalias.html
Re: Why I Don't Like Golang (2016)
#167Earlier quoted context omitted.
I just started digging into C a few years ago and was struck by the same. It's amazingly simple and the only "flaw" that leaps out at me is the precedence of & and | being higher than comparison operators. Other than that, and maybe the macro system, everything frustrating about learning it was due to the frustration of dealing with the machine rather than anything C itself imposed on me.
I love C, but it's biggest mistake is clearly the unstoppable decay of arrays to pointers: https://www.digitalmars.com/articles/b44.html A mistake that C++ missed an opportunity to fix.
Arrays are for FORTRAN is I think the reason.
Re: Why I Don't Like Golang (2016)
#168Earlier quoted context omitted.
Can't say I got that feeling at all. Smalltalk is a tight design. So is Lisp. So is Forth. So is APL. C's design just feels like a pile of... stuff. Arrays are almost but not quite the same as pointers. You can pass functions but not return them. There's a random grab-bag of control flow keywords, too many operators with their own precedence rules, and too many keywords given over to a smorgasbord of different intege…
FYI: 2am possible rambling on design and software Funny, I got the same feeling from Smalltalk and Lisp. I own both "Common Lisp: The Language" and "Smalltalk-80: The Language and its Implementation", and while there are many ways those languages could be described as 'tight' (tightly-coupled, perhaps), at no point can you look at the C language and say "This could be smaller" without significantly removing functiona…
I agree with you, but perhaps you are reading “tight” slightly differently than the way the original poster intended it?
To me, ANSI C is “tight” in the sense that it is made up of a small set of features, which can be used together to get a lot done. But the design of the features, as they relate to each other, can feel somewhat inelegant. Those different features aren’t unified by a Simple Big Idea in the way that they are in Lisp or Smalltalk.
Lisp and Smalltalk, then, have “tight” designs (everything is an s-expression/everything is an object) which result in minimal, consistent semantics. But they also have kitchen sink standard libraries that can be challenging to learn.
(Although to be fair, Smalltalk (and maybe Common Lisp to a lesser extent) was envisioned as effectively your whole OS, and arguably it is a “tighter” OS + dev environment than Unix + C...)
FWIW, I am learning Scheme because it seems to be “tight” in both senses.
Re: Why I Don't Like Golang (2016)
#169Earlier quoted context omitted.
> The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. "const" as well (back ported from C++ ?). And being able to declare variables anywhere (instead of just at the beginning of a block)
Interestingly, the high level language you implement for the nand2tetris course has this constraint, which makes writing the compiler easier
I took that course, too! I loved it. Learned more about computers than any other of the many courses I took.
Re: Why I Don't Like Golang (2016)
#170Earlier quoted context omitted.
It becomes very annoying and tedious to refactor when you need to change visibility. Suddenly, a single line change (e.g. changing private to public) needs an IDE to refactor it and make sure it gets all instances (which is quite ironic given that golang proponents generally shun IDEs). Now depending on how many instances changed, you would need to split up your diff for readability, or clutter your diff with needles…
> a single line change (e.g. changing private to public) needs an IDE to refactor it the language comes with a rewriting tool that rewrites arbitrary expressions. gofmt -w -r 'thing -> Thing' *.go
Still more and unnecessary effort compared to changing one word.