I never understood why state management is overcomplicated in React. For some reason most people use something like Redux which has a very unintuitive API. There are other state management packages available that are so much easier to use and understand, like MobX.
Redux is an implementation of the elm architecture (Tea) which is used for UI state in a lot of languages and frameworks. JS/TS is just not a very ergonomic language for it so it becomes painful quickly.
To shine a light on the mystery, before React had (a) hooks and (b) a stable context API and (c) tanstack-query/react-query or GraphQL - state handling WAS a mess. Thats when redux/mobx etc. made more sense. Try to build something with a pre-2019 version of react and you will understand the need.
I always see this argument but from experience I don't buy it. FSD and its cameras work fine driving with the sun directly in front of the car. When driving manually I need the visor so far down I can only see the bottom of the car in front of me.
The cameras on Teslas only really lose visibility when dirty. Especially in winter when there's salt everywhere. Only the very latest models (2025+?) have decent self-cleaning for the cameras that get very dirty.
For which car? The older the car (hardware) version the worse it is. I've never had any front camera blinding issues with a 2022 car (HW3).
The thing to remember about cameras is what you see in an image/display is not what the camera sees. Processing the image reduces the dynamic range but FSD could work off of the raw sensor data.
It doesn't run well on HW3 at all. HW4 has significantly better FSD when running comparable versions (v14). The software has little to do with the front camera getting blinded though.
"works fine" as in can follow a wide asphalt roads' white lines. That is absolutely trivial thing, Lego mind storms could follow a line just fine with a black/white sensor.
This vision clearly doesn't scale to more complex scenarios.
I think there are more text editors around that render clickable links than there are that don't. Even your terminal probably renders clickable links.
Despite the scary words and score this wouldn't even be a vulnerability if people weren't so hard wired to click every link they see. It's not some URL parsing gone wrong triggering an RCE. Most likely they allowed something like file:// links which of course opens that file. Totally valid link, but the feature must be neutered to only http(s):// because people.
Comparing Outer Wilds to Sherlock Holmes is way too big of a stretch for me. There are mysteries in both, yes, but it's the mystery of the (game's) universe vs. crimes.
I'm curious if you think this way about movies/TV too. It's very strange to me to just dilute things down to their genre(s) and then expect innovation to come out as new genres.
I always see articles like this and have never had it happen to me. It's definitely something that affects specific hardware and/or software combinations instead of just poor QA.
You can drag files etc. onto taskbar icons and it will bring that window to the foreground for you to choose where to drop it. What else do you expect dragging things onto the taskbar icons to do?
not OP, but in macOS, you can drag a file onto a dock icon and that program will open the file if possible. very handy - i use it with Xld, an audio transcoding app. it runs quietly in the background and whenever i need to convert a bunch of FLACs to MP3 (or whatever) i can just drag the folder to the icon and 10 seconds later everything is good to go, without ever really directly interacting with Xld.
> Now when the OP leaves the organization is in a much tougher position.
Are they really, though? You're assuming their org is unfamiliar with C#. Not all data engineers only know Python. The ones I work with mainly use C# because we all do!
I'm a software and data engineer. I work with C# pretty extensively in my software day job. I've never seen a data engineer job listing mention C#.
Additionally, the way the OP's comment reads, I'm ok with the assumption I made. It reads like it was a unilateral decision on their part and not something that got buy in from the team.
I'm curious why you'd want this over using a GUI library that is actually cross-platform? The way you've worded things suggests to me that you're building something new.
I want to go back to making desktop programs the way we used to before they turned into web apps that bundled chrome. I know I should just use Qt but I have some experience already with win32, and all the programs I have fond memories of are written with it (foobar2000, winamp, Everything, etc).
Someone else mentioned Lazarus, though that is Object/Free Pascal, not C/C++. The API is based on VCL for Delphi which was designed for the Windows API and even though Lazarus is cross-platform and can use multiple backends (actually i've been playing with writing a FLTK backend[0], though it is in primitive stages and FLTK doesn't really like exposing much of its guts), the API has some windows-isms (e.g. colors are 4 bytes where one byte is used a special marker to indicate system colors, just like in Windows) and the backends even have to implement a small subset of the Windows API to work :-P.
An alternative in C++ would be wxWidgets which has some (light) MFC inspirations, again feeling somewhat Windowsy though not full-on MFC/Win32 since from the beginning it had to work with X Windows / Motif in addition to Win32 (and AFAIK, the Motif backend still works).
Another alternative, even more lightweight would be the aforementioned FLTK. FLTK is also designed to be statically linked with your program (though it can be linked dynamically too if you want) so it only relies on common system libraries (as an example the screenshot in [0] relies only on the C library, the C++ library -because it is needed by FLTK and it is possible to also statically link to that too- and common X11 libraries like libX11, libXft, etc that existed on any Linux desktop system for decades now -- FLTK can also support Wayland, though i haven't tested that).
Have you considered Tk? Visually, it's quite like Win32, but it's fully cross-platform and (as of Tcl 9.0) has basic screen-reader support – so no mucking around with OLEACC shims or IAccessible2, as you'd need for COMCTL32. And it supports virtually everything Win32 does, with the ability to drop down to platform-specific sorcery (i.e., Win32) if the need arises.
It is. But if you mean .NET WinForms then you don't really need Wine because Wine uses Mono to run .NET executables. If using WPF then you should check out Avalonia UI [1] which is a cross-platform alternative that is also probably better (and has good tooling in VS). There's also .NET MAUI [2] but it's maybe not as good for desktop apps.
https://github.com/mobxjs/mobx
reply