1,665 karma · joined August 6, 2011
In no world does "we expect that pace of change to accelerate" mean "we expect subtle refinement of the language". Refinement or polishing generally isn't something that "accelerates change".
Also, static binaries -- so the DevOps guys don't hit you with sticks.
I still remember the first go program README.md I shipped. "Umm, get foo to box, ./foo in a way so that it runs persistently and at startup."
Easy way to get your apps to the front of the line in the deploy queue -- all the time.
Go will continue to grow at the insane pace it has because it hit a sweet spot and cared about standard library and documentation. You will continue to see high profile successes because it doesn't try to be fancy, it tries to get out of your way so you can do that job of actually transforming data. So you can be a programmer and it can be a language, not a hobby.
I am a language geek, I write DSLs on a regular basis for fun -- and I love any language that is DSL friendly -- but for actually getting my day to day "must ship", "must work", "must scale" work done -- Go to the rescue. Great docs, easy to train people on, ultra-simple spec, multiple compilers, easy enough to integrate C code, and a really great vibrant community.
Go is 185175% better than Java and 8165% better than Haskell -- or making up numbers just makes us all look like goddamn idiots.
1. Download tar.gz (or zip) 2. Extract to <place> 3. export GOROOT=<place> 4. export GOPATH=<some_other_place>
... if you want to get fancy and make sure all your binaries are automatically in your path
5. export PATH=$PATH:$GOPATH/bin
... at this point setup is done, to build your first project using an external library
6. go get github.com/<user>/<library> 7. code, code, use <library>, zug, zug... save code in $GOPATH/src/<your_package> 8. go install <your_package> 9. $ <your_package> # runs it
this package can be shared because it is a static binary -- share with your friends, run on other servers, heck -- even cross-compile for other platforms with ease. Working on Linux -- but want to ship a utility to do X for a friend on Windows, no problem!
Lots of C++ "features" on banned on major projects because of complexity and build time issues -- templates, exceptions, operator overloading...
Or your favorite library author just likes nightlies, which effectively forces you to run nightlies to keep up with bug fixes if he isn't maintaining a separate branch (and who has time for that noise).
> What is the impending 1.0 release if not that? We've been very clear all along that 1.0 means language stability. I see no "hand-waving".
I guess I don't consider "stability" and "backwards compatibility" the same thing -- in the "stability as a deliverable" post, it was specifically referenced that rust will "continue to evolve at a rapid pace and even accelerate!" (quoted from memory, sure it is somewhat off).
I think a constantly growing language (no longer changing cause old code has to work, but growing... which seems worse) and the fact that libraries will opt into new features and bundle use of those features with bug fixes will mean that the entire userbase is on a 6 week upgrade cycle -- 8 or 9 upgrades a year. I consider that a mistake. Furthermore, I consider the idea that the channels will not fracture the community to be very naive. I expect a lot of libraries will just live on unstable and tell users to "come with them".
> Why would you be worried that we're following precisely the schedule that we said we would?
You are correct and that was unfair. I can't fault the team for doing what they said -- even if to an outsider it seems like an insanely late time to be doing these types of refactoring.
Possibly the most telling sentence I have ever read about Rust. I am (well more honestly, was) excited by the language but until there is some sort of stability guarantee, it is a fun toy, a distraction.
The Rust community appears desperate to have continuous improvement at the core language level, and despite some hand-waving, it feels like they simply won't be pinned down. I will watch it with interested post the May 15th 1.0 deadline -- but since they shipped entirely new Path and IO in Feb -- added new language constructs and removed others (Alpha2)... I am worried...
We are currently in the process of shifting everything to RT indexes and have been absolutely delighted with the new beta features.
For reasons I can't seem to put down on paper, remote setups that insist on lots of video conferences feel... oppressive in a way that working next to someone simply doesn't.
Stuff like "native look" on OS-X, some shiny features and ability to be easily pre-configured and shipped to people. So I could just give <person-X> a pre-configured little bundle and they just run it, it would generate the cert and do the wizard, but we would have stuff like default push-to-talk, a few default keys, etc.
What codex are you guys using?
Mumble is a cross platform, open source VoIP application. Often used for gaming in a group (like Teamspeak or Ventrilo). It has the idea of channels (rooms, offices, etc) is very high quality, low latency and low bandwidth installed on your companies servers in minutes, always encrypted... and clients are available for linux, windows, os-x, android, ios, etc.
So you can have channels like "Bob's Office", "Working on XYZ problem", etc. People can come into these channels to speak to you and can leave them. It feels a bit like an office environment, I can pop into Jay's office, talk to him about an issue, and go back to my office. I recommend people setup Push To Talk, which really helps create a silent non-annoying environment. Basically, me and another developer can be working on an issue, but maybe not actively talking, but in the same channel -- and there is blissful silence... I don't hear the fan, the cat, the fact that his wife came into talk to him for a minute, etc.
When I start my work-day -- I start it by logging into the mumble server (or more accurately, moving myself out the AFK channel) -- and when I end it, I move myself back into the AFK channel. This is a realtime communication system, async work still happens... well, everywhere else.
It is easy to be on all day as an "in-office" experience... when I am eating lunch, I create a "eating lunch" channel under AFK and put myself there.... We find it works so much better than video chat (or really anything else), is far more casual (like an office) and far more fluid... it is like having an open door policy. Sometimes I might be in a channel that says "Debugging Race Issue Go Away" -- but it technically doesn't keep anyone out, it is a request.
Using mumble day to day basically changed the experience from mediocre to great for us. We still use everything else, but mumble is our real time core, and slack is our async core.
Bob the developer has his own ideas about what + should mean... and uses gobs of hard to puzzle through magic all over the place. You need to run this C++-alike code through Bob's Pre-Processor -- but it is fine, cause if QT can do it, Bob can do it.
I want to read the code to understand the goal and the means for achieving it, not to be impressed with your brevity or cleverness.
Go was/is developed for teams, which means to some degree to the lowest common denominator. So far, in the last couple years, I have -- in general -- come to see these trade-offs as generally wise. Go is exceptional pragmatic for working on a team.
Idioms have to be agreed upon (by the community) else they have no value at all. Shorthand only works if both people in the conversation understand what it means.
It seems like you are upset that the idioms came from the standard libraries (which is where I believe the initial idioms for Go, Java, and Python stemmed from), but you also have to give time.
Play was released in 2007 -- Java was released 1995. So it took a number of years for that change to take place. During the between time, idioms helped move java forward, make it understandable, make developers able to communicate via code.
Go was released in 2012 (v1), so of course a lot of the idioms are going to stem from the standard library -- we don't have two decades of Gophers moving the ball forward and agreeing as a community what the idioms are, they gotta start somewhere.
> Java programmers familiar with the circa-2004 idiomatic BS over-reliance of GoF patterns and deep class hierarchies created code that was "idiomatc Java EE" but difficult to undertand, overengineered, and inflexible.
Idioms are not static. Please stop using that as a strawman to tear down. Idioms rot. If they are not what the community currently uses, they are not idiomatic.
> People keep saying that, but most Go projects I've seen are made by only few of people, maybe even a couple. Plus, people complain about even single-developer Go projects being "unidiomatic".
Current use and design goals are not the same. Google developed Go to be used at (many-people) scale, even if it currently isn't (which I don't agree with: https://code.google.com/p/go-wiki/wiki/GoUsers). It isn't like Go can stop individuals from using it.
Because being able to communicate is a virtue. That is all idioms are, a way to improve communication. By being well understood in a given community or sub-set of a community, they create a lot of value and a type of short-hand for understanding code.
Idioms are not static unchanging things -- they are flexible, adaptable, constantly changing tools that assist in understanding language (both spoken and programmed).
> Idiomatic Java was the FactoryProxySingleton EE-wank fest from Apache, SUN, Spring and co. It was by changing those idioms around (e.g. how the Play framework wrote Java), that saner alternatives emerged.
Seems like your problem is with bad idioms, you seem to be a fan of the Play style -- both are just idioms, a simple way to improve communication.
> The de-facto idiom of PHP before 2010 was messy code.
That isn't even an idiom. An idiom is a well understood part of a language and community. "Messy code" isn't an idiom, it is just messy code. There is no value gained from it, it has no short-hand value and it is not well understood across a community.
> It started getting more coherent after that, but the preffered idiom now (e.g. for Zend, Synmphony, Laravel) is still a tedious, verbose...
But well understood by those in the space, a Laravel person can see another Laravel persons code and "get it" very quickly because they speak in the same idioms. It might be ugly to you, but it is useful to the community. Rails has its idioms, Django as well...
> Idiomatic JS pre-Cockford was ad-hoc BS. After Cockford it got a lot better, but then it changed again (can't say for the worse) with all sort of functional tricks and patterns that weren't in vogue before.
Idioms are about communities more than languages, JS toolkits vary rather wildly in what they consider idiomatic.
> In all of those cases, if they have stuck to the same "idiomatic" way from the start, it would have been worse.
Again, idioms are about what those native in the language or toolkit understand and can expect others to understand, they have never been (nor are intended to be) static, they are a reflection of what a community understands. They are shorthand.
> But within a whole language people should be able to experiment and not be called upon for being "unidiomatic" all the time. This is exceptially disturbing and often in Go, where there's some cargo cult in many advocates that they have found the be-all end-all way to code.
Go has a very strong core set of idioms that Go developers understand and expect. Breaking them has a significant cost to all future readers of the code and should be done only if it adds value in some ways. But a lot of questions in Go are far from settled, error returns as interfaces, concrete types or strings. I would be interested in explicit examples rather than vague cargo cult claims.
> It seems to me this push for "idiomatic" is also related to the Blub paradox. Blub programmers know a couple of ways of doing things (the "idioms" of their language) and cannot understand why someone might want to program with higher (or just different but convenient) concepts he learned in another language.
"different but convenient" can to be looked at in two different ways. The first is for you, the original developer. It is more convenient for you... but what about the next 5 (or 50) developers who are unfamiliar with the idioms in play, it will radically slow them down as they lack the shorthand to quickly understand it. Go is about programming at scale (in terms of people) and something that benefits one while slowing down all others is going to be looked down on. Of course, there are valid reasons, it is faster, it is lighter, it is X. But when you diverge from the norm, you better be willing to explain it in a comment, both the what and the why.
This pervasive myth that it is a "not enough money in the system" does a great disservice to everyone involved and means we never discuss the REAL issue. There is tons of money, but the systematic problems are immune to money -- we could double spending and it wouldn't fix the issues. Parents don't care, teachers are protected by a powerful union so they don't care... student are treated as "must move" assets, standardized testing is held up as the be all, end all of measuring progress.
Instead of continuing to throw money down a blackhole that seems to not generate better outcomes, maybe it is time to rethink our approach... or admit that schools are tiny people prisons and useful filters and have very little to do with educating children, and more to do with segmenting and ranking them (which is useful, but can be done far more cheaply).
I zip through my email in gmail using keybindings, se/e/! respectively with gmail set to go to next message automatically. Takes me a few seconds to go through about 20 emails, then I circle back to the ones I starred.
Inbox looks better, but feels a bit worse for me. Also, the no apps support as always is a downer, but us apps users are used to it.