VorpalWay

Not yet that I know of, though perhaps LLVM might be able to infer simple cases (when loading from a known constant for example).

Pattern types could potentially maybe in the future allow for the compiler to know more details though. They are a nightly feature, and afaik only for enums, integers and pointers so far. The idea would be that you can define a custom type such as "an integer between 7 and 45" and everything else become niches for niche optimisation (e.g. for `Option<MyFunkyInt>` some of those impossible values would be used to represent the None case of the wrapping Option).

But I could envisage a future in which you could say "f64 without NaN" which would both make those available for niches and potentially tell LLVM about this. However, we are very far from any of that currently. And it might not be what you want, since you would need to add checks when you perform operations to ensure the value doesn't suddenly become a NaN. Which is way more complicated than ensuring integers don't become, say, zero. It will likely be much harder to optimise away the checks.

Last I checked (a few years ago admittedly) Gnome Tweaks only configured the fontconfig setting, not the ini setting to make GTK4 programs care.

Also Gnome Tweaks is an add-on, not part of the default install on any Linux distro I have tried. In KDE Plasma this is in the standard settings.

And if you use any desktop environment other than GNOME, their preferences certainly won't set the GTK4 hidden ini setting. Rather they expect programs to follow best interoperability practises, such as respecting the fontconfig settings. Most people won't limit themselves to only first-party apps from their DE of choice, so interoperability is king.

Those tank controls are not great, and going to 3D made the graphics noticeably worse. It would have been a better game had it stayed 2D but with the same story. A lot of early 3D has aged poorly.

Yes the first 3 games are really good. But I also have a soft spot for Myst. Maybe it is nostalgia, but I really enjoyed replaying it from the original CD of the Mac release a few years ago (using my original iBook, which is slightly later vintage than the game of course).

Last I checked I couldn't set full hinting. And for GTK4 programs I even had to set a hidden variable in a ini file[1] to make it respect my fontconfig setting for hinting.

Apparently it is supposed to be on for low DPI screens. I would count mine as low DPI (even my laptop is only around 150 DPI) but I still need to set that manually.

So no, GTK didn't keep the font rendering settings I care about, and is actively hostile in trying to ignore them even.

[1]: https://wiki.archlinux.org/title/GTK#Text_in_GTK_4_applicati...

There may be differences between C and C++ here (and I worked with C++ more recently than C), but: if that enum doesn't specify an underlying type it would be UB to have a value that isn't in the "member list" of the enum. In that case it should be possible to determine if all cases are covered.

If an underlying type is specified, then it should error since it is legal to have those values (unless the whole range of the underlying type is covered by the cases.

Again, that is what would be sensible from a C++ perspective, I don't know if C differs here.

EDIT: Also, and now I'm talking with my Rust user hat on: it is better to not have pointless UB. Yes some is needed to practically allow for optimisation. But C and C++ had a lot of UB that doesn't really help with making your code faster, such as this.

Gnome 2 was really good for it's time. Gnome 3 is a dumbed down disaster, removing settings I care about (such as font antialiasing settings, which I need to change to not get literal headaches, subpixel AA is awful as is anything blurry).

And that is just the tip of the iceberg when it comes to Gnome. I went to Xfce, MATE and then Cinnamon for some years, but I'm now back on KDE and it been good for several years (I left KDE when KDE 4 came out and went to Gnome 2).

But each to their own, use what makes you happy. But Gnome has a history of messing with your desktop, KDE less so in recent years.

That or you hit some UB elsewhere that caused the compiler to assume things that you didn't follow.

Trying UBSAN and ASAN might have been worth it. I don't think comparing debug and release builds would have helped: could be buggy optimisations or UB in your code regardless of what the outcome of that test was.

It makes no sense to me that C and C++ didn't require a diagnostic for this, rather you hit UB.

I know that at least modern GCC and Clang will warn and/or error for this (not sure which as I use -Werror), but still, this is pointless UB to have.

And no, in this case I don't buy that a C90 compiler would have been unable to check this.

It all depends. I was thinking mainly of small keys that are at most a machine word. But yes I conceded that for large keys (extremely unusual for what I do, thus I didn't think of that case before) a hashmap wins.

Also, while on a desktop class CPU any pointer chasing you do tends to dominate, that is not the case on small and medium microcontrollers (which I work with a lot). They have very short pipelines and their memory is all internal SRAM most of the time. Here classic cycle counting is still king, so you need to ask yourself if it is quicker to compare the key than to calculate the hash and compare hashes.

Code size in general matters a lot on embedded. Even a simple hashmap will always have more code than a simple vector. And a state of the art implementation with probing and tombstones (such as swisstable in C++ and hashbrown in Rust) will be way too large to be usable.

> I completely agree. My point isn't that Big-Oh is low level, but rather that Big-Oh is often enough for most programming problems.

For what I work on, the hidden constant is often more important than big O. For example, a hash map has better complexity than just searching through a vector. But if the vector is small enough it will best the hash nap for actual time. Just plain searching until you find the element will even beat binary search on a sorted vector for small enough vectors. The reasons are complex, to do with cache, prefetch, branch prediction and also just how many instructions your tight inner loop has. (And the specific reasons will vary between desktop class CPUs and microcontrollers. But both exhibit this pattern.)

You could argue that at that point why bother optimising at all (there aren't a lot of elements in the collection after all). But there are two distinct cases I have come across over the years where it still matters (and for what I work with, they represent the common cases):

* You need to look up in a small collection a lot (either lots of lookups into a few small collections or a few lookups each into lots of different small collections, I have seen both cases).

* Hard realtime code where predictable latency matters. Hashmap has a bad worst case, binary trees and binary searching has badly predictable memory access patterns. And in this case the collections are usually small anyway (there are only so many actuators and sensors your equipment has, and/or the embedded microcontroller doesn't have a lot of memory anyway).

So, where do you draw the line? Do you accept having an OS? Because that is a huge dependency. So I assume you run directly on BIOS or UEFI? But even those are fairly sizable on modern systems.

Depends on your use case. If i want to export some graph data structure from a program to visualise it for debugging purposes, graphviz is way more relevant than doing it by hand in drawio.

But if I'm making a presentation for a conference I would choose differently. And in between you get a whole spectrum of tradeoffs.

An alternative way to think about it would be a padlock and a key. Anyone can close the padlock (assuming the common spring loaded design), but only the key holder can open it.

While this works for encryption, it doesn't really work for explaining signatures or however. Maybe someone can come up with a good analogy for that case.

Shouldn't this have a "(1939)" suffix on the title according to HN rules? ;)

For books an important features is that the shelves have doors and a back, to have to dust off the books less often. Do yours come with that? I'm not finding that brand on any Swedish retailer from a quick search either, so not sure how relevant it is.

I have some older Billy shelves that have been very solid, even when overloaded with books (I too have a lot of physical books, a lot of them older and not available as anything except physical, quite a few even predating the ISBN system).

I'm not sure that is such a strong signal. The minimum return policy by law in EU is 14 days. IKEA has a one year open box return policy. I would not argue that modern IKEA is high quality.

I'm also sure I have seen other stores with a 1 year return policy, though I can't remember which ones off the top of my head.

(That is "return undamaged working product" return policy, not warranty policy. Exceptions apply to perishables, underwear, etc. At least here in EU they are different. Warranty is, depending on product category, typically 3 months, one year or two year minimum by law.)

One signal (not fool proof, but often a good signal): what length of warranty do they offer? If some brand has a warranty significantly above the average for the product type, that can be a good sign.

And I'm not talking about offering extended warranty programs or such here. Just the basic warranty everyone gets when they buy the product.

I can't tell if this is serious or sarcastic. I'm going to err on the side of serious though. Maybe the majority is actually correct, and traditional architecture is just plain better. I certainly find it more welcoming than the modern concrete and glass box jungle.

It all depends on what you are doing. I do embedded with strict realtime requirements. CPU pinning would not be an option. I have also done software that should use as little resources as possible (but still be quick) to coexist with other software on the same hardware.

All of these are different, valid, meanings of high performance. You need context. An interactive IDE is yet another thing that needs to be high performance in yet another way.

Two counterpoints: Searching for "unsafe" is a lot easier when you want to audit the code (there is even a lint you can enable to forbid all unsafe in a crate (library)). And there is a pervasive culture to avoid unsafe where possible and document all the unsafe you do have explaining why it is in fact ok.

There are also experiments in formalizing the safety comments with attributes. To me the current prototypes look halfway towards formal verification, with unsafe functions specifying named requirements that must be upheld when calling them and the callsites needing to "discharge" them by name. Time will tell if this is a good idea for general code and it it catches on.

It has been going between 4G and 5G today while hiking, so if they lie it isn't all the time at least.

But what do you suggest instead (on Android, a Pixel specifically)?

As a beginner use the editor built in on the website instead (called ID). JOSM is a great power user tool, but this article's recommendation to use it for your first edit is misguided.

And I think that illustrates my point well. Yes there is MISRA C++ and CERT for C when you write safety critical code. But that is a lot of extra rules to follow and remember (and have linting tools check where possible). It is basically a entirely separate dialect of the parent languages. And if you aren't doing safety critical you won't be dealing with these but have to come up with your own (company specific or individual) rules. (You dont want to write MISRA C++ unless you have to, large parts of it are quite miserable).

In Rust I get good defaults, and a language that guides me in the right direction. The rules for safety critical rules are somewhat still under development but so far they look a lot shorter (you still need the "don't allocate in hard realtime tasks except at startup" and similar rules for example). And if you aren't doing safety critical you can safely use all of the language as long as you stay away from unsafe.

And for most code you dont need unsafe, and even when you do someone else has likely done the hard work for you already, providing safe abstractions on top. (The exception is FFI to other languages, it is impossible to avoid unsafe when calling code in another language that the compiler can't reason about, you should build a safe Rust API on top of the raw bindings. For popular libraries this often already exists.)

It has been a long time since I coded C. Last I did I remember hating C strings and the standard functions for dealing with them. So easy to get buffer overflows. I'd rather have the language design be so that I dont constantly have to think about not tripping over various things, instead I want to focus on the hard and interesting domain specific problems.

EDIT: Also, errno is an awful design. Forgetting to check for errors, or screw up which error you report is so easy in C. Exceptions in C++ are also bad, it is very easy to have no idea what exceptions are possible 5 layers down and end up with unhandled exceptions.

5G seems pretty widly available here in Sweden in my experience, even in the countryside. Not that the speeds are actually better than 4G, but the indicator say 5G as I'm writing this in a tent in the middle of nowhere. :)

I guess other countries are further behind?

As someone who coded C++ (15+ years) and later Rust (about 4 years now) for my dayjob: there are more than those you listed I have seen commonly. Unaligned accesses is a perrenial favourite, as is ODR violations and reliance on the undefined order of static constructors between translation units. In C++ I didn't see much of unsafe casts, except related to enums (always specify an underlying type to mitigate this).

Rust protects against all of these, but if you think Rust is only about memory safety, I don't believe you have seriously tried it. It does a lot of things in std API design as well to steer you away from bugs. Some examples:

- The pervasive use of Result and Option makes it impossible to forget to handle (or forward) the error case.

- Because of usage of RAII (C++ has this too, but not as pervasively, C doesn't except using some very new GCC extension) it is very hard to forget to free resources such as files, sockets, database connections, mutexes, etc.

- Enums can carry payload in their variants (C devs: think tagged unions, but safe, C++ devs: think std::variant but with match/case rather than bulky visitor pattern), which means you can make API designs that cannot represent invalid states.

- The typestate pattern is a bit hard to explain briefly, but it allows a state machine with types at compile time, to make sure you dont misuse an API. For example it can be used to prevent forgetting setting required fields in a builder before building. Or in embedded microcontrollers to make sure you can't hand out the same GPIO pin to different parts of the code base.

I often find that my code in Rust works first try, while that almost never happen in C++ for non-trivial code. It is what all those Haskell devs were talking about all these years, but in a systems language (no GC is critical to my day job in hard realtime control systems) and without the incomprehensible abstract math lingo.

For a static blog you dont need that. My blog made the (near bottom of) HN front page last year. I didn't notice a thing until I looked at the traffic report (using goaccess). Static site generator with the result served from a bottom of the barrel Hetzner VPS, using nginx.

If a blog needs "scaling" of any sort you are doing it wrong.

Interesting. Though after looking at the examples on their home page and skimming the examples it looks more limited than the imhex format. But that could just be because I don't know this library well enough.

The DSL (domain specific language) for defining data formats in ImHex seems really cool. I have never seen a language that mixes logic into definitions of data structures quite like that before.

It wouldn't at all suit a general purpose compiled programming language (the best you can do there is templates or similar), but here it seems really neat. I haven't looked into it (maybe this exists), but I would love to see this DSL as a library or a code generator, to help with parsing custom binary formats in my own programs. This is much easier for this specific purpose than even parser combinators (which is what I would typically use, e.g. winnow in Rust).