Threads for nexneo
-
We are preparing our application for move to PostgreSQL. Excited!
-
This is perfect Macbook except that it’s first generation.
-
-
-
Retina: awesome. Battery: awesome. Keyboard: if you hate the chicklets for lack of feedback, will you hate these more or less? Cpu/fanless: I would need to off-box my compiled dev cycle using kqueue to trigger an rsync to a beefy test/CI system that I’ve got a terminal monitoring on the other half of my screen.
I hope we can use the retina without scorching our laps. If so, this will be a fun machine for most situations. I can’t give up the power of my MBP for actual work though.
-
I wonder if it’s too thin. My current MacBook Air at 17.5 mm thick seems very thin to me. I like the heft of my work MacbookPro. Most of the time my laptop is on a table, not in my lap. Combined with the force trackpads; I wonder how many people will accidentally bend their laptop.
-
-
Good read. I liked the case study, much more information than the average “we moved, here are some high-level bullet points you’ve heard 50 times before” articles.
-
-
I have started adopting Amazon CodeDeploy and combing that with Auto scaling is amazing. To some that may not be new thing but moving to completely elastic infrastructure is really amazing.
-
While I liked this article, this one part stuck out to me.
Go feels under-engineered because it only solves real problems.
I usually don’t get that feeling while using Go. Maybe it is a failing on my part, a testament to my ignorance, or my inexperience of language design, but I generally get the feeling that Go was very carefully and purposefully engineered.
In fact, I find it quite jarring when I run across areas of the standard library, or even the language itself, which do not have that same feel to it.
To me, Go feels more like a *BSD, and less like a Linux.
-
-
Releasing first Go based service into production!
-
-
Interesting, the
Killablefunction caught my eye because I’m not aware of any facilities in Go that allows arbitrarily stopping the execution of a goroutine. Yet, the function documentation says:Starts a job and returns a channel for cancellation signal. Once a message is sent to the channel, stops the fn.
I looked at the code for the function, and it seems like “killing” really means “stop waiting on the execution of
fn.”Question for OP: what kinds of things do you work on where these sorts of patterns are useful? (I’ve been writing Go for years and haven’t yet had much use for cool things like this.)
-
-
Since Go has shared-memory concurrency (even though you’re discouraged from using it), arbitrarily stopping the execution of a goroutine could lead to corrupt program state. Java included such a facility, but as a result, it’s deprecated.
(Why? If you die while holding a lock, nobody can undo what you did, and hilarity ensues, like Office Space.)
-
-
Seems wrong on main complain “Confusing Semantics Of Exported Identifiers”, that is not a problem rather that enables good public API design.
-
Let me be the first to say (here): FINALLY.
-
-
Rob Pike’s answer on topic. (via golang-nuts)
I don’t know if it will help his particular case but there has been significant performance work, and much still to come, that has a dramatic effect on the performance of some benchmarks like this. Even what’s at tip now is much faster than go1.0.2 because of changes to the compiler and run-time.
Leaving aside the general unreliability of benchmarks.
-rob
-
It was working fine few hours ago. Now it constantly throwing cloudflare access request page and that page isn’t working.
-
-
If I edit comment, it appears as duplicate(to me) is that normal?
-
My default interface for HN is http://hckrnews.com. I know something like will be useful http://hckrnews.com/about.html
I don’t have anything knowledgeable to put in this debate - I don’t use go - but the language used by Pike in the quote was a bit painful for me. The whole quote is:
“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
“They’re not capable of understanding a brilliant language” - um, I don’t know. Is this a good management style, dissing your own employees? Also stereotyping them? Lots of brilliant people I know aren’t “researchers” i.e. don’t have PhDs or papers. They can work through stuff just fine.
“but we want to use them to build good software” - uh, very “human resources”. Perhaps more “we want them to be able to build good software”?
It could be a turn of phrase but “using” people seems a bit like thinking of people as simple machines. Again, leaves me with a funny feeling.
Words expose a lot of how we think. I don’t like this kind of thinking.
Probably he is just being sarcastic on some languages when he said “They’re not capable of understanding a brilliant language”
Personally I don’t see any problem with word “using” I sometime use that for myself. When I feel management is not using me to best advantage for company/product, I just say “You are not using me” that doesn’t mean I’m considering myself machine. (arguably we are just brilliant machines evolution have made)
Don’t be so sensitive, people are wired differently from each other.
If you are prepared to accept that people are different from each other, then don’t tell people not to be so sensitive. Accept their sensitivity.
Sort of bums me out to hear someone’s worst-sounding quote treated as the “real” them. I expect it more in, say, politics, but it’s not necessarily great there either.
I think there’s a less upsetting but related argument for simpler languages, though I’m not sure if it’s actually what Pike was getting at. Kernighan and Plauger said, “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”
When I started working as a programmer, I was, if anything, smarter than today. I did all sorts of tricks to make code shorter (especially), get things done faster, and try and eke out better performance. (Code that smooshes together other code, my own little languages, more.)
I wound up building some messes that were hard to maintain, using clever approaches that worked at the time but were hard to maintain later, especially when more coworkers entered the picture. I can’t exactly fault past-me; to start with, it was hard to foresee what’d be tough to maintain in, say, three years before actually working three years.
An environment that didn’t make some of those clever options so readily available could have served my clients better by leaving the code more understandable, and even now I don’t mind worrying less in Go about choosing from several ways to express the same result (Jeff Hodges and Rob Napier get me on the latter thing, I think).
This is all just the bones of a discussion that needs much more nuance and fleshing-out. I’m not saying everyone new to the industry makes the same mistakes I did, or whatever, and I also directly feel the costs of the status quo (my sorting package could really benefit from something generics-y!). I’m mostly trying to say that smart coders can also sometimes benefit from more Spartan environments, especially in maintainability.
Also, for all their apparent grumpiness, Gophers haven’t ruled generics out: team members acknowledge the pain, but they’re not high on the to-do list because of the complexity.
If any Go users want to move the ball on this stuff, I think rolling your own Go tooling on top of the existing language is an underrated approach. (Beyang Liu had a neat talk on this.) There’s plenty of neat parts to build on (go/parser, ast, etc.), some tools get pretty popular (goimports, errcheck, gocode), and some do pretty wild things (gotgo, revel). It’d be interesting to look at something like
bradfitz/sliceor an algorithms library (evenencoding/binary) and ask, “can we deploy codegen [or whatever] to make it on net saner to write and use stuff like this?” It’s only one of many interesting areas to explore and the focus it gets sometimes seems disproportionate, but doesn’t change that it’s interesting.