I enjoyed that the author readily admits to his own faults concerning Go too:
In this telling, the story of Go is really a tale of revenge, not just against slow builds, but against all kinds of sloppy programming. Which in my opinion is too bad, because I myself am a sloppy programmer.
This really does seem to be the approach I see with the Go digest mailing list. What I don't understand though is the ease of importing a library, say from Github. Interesting that the language from the author is all about how rigid and unforgiving Go is, yet "some guys" libraries can just be thrown into the mix in your program, and Go has no issues with this.
Go is developed inside Google where all dependencies are checked into their global version control repository. There are literally no versions inside the Google codebase - everything is compiled at head. If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project!
Given this background and the Go designers focus on Google's internal needs, it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)
> If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project!
The alternative is of course supporting dozens or hundreds of copies of a library and every possible commit hash of said library. I contracted at a python shop that had 81 versions of a single library in use all pinned at different versions. The reason I know this is that I had the great joy of dealing with upgrading all of them after a critical hole was not only discovered (the company knew about it for some time, but just didn't want to bother updating all those apps) but exploited... repeatedly.
> it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)
If by "fixed" you mean there are dozens of solutions to pin versions -- then yes. If you mean baked into the go tool, then no.
But - but! Saying that you want your org to use one version of a library at a time is one thing. Saying that you want your code to use the latest version of every library is another thing altogether, however, and that's what "no version for github code" does, right?
"One version per org" means "upgrades are harder, but patches are easier and you don't need to deal with different quirks of different versions at the same time and you don't get problems using 2 components that need 2 different versions of some other thing in one process etc."
"Latest version, always" means you have no way to even build the latest version of your thing that was tested and is known to compile and work. Kinda sucks, I think.
Yes, I didn't pass judgement on the approach. It works well enough for Google and avoids problems with e.g. ELF symbol conflicts. For development out on the open internet you do need some way to specify versions so it's a puzzling lack, but "if it works for Google it works for you" does seem to be a recurring theme in the Go design.
> Given this background and the Go designers focus on Google's internal needs
Does it mean the community isn't a priority? this vertical relationship between the Go team and the community could doom the language as fast as it was made popular, that's my opinion.That's a real issue.
That has always been the point of go. A better way of writing code the 'Google Way' It is really useful outside of that (I use it for everything other then video games), but it was always a language to help them get their work done faster.
This article really didn't get an objective analysis. The Scala language looks interesting, but the biggest "push" towards it was a graph of the job outlook, with the y axis at the scale of... .04? 4%? Is that supposed to convince me to use this in the industry, and apply my time?
I understand the article comes from scala-academy, but I think by offering a more objective viewpoint of different languages and the standards they impose, scala can show what niche they provide. I don't believe it is the niche of "Everyone is hiring a Scala programmer", but it should be (quoted from the article) "...implicits, underscore notation, flexible imports, multiple classes per file, multi-line strings, pattern matching, traits with variables, etc." If this article was about these points, with relations to other languages, that could be some quality content!
For everything else, either the article misrepresented other languages, or simply remained apathetic to their application.
"Is that supposed to convince me to use this in the industry, and apply my time?"
I say in the article:
«- Does this mean that I should use Scala?
Can you get a job you like programming Scala? If so, then: yes!
(Otherwise, unless you're rich, you need to pay your bills...)»
If don't think you can get a job programming Scala (because of where you live, or another reason) I explicitly say you shouldn't learn it! :)
But the rate at which Scala jobs are becoming available is relevant: I don't care if there are 200 Java jobs near me, as long as there are 3 or 4 Scala ones. As long as I have a Scala job, I don't care if the other companies are programming something else. If you can't get a Scala job - again: it's probably best to not even to take the time to learn it.
Wow! I just realized FreeBSD is about as old as I am! FreeBSD is a great system, and going from Windows to Ubuntu to FreeBSD was a fun transition, one I recommend for anybody willing to learn more about computers.
I saw a promotion for Design and Implementation of the FreeBSD Operating System, 2nd. ed this morning, in case anyone is considering purchasing the book. If you buy it direct from the publisher[1], there is a coupon code [2] for 35% off -- bringing the price down to a very reasonable $36.
Love the article. I'm a university student, bored with the lab and into coding SSRS reports as a job. Luckily, I enjoy my work, constantly fighting the SQL queries and arranging the datasets in ever complex fashions the client needs, or decide they want to change drastically.
I found though that my enjoyment in code is I like the challenges I face, not how I got there. I have tools in front of me, that may be good or may be bad, but it doesn't matter. Using these tools, learning some tricks, or asking (even helping) others is what I find enjoyable. I enjoy the code because I challenge myself. A client will give me a new task, but ultimately it's me who has accepted it. Make the best of it.
In this telling, the story of Go is really a tale of revenge, not just against slow builds, but against all kinds of sloppy programming. Which in my opinion is too bad, because I myself am a sloppy programmer.
This really does seem to be the approach I see with the Go digest mailing list. What I don't understand though is the ease of importing a library, say from Github. Interesting that the language from the author is all about how rigid and unforgiving Go is, yet "some guys" libraries can just be thrown into the mix in your program, and Go has no issues with this.