hodapp/blag
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Started restoring some old images & posts; changed themes to notepadium

Browse Source
This commit is contained in:
Chris Hodapp
2020-02-02 14:02:10 -05:00
parent 94f678534a
commit 7f98cee1da
84 changed files with 126 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
hugo_blag/content/posts/2018-04-13-opinions-go.org
View File

@@ -20,20 +20,21 @@ compilation, namespaces, multiple return values, packages, a mostly
sane build system, no C preprocessor, *minimal* object-oriented
support, interfaces, anonymous functions, and closures. Those aren't
trivialities; they're all rather great things. They're all missing in
C and C++ (for the most part). They're all such common problems that
nearly every "practical" C/C++ project uses a lot of ad-hoc solutions
sitting both inside and outside the language - libraries, abuse of
macros, more extensive code generation, lots of tooling, and a whole
lot of "best practices" slavishly followed - to try to solve them.
(No, I don't want to hear about how this lack of very basic features
is actually a feature. No, I don't want to hear about how
painstakingly fucking around with pointers is the hairshirt that we
all must wear if we wish for our software to achieve a greater state
of piety than is accessible to high-level languages. No, I don't want
to hear about how ~$arbitrary_abstraction_level~ is the level that
*real* programmers work at, any programmer who works above that level
is a loser, and any programmer who works below that level might as
well be building toasters. Shut up.)
C and C++ (for the most part - excluding that C++11 has started
incorporating some). They're all such common problems that nearly
every "practical" C/C++ project uses a lot of ad-hoc solutions sitting
both inside and outside the language - libraries, abuse of macros,
more extensive code generation, lots of tooling, and a whole lot of
"best practices" slavishly followed - to try to solve them. (No, I
don't want to hear about how this lack of very basic features is
actually a feature. No, I don't want to hear about how painstakingly
fucking around with pointers is the hairshirt that we all must wear if
we wish for our software to achieve a greater state of piety than is
accessible to high-level languages. No, I don't want to hear about
how ~$arbitrary_abstraction_level~ is the level that *real*
programmers work at, any programmer who works above that level is a
loser, and any programmer who works below that level might as well be
building toasters. Shut up.)
I'm a functional programming nerd. I just happen to also have a lot of
experience being knee-deep in C and C++ code. I'm looking at Go from
@@ -53,13 +54,12 @@ less transparently.
Concurrency was made a central aim in this language. If you've not
watched Rob Pike's [[https://blog.golang.org/concurrency-is-not-parallelism][Concurrency is not parallelism]] talk, go do it now.
While it's perhaps not my favorite approach to concurrency. While I
may not be a fan of the style of concurrency that it uses (based on
[[https://en.wikipedia.org/wiki/Communicating_sequential_processes][CSP]] rather than the more Erlang-ian message passing), this is still a
far superior style to the very popular concurrency paradigm of
Concurrency Is Easy, We'll Just Ignore It Now and Duct-Tape the
Support On Later. [[http://jordanorelli.com/post/31533769172/why-i-went-from-python-to-go-and-not-nodejs][Why I went from Python to Go (and not node.js)]], in
my opinion, is spot-on.
While I may not be a fan of the style of concurrency that it uses
(based on [[https://en.wikipedia.org/wiki/Communicating_sequential_processes][CSP]] rather than the more Erlang-ian message passing), this
is still a far superior style to the very popular concurrency paradigm
of Concurrency Is Easy, We'll Just Ignore It Now and Duct-Tape the
Support On Later, How Hard Could It Possibly Be. [[http://jordanorelli.com/post/31533769172/why-i-went-from-python-to-go-and-not-nodejs][Why I went from
Python to Go (and not node.js)]], in my opinion, is spot-on.
Many packages are available for it, and from all I've seen, they are
sensible packages - not [[https://www.reddit.com/r/programming/comments/4bjss2/an_11_line_npm_package_called_leftpad_with_only/][leftpad]]-style idiocy. I'm sure that if I look
@@ -92,7 +92,11 @@ system is also still very limited - particularly, things like the lack
of any parametric polymorphism. I'd probably prefer something more
like in [[https://www.rust-lang.org][Rust]]. I know this was largely intentional as well: Go was
designed for people who don't want a more powerful type system, but do
want types.
want types, and further, to support this kind of polymorphism involves
tradeoffs it looks like they were avoiding, like those Russ Cox gives
in [[https://research.swtch.com/generic][The Generic Dilemma]]. (Later note: the [[https://github.com/golang/proposal/blob/master/design/go2draft-contracts.md][Contracts - Draft Design]]
proposal for Go 2 offers a possible approach for parametric
polymorphism.)
My objections aren't unique. [[https://www.teamten.com/lawrence/writings/why-i-dont-like-go.html][Ten Reasons Why I Don't Like Golang]] and
[[http://yager.io/programming/go.html][Why Go Is Not Good]] have criticisms I can't really disagree with.