Current PC technology churn that makes me reluctant to think about a new PC
My current home computer will be five years old this fall. Five years is a long enough time in the PC world that any number of people would be looking to replace something that old. I'm not sure I am, though, and one of the reasons for that is that I at least perceive the PC world as being in the middle of a number of technology shifts, ones where I'd rather wait and buy a new machine after all the dust has settled. However, I may be wrong about this; I haven't exactly been paying close attention to the world of PC technology (partly because of my self-reinforcing impression that it's in churn now).
The first point of churn is in SSDs. It seems clear that SSDs are the future of a lot of storage, and it also seems clear that they're busy evolving and shaking out at present. We have ever larger SSDs becoming ever more affordable and on top of that there's coming changes in how you want to connect SSDs to your system. It seems quite likely that things will look rather different in the SSD world in a few years. I expect growing SSD popularity to affect both motherboards and cases, although that may be well under way by now.
The next point of churn, for me, is high DPI displays or more exactly the degree of graphics that I'm going to need to drive one, what sort of connectors it will need, and so on. I think the 'what connector' answer is some version of DisplayPort and the 'what resolution' is probably 3840 by 2160 (aka 4K UHD); I'd like something taller, but everyone seems to have converged on 16:9. On the other hand, this may be last year's answer and next year will bring higher resolution at affordable prices. Certainly the hardware vendors like improvements because improvements sell you things. In addition, the longer I wait the more likely it is that open source graphics drivers will support cards that can drive these displays (cf my long standing worry here).
Finally, there's the issue of RAM and ECC. One part of this is that I have a certain amount of hope that ECC will become more widely available in Intel chipsets and CPUs. Another part of it is that Rowhammer may cause changes in the memory landscape over the next few years. There are claims that the latest generation DDR4 RAM mitigates Rowhammer, but then there are also things like this Third I/O paper [pdf] that have reproduced Rowhammer with some DDR4 modules. Worrying very much about Rowhammer may be overthinking things, but there I go.
(I'd certainly like that any new machine wouldn't be susceptible to a known issue, but that may be asking too much.)
(There are other factors behind my somewhat irrational desire to not put together a new PC, but that's for another entry. Especially since I'm probably wrong about at least one of them.)
When you want non-mutating methods in Go
In Should methods be declared on T or *T, Dave Cheney included a footnote:
5. If the method does not mutate its receiver, does it need to be a method?
(One alternative Dave Cheney had in mind was a pure function that's passed the necessary fields directly, cf. I also suspect that Dave Cheney put this in more to make readers think about the issue than as an outright directive.)
I'll bite on that somewhat rhetorical question, because I see several possible reasons to want a method that merely reads things from the receiver without modifying it.
The biggest one is interfaces. Interfaces can only contain methods,
so if you want an interface to give you some form of polymorphism
over fields you need either getter methods or a method that does
the actual field based computation. We can see this all over the
Go standard library; for instance net.Conn contains some functions that are
more or less getters, namely
Even without interfaces in the picture, encapsulating fields inside method functions preserves your future freedom of action. Maybe the computation involving fields is simple today and easily done directly by outside people, or maybe today the getter functions are trivial. But tomorrow the calculations could be complex or the field values generated through non-trivial calculations; in both cases, you'd want to change the API away from direct field access. Obviously this is less compelling when it involves fields that aren't exported outside your package, because then they aren't part of any public API. So there I'm with Dave Cheney, because this is at least something to think about.
Finally, you may reasonably feel that having read-only method
functions simply makes the (internal) API simpler and more regular.
There's definitely a consistency value in always doing
instead of sometimes doing
x.writething() and other times doing
readthing(x.field1, x.field2). And if you're tempted to write
readthing(x) I would definitely make it a method, because
readthing(x) are almost directly equivalent.