I'm looking forward to my first project with GO. It appears to offer a lot with minimal complexity. > Because Go has so little magic, I think this was easier than it would have been in other languages. You don’t have the magic that other languages have that can make seemingly simple lines of code have unexpected functionality. You never have to ask “how does this work?”, because it’s just plain old Go code. That lack…
> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.
3.5 Years, 500k Lines of Go
91–100 of 249 posts
Re: 3.5 Years, 500k Lines of Go
#92This entire piece sounds like the Blub Paradox made real. http://paulgraham.com/avg.html It's written with knocking down a very specific set of straw men in mind, but rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. One of the things that's most irritating about Go enthusiasts is the way they try to close ranks on legitimate critique and reframe their language…
The "criticisms of Go are addressed every time the language is discussed: in practice, generics are rarely missed. They would be nice to have, but their absence is outweighed by other benefits of the language.
Critiques of Go tend to be principal-based: "Go doesn't have features X, Y, and Z, therefore it cannot be a good language. QED." Praise of Go, on the other hand, tends to be pragmatic: "We built something in Go, features X, Y, and Z weren't missed and we enjoyed features A, B, and C, which the language's detractors oddly refuse to acknowledge." Which view carries more weight is left up to the reader.
> http://paulgraham.com/avg.html
I know this is heresy, but has this article really held up well over time? Since 1995, when ViaWeb was founded, how many other companies have been able to run rings around their competitors by using Lisp or something similar? Are we really going to base our arguments on a sample size of 1? How many counterexamples are there?
Re: 3.5 Years, 500k Lines of Go
#93Earlier quoted context omitted.
If they came from any scripting language they probably have never worked with generics -- that doesn't really strike me as an outlandish scenario.l
Ask a dynamic language enthusiast about that. Dynamic languages don't have "proper generics" but what they do have is all the generic use cases covered... so... which is more important, having a particular feature, or being able to do all the things that the feature can do? A generic enthusiast can argue that the type safety is a fundamental difference. A dynamic language enthusiast is obviously going to take issue w…
Well, the "things that the feature can do" in a dynamic language you can do in Go with interface{}.
It's the one thing you can't do (in Go or a dynamic language) that Generics are all about: type-safe generic code.
So, you'd made the parents case for them...
Re: 3.5 Years, 500k Lines of Go
#94Off topic rant: I don't know much about the details of godeps hash file but I do wish that there were a better infrastructure for merging contents of various file formats. Built into git or shipped as a separate repository. I wasted too much time merging vcxproj.filters files just because in its XML representation one item of a sequence of folder assignments occupies 3 lines (opening tag, contents, closing tag) inste…
I found a program someone wrote called sortxml that will prettify and sort XML files. It's written C#. Might be possible to run it on Linux also, or to find another similar program for Linux that will. I'd investigate further if it wasn't for the fact that I rarely work with XML files. https://github.com/kodybrown/sortxml You may be able to write a small wrapper script that does the following: For each filename passe…
mkdir -p ~/tmp/xml-merge-example
cd !$
git init .
cat > example.xml
EOF
git add .
git commit -m "Initial commit."
git checkout -b alternate-reality
cat > example.xml
EOF
git add .
git commit -m "Alternate reality."
git checkout master
sed -i '' -e 's/hello/foo/' -e 's/world/bar/' example.xml
git add .
git commit -m "Hello foo to the world bar."
git merge alternate-reality
The attempted merge will result in the following: Auto-merging example.xml
CONFLICT (content): Merge conflict in example.xml
Automatic merge failed; fix conflicts and then commit the result.
For a quick PoC, let's create a little script that will echo the arguments that was passed to it and then exit with failure. The real script would work as outlined in the parent comment and would exit with success at the end as long as the merge worked out.The t argument to mergetool works a bit different than I thought, but not by much -- the tool must be referenced by name and the corresponding mergetool..cmd must have been set. In the command you use the variables $BASE, $LOCAL, $REMOTE and $MERGED as explained in https://git-scm.com/docs/git-mergetool#git-mergetool--tlttoo... . This allows tools with different argument ordering, flags and such to be used.
Let's write the PoC script
mkdir -p ~/bin
cat >~/bin/mergepoc.bash &2
echo "$0: INFO: Arguments: $@" 1>&2
exit 1
EOF
chmod 755 ~/bin/mergepoc.bash
and define the mergetool cmd git config mergetool.mergepoc.cmd '~/bin/mergepoc.bash --base "$BASE" "$LOCAL" "$REMOTE" -o "$MERGED"'
and tell git to trust the exit status of this tool git config mergetool.mergepoc.trustExitCode true
Then we run it. git mergetool -t mergepoc example.xml
Result (with an additional line-break inserted in order for to avoid having the contents shown here scroll sideways): Merging:
example.xml
Normal merge conflict for 'example.xml':
{local}: modified file
{remote}: modified file
/home/erikn/bin/mergepoc.bash: WARN: Proof-of-Concept
/home/erikn/bin/mergepoc.bash: INFO: Arguments: --base ./example_BASE_4020.xml
./example_LOCAL_4020.xml ./example_REMOTE_4020.xml -o example.xml
merge of example.xml failed
Continue merging other unresolved paths [y/n]? nRe: 3.5 Years, 500k Lines of Go
#95Wait what? I thought this was solved ten years ago https://en.wikipedia.org/wiki/Path_(computing)#MS-DOS.2FMicr...
Re: 3.5 Years, 500k Lines of Go
#96Earlier quoted context omitted.
> I find Go's magical maps and slices Magical? What's magical about a hashmap or a pointer into an array? There are a lot of valid criticisms of Go; "magic" is not one of them.
Go has special syntax for channels, maps and slices. It's impossible to define your own data structures using the same syntax. An argument can be made for array subscripts, certainly, but why can't you use 'make' for your own code? They're also magic in that Go does have generics, but only for those three types.
Re: 3.5 Years, 500k Lines of Go
#97Earlier quoted context omitted.
Comparing 1.0's is a much better comparison, except in cases where there was huge adoption before 1.0.
I wouldn't say rust was hugely adopted before 1.0 (not that it's hugely adopted after, either).
For Go vs. Rust, I think a comparison of 1.0 releases is perfect.
Re: 3.5 Years, 500k Lines of Go
#98Earlier quoted context omitted.
functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods. I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.
Yeah, I guess some need to review the definition of abstraction.
Re: 3.5 Years, 500k Lines of Go
#99Earlier quoted context omitted.
So these will be made into functions with uncertain O complexity. How's this situation preferable?
When the programmer sees a function call they know its complexity is a O(?) and will (hopefully) vet it before calling it in a tight performance sensitive loop.
I get that someone could say "Go has fields, and they're always fast" and that seems like a great facility of the language, but any C# developer that says similar about instance members is wrong, and has some invalid assumptions about the language they use.
Re: 3.5 Years, 500k Lines of Go
#100Earlier quoted context omitted.
> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.
Example, properties in C# can be method calls, and while they appear to have the complexity of accessing a field they actually could be arbitrarily algorithmically complex. This leads to a programmer down the road, calling it in a tight look, expecting field access overhead and getting somones complex property-method-logic. That is an example of magic. IMHO magic is when the run or space time complexity of a code isn…
It looks like a simple for each loop, just like over a slice or map, but under the covers involves locking semantics.
If so, I guess I'll buy that definition of magic, I'm not sure thats any different than knowing what the language does.