HN user
https://github.com/feluxe
Same here. I've been using Lenovo/ThinkPads for the last 12 years mainly because of the pointer. It's perfect for programming. I'm more productive and focused when I keep my hands on the home row all the time. I don't see myself ever going back to a touchpad.
Haha, no. I'm waiting desperately for one that ships with a pointer. Seems like I'm stuck with Lenovo/ThinkPad forever...
I configure bindings through Zigbee2MQTT. You can view the bindings in the switch configuration, where you can also update or remove them. I use Zigbee2MQTT to handle low-level Zigbee tasks such as pairing, binding, creating groups, setting up scenes, and configuring devices. Most of these things are stored within the devices and work without the coordinator/ha-server.
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.
I think it's called 'direct binding.' All of my lights are directly bound to my switches, so they work even without the server or Zigbee coordinator running. With some switches, you can even bind light scenes directly to the buttons. For example, you can bind the four buttons of a Philips Hue Tap Dial to different light scenes using Zigbee2MQTT.
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.
Same. I was using intellij, then vscode the ten years before I switched to doom. I tried a lot of other editors and IDEs, but emacs was the only one with good vim integration. From all editors I tried, it was also the only one with good plugin interoperability. In emacs plugins are often build up on the interfaces of other plugins. In vscode plugins tend to be encapsulated, competing units which often do not play well together. I also find it much easier to customize emacs to my needs, because the interfaces of both the system and the plugins are mostly well documented.
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.
Meanwhile we have distros lagging behind for years to provide a new package because they can't break all the things depending on the old version.
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 awesome, thanks for sharing! I think this should be added to the PyO3 examples list :)
Python supports type annotations and static typing via mypy and co. I find statically typed Python is absolutely comparable to other statically typed languages. At least I don't feel much of a difference working with it compared to go, typescript.
And docker on Linux doesn’t support all the features that docker on Mac does. Specifically kubernetes.
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).
You can compile your Python code using Nuitka, the resulting binary has much better startup time. I do this for a couple of command line tools.
This looks interesting!
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 is great! I use it to compile some of the command line tools which I have written. Command lines tools compiled with Nuitka have a much better startup time.
Nuitka also has a single file binary target in the works.
Compiled single file binaries for python. Wohoo!
This is also very easy to achieve in Python by using Cython to selectively optimize code
There is also mypyc [0] coming up on the horizon.
du -hs node_modules
1.7G node_modulesSame here. I don't understand why AsciiDoc doesn't get more attention.
What is it about writing views the React way that appeals to you more?
JSX 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.
I wish there was a union operator for typing as well to replace `Union[str, int]` with just `[str|int]`.
AFAIK, Julia has a garbage collector. I envision the thing more like a rust split into two variants. One with GC and mandatory typing, one without.
I hope the next big programming language will be one that is split into two language-variants: the "low-level-variant" and the "high-level-variant".
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.
The 2/3 mess (yes it is still a thing)
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.
That's why I went with git-subrepo [0] over submodules.
If I would have to port a code base from 2 to 3 today, I think the first thing I would do is add type annotations to to the code base via typing/mypy and go from there. A fully typed Python 2 code base shouldn't be too difficult to port with the help of mypy and proper editor support.
Same here. I love to keep my hands on the home row. Nothing can beat a pointer with a concave cap!
I check the system76 laptops every once in a while only to see if they added a pointer yet.
And for that it works nicely and is fast enough.
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 is simple and elegant
C interop in go is super slow: https://github.com/dyu/ffi-overhead
I'm putting off buying a new phone in general until we get a decent Linux variant.
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.
Whoops.. There is one now :)
There are two new tools in the Python ecosystem, which try to fill the gap left by cargo, npm, yarn & co.:
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.
and is there maybe a way to come up with a unified language dependency manger?
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.
Every ecosystem has these problems, and if they don't it's probably because they're still relatively esoteric.
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).