Earlier quoted context omitted.
I would contend that java should be considerably lower on the fun scale. Maybe they are counting other languages that target the JVM? Also perl is apparently as fun for humans python which I also find suspect after maintaining perl 5.x code. Turns out this subjective made up graph is subjective and made up I guess.
> Also perl is apparently as fun for humans python which I also find suspect after maintaining perl 5.x code. When people talk about a language being 'fun', they need to distinguish between writing something new for the first time vs maintaining something or figuring out someone else's code.
Program your next server in Go
221–230 of 384 posts
Re: Program your next server in Go
#222I can't help but think this is specifically a dig in C++'s direction. Since C++11 lambda's I've been using a lot more and I don't think you could get me to go back at this point... Yes I had to learn exactly what a few methods do, but now I have beautiful straight line code...
Re: Program your next server in Go
#223Earlier quoted context omitted.
I've been writing Go daily for almost two years now and outside of wishing for generics a few times I've never struggled to fit a solution into the type system. I've certainly never considered going back to a duck typed language like Python or Ruby. Not once. Not ever. We have slowly replaced even our glue scripts that are written in Python with Go versions because maintenance and understandability trump any perceive…
As soon as a system reaches a given size, not having static types becomes unwieldy. Go's type system is great. Though my code still uses the var type declarations.
To me, the power of Go's simplicity is almost always underestimated by the language's detractors. I can look at code my team wrote two years ago and with a few gd's in Vim I know what's going on. Obviously Python fails this test, but even a high-level static typed language like C# can suffer greatly from all the magic one can invoke (Linq being a great example).
What it comes down to is that Go doesn't give you many ways to be clever. Younger me who loved template metaprogramming in C++ would scoff at this statement, but if you go back and have to reverse engineer your own cleverness enough times you really, really start to dislike the practice.
Re: Program your next server in Go
#224Earlier quoted context omitted.
I think it refers to the Perl-era idea that good code should be somehow "clever" rather than maintainable. It's how bad programmers who spend hours agonizing over how to reduce their line count (presumably to save disk space?) justify their behavior.
Personally, I think "cowboy coding" is the best derogatory name for this. IMO, what all of these ninjas have in common is that they don't realize that software development is a team exercise. Berkeley did a study on BSD and found that a file was opened 10x more often for reading that writing (i.e. people read code 10 times for every time they make a change). To my mind, "cowboy" conveys the proper amount of ignorance…
Re: Program your next server in Go
#225Earlier quoted context omitted.
We've been running splice.com on Go for 3 years now and handle 5TB of audio/binary data per day. Our memory usage is around 10-15MB per server and the GC pause time has been really low. You do need to stream your IOs instead of reading everything in memory. In regards to dependency management, we honestly had no issues and now with vendoring, it's even easier. We do use a main repo with lots of smaller packages and o…
Could you elaborate on what you mean by stream your IO? Is this just using buffered io it is there a concept I could read up on here?
Re: Program your next server in Go
#226We used Go at Hailo for our microservices platform and it served us incredibly well. I've gone on to create an open source project called Micro https://github.com/micro/micro that builds on those past experiences. It's just a joy to write micro services in Go.
Re: Program your next server in Go
#227I'd love to see Nim on this diagram: https://talks.golang.org/2016/applicative.slide#13 - it could be close to the top right corner.
The go devs are very careful to avoid mention of all the other languages that compete in the same space and are significantly better.
Re: Program your next server in Go
#228Earlier quoted context omitted.
The instructions are literally at the bottom of the first slide.
Oh didn't realize i had to read things to learn how to navigate things. Cool UX bro.
Re: Program your next server in Go
#229Earlier quoted context omitted.
So as someone who's written some Go, I'd argue that Go is the screwdriver - it's one of the only modern languages which explicitly refuses to tackle the error handling problem, which has resulted in some of my code being more about the failure case than the success case. Of course, others will disagree - fine. But to argue that e.g. Java is definitely the screwdriver is a subjective judgement.
To add to this: Go's inexpressivity (hi, generics!) makes common patterns that I see in Kotlin, Java, and Scala (as well as Rust, off-JVM) makes error handling a complete bear , to the point where my eyebrows are really raised at vertex-four being downvoted for this. The use of please-check-this error conditions instead of something like a Try (Result in Rust) and an inability to just map over these as 0- or 1-elemen…
Re: Program your next server in Go
#230Earlier quoted context omitted.
> We continue to use Go because of its strengths, but it just really surprises me how little Google seems to care about the language and ecosystem. Go is certainly a language that is used at Google, but AFAIK a lot of "Googlers" don't really like it and don't use it. It certainly not the "official language at Google", given the weight of C++ and Java there. But that's the consequence of being opinionated. Using Go me…
>> given the weight of C++ and Java there. Python as well. >> how little Google seems to care about the language and ecosystem Let's compare with Microsoft. The top four out of five users at StackOverFlow have top tags in C#, I guess Google have a long way to Go.