Dark Arc

It sounds like just from how you describe things Swift is using fibers instead of real OS threads(?)

Seriously look at this comparison of DispatchQueue and OperationQueue

What are these things/what is this comparing?

Hmmm… That’s true, my rough litmus test is “can you explain what this thing does in fairly precise language without having to add a bunch of qualifiers for different cases?”

If you meet that bar the function is probably fine/doesn’t need broken up further.

That said, I don’t particularly care how many functions I have to jump through or what their line count is because I can verify “did the function do the thing it says it’s supposed to do?” after it’s called in a debugger. If it did, then I know my bug isn’t there. If it didn’t, I know where to look.

Just like with commits, I’d rather have more small commits to feed through git bisect than a few larger commits because it makes identifying where/when a contract/test case/invariant was violated much more straight forward.

This only leads to bad code when people get to afraid to refactor things in light of the new requirements.Which sadly happens far to often. People seem to like to keep what was there already and follow existing patterns even well after they are no longer suitable. I have made quite a lot of bad code better by just ripping out the old patterns and putting back something that better fits the current requirements - quite often in code I have written before and others have added to over time.

Yup, this is part of what’s lead me to advocate for SRP (the single responsibility principle). If you have everything broken down into pieces where the description of the function/class is something like “given X this function does Y” (and unrelated things thus aren’t unnecessarily coupled) it makes reorganization of the higher level logic to fit the current requirements a lot easier.

For instance I see this a lot in DRY code. While the rules themselves are useful to know and apply they are too easily over applied removing any benefit they originally gave and result in overly abstract code. The number of times I have added duplication back into code to remove a layer of abstraction that was not working only to maybe reapply it in a different way, often keeping some duplication.

Preach. DRY is IMO the most abused/mis-understood best practice particularly by newer programmers. DRY is not about compressing your code/minimizing line count. It’s about … avoiding things like writing the exact same general (e.g., a sort) algorithm inline in a dozen places. People are really good at finding patterns and “over fitting” making up abstractions that make no sense.

I agree; I prefer a “hammer and chisel” strategy, I tend to leave things a little less precisely organized/factored earlier in the project and then make a some incremental passes to clean things up as it becomes more clear that what I’ve done handles all the cases it needs to handle.

It’s the same vein as the “don’t prematurely optimize.”

Minimizing responsibilities of individual functions/classes/components is the only thing that I take a pretty hard line on. Making sure that I can reason about the code later and objectively say simple sentences like “given X this does Y.” I want all the complex pieces to be isolated into their own individual smaller pieces that can be reasoned about.

All of the code bases I’ve been in where I go “oh my god why”, the typical reason is been because that’s not true; when I’m in the function I don’t know what it does because it does a lot of things depending on different state flags.

I’ll contest their is such a thing as good code. I don’t think experienced devs always do the best job at passing on what works and what doesn’t though. Universities certainly could do more software engineering/architecture.

My personal take is that SRP (the single responsibility principle) is the #1 thing to keep in mind. In my experience DRY (do not repeat yourself) often takes precedence over SRP – IMO because DRY is easy to (mis-)understand – and that ends up making some major messes when good/reasonable code is rewritten into some ultra-compact (typically) inheritance or template-based mess that’s “fewer lines of code, so better.”

I’ve never regretted using composition (and thus having a few extra lines and a little bit more boilerplate) over inheritance. I’ve similarly never regretted breaking down a function into smaller functions (even if it introduces more lines of code). I’ve also never regretted generalizing code that’s actually general (e.g., a sum N elements function is always a sum N elements function).

The most important thing with all of these best practices though is “apply it if it makes sense.” If you’re writing some code and you’ve got a good reason to have a function that does multiple things … just write the function, don’t bend over backwards doing something really weird to “technically” abide by the best practice.

I want one even more badly for thunderbird. It feels like such an obvious thing that’s just … missing.

Okay, that’s pretty cool not going to lie. Granted, I’m not entirely sold on the idea of having a config format that’s aimed at generating other config formats.

That feels like (in most cases) a recipe for things getting out of sync between the latest version of the PKL and e.g. the JSON

I agree with this, but there are ways to make your “source code” not a file that you will modify.

For instance you can have a file that’s imported/included for configuration purposes that you yourself don’t author… And I think that’s okay.

One of my favorite configuration languages for Python projects is actually just Python. It’s remarkably nice. It’s like having a YAML file you can script.

I should have said statically typed, fixed.

Python also has a statically typed option these days.

Edit: Previously said “strongly” instead of “statically”

I mean it’s a student project. It literally could be “I think Swift is cool and I like Linux.”

And you know… They’re not wrong, Swift is a cool language, it’s just not got much adoption outside of the Apple ecosystem for whatever reason. It’s long been workable on Linux … I’m happy to see some novel work in this space.

Swift is also interesting because while it’s general purpose, UI design was always in mind for Swift. That’s different from C or C++ which are the basis of GTK and Qt the predominant UI frameworks used for the Linux desktop currently (Rust might enter that conversation more seriously with Iced and System76’s COSMIC).

You’re also right that there are options … but there are also options in the Windows world. Everybody isn’t using what Microsoft uses and even Microsoft doesn’t use the same UI toolkit everywhere.

If you use the software without modifying it directly (such as building on top of it, or building something that uses it), then that’s allowed.

(IANAL)

Not in the case of AGPL (use over the network and IPC counts as distribution – presumably proxying the request is insufficient to disable this clause) and even in the case of GPL that’s a very problematic position to put yourself on. You’re basically talking about invoking a foreign process from your primary process to avoid licensing constraints and that comes with a lot of limitations as to what you can do.

You can modify the GPL program to support more things via IPC but then if that program needs to touch a customer’s computer, you have to contribute at the very least those notifications and any related improvements you made to make that possible or any new feature which makes more sense to be in the tool you’re calling than your tool building on top.

And last, if you don’t modify the software but charge people using it, that’s completely allowed.

Yes, but who’s paying for that? If it’s a server hosting company, they’ll pay the hardware rental fee, fair enough. However, you can’t reasonably sell that software itself, people will just build it themselves.

It does, AGPL for servers, GPL for applications… If you make changes they have to be made available or you’re breaking the law.

There’s generally an understanding (the GPL folks think it’s naive – and this makes their case) that if you use open source software you should give back to it.

https://redis.com/blog/redis-adopts-dual-source-available-licensing/

This is the announcement.

This is a disappointing outcome but one that I think has been coming for a while. Amazon has profited off of Redis without giving much back for quite a while (at least I recall this being a complaint of the Redis folks, perhaps others have evidence to the contrary).

This is pretty clearly an effort to bring AWS to the table for negotiations.

In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of block

Which is what I said, this is about the default.

My issue is not that I don’t understand Rust provides static guarantees. My issue is that you raised a comparison between unsafe Rust and C++ code. In that comparison, you’re basically saying “writing an entire program in a rust unsafe block would be better than writing an entire program in C++” and I think that is very wrong.

Rust unsafe is not better than normal C++ while following best practices for maintaining memory safety.

And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?

Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.

Accessing a union that’s in an invalid state is also a big problem.

Use after free… Maybe?

Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.

Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).

A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

Python is memory safe? Can’t you access/address memory with C bindings?

You can do that in basically any language. Rust even has the ability to break out of its safeguards and write unsafe Rust code.

“Memory safety” in this context is more about the defaults and how easy it is to write unsafe code accidentally.

C++ is leagues above C in this regard. He’s rightly upset that they’re lumping the two together.

Bjarne’s work for safety profiles could indeed manifest in a solution that guarantees memory safety; time will tell. C++ is a moving target.

I’d recommend using a VM in that case and calling it a day.