Error handling in Go is actually very nice. You do not have unhandled errors, not possible unless you really want to not handle the error. Now I even use it similar in Python, amazing how many errors I did not handle at all. But what got me into using Go is that there is no libc dependency, just system calls, static binary, that is just amazing. I can compile Go compiler in like few minutes. Rust I cannot even compile after 24h, I use rust-bin in Gentoo,luckily that exists.
Could I ask what hardware this is on? Even when building LLVM from scratch too as part of building the toolchain (which hasn't been the default for a while now, but could see Gentoo doing so), it never took that long on any hardware I own. (Granted, I never tried on the EEE PC I've got on some drawer, and its 2G of RAM would likely kill the whole thing before it got started.)
$ time ./x.py build
... snip ...
Build completed successfully in 0:21:24
real 21m24.736s
user 67m48.195s
sys 1m54.906s
Subsequent builds during development are faster (as 1. it doesn't build the same compiler multiple times, you can use the stage 1 build as normal, stage 2 is not strictly necessary and 2. if you modify one of the constituent crates of the compiler, the ones that are lower in the dep tree don't get recompiled). I've used this laptop on and off for rustc development for the last 10 years. Nowadays I spent more time using a cloud desktop that has much faster IO, but still use it during travels sometimes.
From the sound of it, I suspect that your issue might be that you don't have enough RAM and your build is swapping a lot.
This is an older thinkpad I am using, 4 cores, 16G of ram. LLVM is now dependency you cannot get rid of. That is painfull, but in the morning, after several hours it is usually done. Rust is LLVM plus I am not sure what, really painfull. And Gentoo also forces many different arches and flags for some reason, use flags are masked, you cannot easily disable them.
That sounds similar to the hardware on my T460 (2 cores, 4 threads, 16G). Would you consider cloning the repo and building it with the same command as my other comment? I'm really intrigued if the issue is the hardware/platform or "just" the Gentoo configuration or something else that doesn't affect the default build process.
Are you joking? It's trivially easy to drop the err or just not handle it accidentally in ways that are essentially impossible in rust. Especially when people re-use the `err` variable.
Window positioning? You cannot position the window, you cannot send a hint, nothing? So my pop-up with GTK4 will randomly be placed somewhere, anywhere, without any control. OK, GTK4 went further and also removed popups without the parent, so you hack that with an invisible anchor window and then write platform-specific code for sane platforms that CAN, of course, move the window. And let's not talk about window icons that you have to put somewhere on the file system?
Have you considered if someone wants to make a compositor where each window is projected onto a facet of a hyper cube and must place windows in 4 dimensions? These are important use cases we should support, we should make cross platform software as difficult possible to develop for Linux by removing features that have been standard on desktop operating systems for decades.
I must correct you! Wayland has not and indeed cannot remove features because Wayland is a “protocol”. It is the compositors that are removing features.
This dilution of responsibility should make you feel much better.
It's not technically behind on window positioning. Rather, it was a deliberate choice not to support it. You can very reasonably object to that, but it is sorta a necessary measure to prevent clickjacking.
And common sense mitigations: if a new program I've never seen before drops an actionable control under my cursor, maybe just default to not immediately accepting the next input to it so I have a chance to see it.
I mean, you can create alternate APIs that would work for the pop-up use case: you could have a command to create a new window positioned relative to the current window’s coordinate space.
That limited capability still has a risk of denial attacks (just throwing up pop-ups that extend beyond the current window’s boundaries), but those can be mitigated in a number of ways (limit the new window’s boundaries to the current window’s, or just limit how many windows can be opened, etc.).
I like how even the nus product (jpegli) is a significant improvement. I am in the process of converting my comic book collection. I save a lot of space and still use JPEG, which is universally supported.
To me, this argument always sounds like someone is being forced or threatened into creating a desktop app. It was never supposed to be easy; the goal is to create an app that users would want and will actually use.
I am working on the UI library and bindings for Go. Still not finished, but currently, the same app can be compiled for Win32, Cocoa, GTK2, GTK3, GTK4, Qt5, Qt6, and Motif. There is a web browser control, a GL canvas, and a regular canvas. I still work on the native table control, though.
IUP has custom-drawn controls for tables and cells (additional controls), and it uses another CD (canvas draw) library for that, not internal IUP Draw functions. I also started rewriting that to use the core IUP drawing functions instead. I also added a few more drawing functions, for rounded rectangles, bezier curves, and gradients. But ALL drivers, including Motif, have native table controls, so I really want to add one.
Edit: Also, the GLcanvas control now has an EGL driver, with native Wayland support for GTK3, GTK4, and Qt6 (needs private headers). I modernized a bit of everything, added support for APPID, DARKMODE, etc. Linux uses xdg-open rather than hardcoding browsers. Win32 driver is not using the Internet Explorer web control but the WebView2 with custom loader, on GTK, you do not have to worry about the WebKitGTK, it will find the correct library with dlopen, etc, etc. But, there is still a lot to do.
Sure, but Apple doesn't fully support HEIC either.
They support only a very specific subset of it, in a particular combination.
Some Apple apps can open third-party HEIC-in-HEIF files, and even display the image correctly, but if you try anything more "complex", it'll start failing. Simply forwarding the image to someone else will result in thumbnails looking weirdly corrupted, brightness shifting, etc...
I've even seen outright crashes, hangs, visible memory corruption, etc...
I bet there's at least one exploitable security vulnerability in this code!
I often use <img> with "width" on GitHub, so that I do not have the scrollbars on the main page, and one can click on the image to see the original size. It is ugly, but what is the alternative in Markdown? Several images instead of one?
I know a few apps that did the same (mpv for example). If you still have it in home root it uses that, when you move it to .config it uses that instead. Auto migrating could and would create issues.
People are talking about AI everywhere, but where can we find documentation, examples, and proof of how it works? It all ends with chat. Which chat is better and cheaper? This local story is just using some publicly available model, but downloaded? When is this going to stop?
reply