Couldn't agree more. Rot is rot. People hate reading giant verbose AI generated PRs. Imagine mandating your codebase requires people now also read AI generated markdown files to compare the AI intent with the AI outcome. What a laugh and this is the guy giving out CS degrees and opposing React.
I'm so tired of "smart" tech. I don't want my TV, or fridge, or dryer or anything connecting to wifi and bluetooth and having an app to manage settings. It's hard to believe there's demand for any of these terrible "features". The peak of smart tech were watches you could do math on.
Oh no ... I think you do actually want those. It's quite amazing to receive a notification from your dryer that it finished its cycle.
What you do not want instead is :
- being mandatory
- requiring a proprietary application
- expecting the app to force onto you services
- expecting the setup to fail and making the hardware unusable over time
because honestly when it does work, it's great. It's really not the features that are problematic, it's the predatory surveillance and locking down way to provide them that is absolutely horrible.
Some people have their dryer far away from where they usually are and cannot hear it, like me. Although I do put a timer for N hours to remind myself rather than having a "smart" dryer.
I do like "smart" lights that are based on presence, and various sensors and "smart" automatic irrigation, but don't see much point in home appliances being connected to my phone/network.
I think we tend to forget that many things can be implemented without "smart" features / wifi access / apps. Ie my 20 year old oven has a "start time" feature. It just uses the built in clock.
I don't think I know of any (big) appliance, e.g. dish washer, drier, washing machine with that option but to be honest I didn't dig deep, is it possible?
> It's quite amazing to receive a notification from your dryer that it finished its cycle.
It’s really quite useless to me.
What I may want is an ODB so I can plug in whatever external observation and possibly control plane I wish, were I so inclined (I am not), and could make my device smart. Hell for a dryer you could probably have a plug or panel feeding into HA and send an alert based on load.
Anything that’s “smart” out of the box is rife for abuse and will eventually sink into that.
Well that's the point, you do want information in and out, including the ability to send instructions. Call it "smart" or "connected" or whatever marketing words you prefer, the point is having affordances that give you agency.
So yes I insist you do want those, just not in the way it's been currently forced. IMHO you are right to reject this as it is but wrong to reject the possibilities when done right.
We are just so disgusted by the way it's currently done that we reject the entire possibly. Quite sad really.
Edit: I have been using HA daily for years now. Smart plugs work and are useful but it's rarely enough. You can infer the device state based on instant consumption but you can't convenient control back.
I think I agree with the parent more. For one, not all "smart" appliances are made equal. You can see the appeal of some of them if there was no customer abuse, like with smart TVs. But things like smart microwaves are a harder sell. In practice, lots of smart devices are made with one purpose - to remove methods of configuring it on-device and instead forcing you into using the manufacturer's app. Many of them offer no benefits over their non-smart equivalents, and whatever benefits are there are usually solutions in search of a problem.
And I think their point is that, even with strong legislation, giving every device unlimited internet connectivity is a siren song for the corporations which will always be incentivized to shoehorn their interests into the product you own. Things like control through external connectors, on-device modifiable configurations, only local connectivity or flashable firmware would not qualify as 'smart' but would go a long way to do the things you're looking for without giving them the physical possibility of future abuse.
Internet connectivity as a requirement is an instant red flag ... but it doesn't mean we should have appliances we can't control.
This false dichotomy is precisely the problem. I DO want to program my hardware, even ones with actuators, but I do NOT want for this to happen to rely on the infrastructure of the manufacturer if I don't explicit ask for it.
I have a speech recognition standing fan with touch button. Its terrible. The voice is loud, the touch controls dont register very well, give me a dumb thing with physical buttons please!
I'm not advocating for touchless smart devices, I'm advocating for optional interface we can use to operate our appliances without having to rely on the manufacturers app and/or server.
But that's the problem: as soon as you move control inwards to the software, and add more accessibility (smart watch, voice control, whatever), you have a sophisticated, hidden control layer.
How do you know that your dryer won't lock onto an open wifi? How do you know that your smart TV won't download malware? You don't.
Contrarily, if you accept that you only hear the dryer "DONE!" bell if you are within 20' or so, you can be certain that the dryer is yours and yours alone.
> generics were a slippery slope. give it a decade and Go will be indistinguishable from c++
Lib boost will have conquered every language by then!!! :D
Jokes aside, generics are unusable in a lot of languages due to their syntax choices. In Go we kinda have the problem that there's no real templating and no real macros, so they're even harder to use.
But I agree somewhat, generics feels to me like an anti pattern in Go.
Also, the way the Go core/stdlib is written, it makes generics so unnecessarily painful to debug. Why they decided to have definitions like "~C" or "~[]S" is beyond me. No human knows what the resulting compile time error means. They should have named these things "Comparable" or "Slicable" or whatever is more expressive. Just stop with this stupid single letter shit.
Generics themselves maybe not. Generic methods probably yes. What people want generic methods for is to do deeply nested call chains that were never typical of Go. And if you have deeply nested calls you'll need some way to deal with errors in deeply nested calls, and then a short function syntax to pass to behavior inside those deeply nested calls. Give it a few years and everyone will be writing the same functional slop in Go that they are writing in every other language.
> What people want generic methods for is to do deeply nested call chains
I don't see that as the only use of generic methods.
The example in the article is a "Map" method that transforms e.g. a List[A] to a List[B], by taking a function that takes an A and returns a B. To be able to transform a list like that is a useful operation.
It was possible to do the same with a global function like MapList but the syntax is nicer if you use methods. You don't need the type in the name (function MapList vs method Map) and it is an operation on the List after all so list.Map(..) is nicer than MapList(list, ..).
The generic methods that have been added are essentially just syntax sugar. You can now use method syntax in cases where you could equivalently define a function. They’re not the fundamental extension to the type system that some people have been asking for (and probably will never get, because there’d be no reasonable way to implement it).
Not here against Generic methods, but I feel the Go team is in a mid-age crisis where they lack of new things to do to prove themselves. See their iterators mini-drama not long ago?
I feel the sumtype/emum/routine demanders should yell a little harder so Go team can find their purpose again.
