Guaranteed you'll find use for Go in one system or the other when you want easy deployment, fast development time and extreme speeds. :)
(Disclaimer: I love Go and I hope it goes mainstream in a big way in 5 years)
In a few other languages:
// C++
sort(vs.begin(), vs.end(),
[](const string& l, const string& r) -> bool {
return l.size() < r.size();
});
# Python
vs.sort(key=lambda s: len(s))
There's plenty of other ways in which Go is shorter than the equivalent C++ (e.g. with type inference, or channel operations), but no-one's trying to claim that the shortest code wins.
sort(begin(vs), end(vs),
[](auto const& l, auto const& r) {
return l.size() < r.size();
});
Can any "idiomatic" Go programmers here give a better example of how you would do this?
vs.sort(key=len) L.sort(key=len)Making go-routines map to OS-level threads is a pain. And as much as I hate to trot out this old chestnut, the lack of generics is also a real pain.
I've gotten too used to having generic containers to go back, and the various hacks available just aren't worth it.
I still can't believe Go doesn't have some of the "basic" data types that older languages do such as Python's set() objects and the various operators.
That said, if was writing a small command-line utility for text manipulation or something else similar in scale that doesn't involve dealing with POSIX threading, I'd probably use it instead of Python, C, or C++.
Generics actually have very little to do with sorting a list in Go. The example that the parent gave could be expressed in one line as "sort.Sort(sort.Reverse(sort.StringSlice(vs)));" No generics needed-- only composition. sort.Reverse is a wrapper interface which can be composed with any other sort.Interface to reverse it. It is typesafe, too-- there are no typecasts.
There are cases where generics would allow us to avoid typecasts, but this is simply not one of them. In many cases, what you want can be expressed via composition of types, and often (in my opinion) in a clearer way than by using lambdas, continuations, and callbacks. I suggest learning a bit more about the language and keeping an open mind.
Turbo Pascal 5.5 was compiling 34,000 lines/minute in 1989 in MS-DOS systems!
http://edn.embarcadero.com/article/20803
Compared with module based languages, C and C++ toolchains have been always slower.
It helped me build this: https://github.com/joewalnes/websocketd/
Here is a search for Go repositories with > 100 stars.[1] Every project will look different (the really big ones might be more complex then you need) but as you get deeper into the results you can find some great stuff.
[1]: https://github.com/search?l=go&q=stars%3A%3E100&s=stars&type...
- Eggs should not be washed.
Since your folder structure is also your package structure, with rmux[1] I tried to separate the project into dependencies, and use a package for each one. I like to also limit files to one class--but if you read through the default package files, the creators seems to go both ways.
One interesting thing that isn't mentioned often is how to handle the equivalent of #ifdef, through +build flags. This isn't the best solution, since all functions and their arguments are evaluated (even empty functions), but it does allow for the use of constants to wrap around cpu-wasteful debug-only areas/
[1]: http://fitzgen.github.io/pocco/ [2]: http://jashkenas.github.io/docco/
What about freenode/#go-nuts? Seems like a very nice channel to me.
- Eggs should not be washed.