484 karma · joined August 16, 2016
The configurations you set up in Zigbee2MQTT are synced with HA and can be used there as well. I use the options provided by HA for higher-level tasks, such as automations, custom sensors, statistics, and more. Everything I configure there will not work when the server/coordinator goes down.
Some switches don't allow direct binding, though. All of the Hue switches I tried support it, but some Tuya switches don't. On the other hand, all lights from different manufacturers which I tried were able to bind directly.
The first year I had to fiddle a lot with the tooling. The uptime of HA/zigbee2mqtt wasn't great. It was good to have this as a fall back.
Emacs has a high barrier of entry though. I think it would be difficult for a novice to get a good IDE experience from emacs, even with doom.
I'm glad I left this category of problems behind me 5 years ago when I switched both, my personal and my work laptop to arch-linux/i3wm. These two machines have been running for 5 years, almost daily, with almost no issues, with the latest software packages. If the hardware lasts, I will go on like this for another 3 to 5 years and then upgrade hardware and (maybe) switch to wayland. I don't see anything on the horizon which would make me switch away from this setup.
This is nonsense. We invested multiple man month this year to create a local k8s dev environment for our company. Our devs use MacOS and Linux. Me and my colleague evaluated various solutions for running k8s locally, all of which worked fine on Linux out of the box, while the process of setting them up for MacOS was riddled with issues (mostly around performance).
I think the approach where a typed subset of Python is used to compile a fast extension module is the way forward for Python. This would leave us with a slow but dynamic high-level-variant (CPython) and typed lower-level-variant (EPython, mypyc & co) to compile performant extension modules, which you can easily import into your CPython code.
The most prominent of such projects I know of is mypyc [0], which is already used to improve performance for mypy itself and the black [1] code formatter. I think it would be interesting to see how EPython compares to mypyc.
Nuitka also has a single file binary target in the works.
Compiled single file binaries for python. Wohoo!
There is also mypyc [0] coming up on the horizon.
du -hs node_modules
1.7G node_modulesJSX is JS thus it's powerful. I prefer to use JS to "sprinkel the magic", rather than using yet another (awkward) template language. Using JS for everything is keeping my mental consistent. I enjoy getting full editor support for the entire app (typing (via TS), warnings, auto-suggestions, etc...). Overall it feels more consistent, more composable and more functional (as in Functional Programming) to me.
The high-level-variant is a dynamic language with optional typing, which is good for scripting, fast prototyping, fast time-to-market, etc.
The low-level-variant is similar to the high-level-variant (same syntax, same features mostly, same documentation), but it has no garbage collector, typing is mandatory and it runs fast like C/C++/Rust. Compiled packages that are written in the low-level-variant can be used from the high-level-variant with minimal effort or without additional effort at all. The tooling to achieve this comes with the language.
It's still a thing for the (loud) few who couldn't manage to move to 3 after 10 years. The rest just went on. The ecosystem is on 3 [0] and it has been for years now.
> The insane packaging situation. Packaging a Python app is a nightmare.
The packaging story in Python is in the middle of a big transformation from legacy tools to modern npm/yarn/cargo-like tools. pipenv [1] and poetry [2] are the most popular contenders. It will take a while until the community settles on this, but both tools work already.
[1]: https://github.com/pypa/pipenv
[2]: https://github.com/sdispater/poetry
> Dynamically typed
Python 3.5 introduced type annotations. It is now possible to write statically typed code in Python via mypy [3], which from my experience works similar well as TypeScript works for JavaScript.
I check the system76 laptops every once in a while only to see if they added a pointer yet.
It may be fast enough for you, but it certainly isn't for many other people. golang will for example never grow a large mathy/scientific ecosystem, because of it.
C interop in go is super slow: https://github.com/dyu/ffi-overhead
Me too. I want a smartphone which can run an up-to-date OS for more than 5 years, just like my laptop.
LinageOS dropped official support for my current phone a couple of month ago, which means no more updates for this phone... EOL... The phone was released July 2016. The hardware works just fine. I would use it for many more years if it was still receiving updates. What a waste of resources and time.
Once again I'm looking for a new phone, because my old one died of planned obsolescence.
One is pipenv [0], which works similar to yarn & co. It uses Pipfile/Pipfile.lock to define and lock dependencies. Pipenv has a major flaw: It can't be used to publish packages on pypi.org (you still need twine & setup.py for that). It's also known for being slow and somewhat buggy. Despite all that pipenv is an "official" tool maintained by the "Python Packaging Authority".
The other one is poetry [1], which works exactly like yarn & co. It uses "pyproject.toml" to specify dependencies and "poetry.lock" to lock them. Poetry does most of the things "right", but it's still an underdog compared to pipenv.
Both tools have not yet fully matured, thus there are a lot of complaints.
For interpreter/compiler version management you can use asdf [0]. It works for all popular programming languages. You can use it to replace tools such as pyenv, nvm, gvm, etc.
Exactly! I'm not aware of any non-compiled language where (all) these issues are solved much better. I can be very productive with the tools I mentioned above and I'm glad that they work almost identical for both my main drivers (Python and JS/TS).