Ah it was intentional and now I see how it was meant. It makes perfectly sense, it was just not clear before. :-) Human language and interpreter is not as precise like programming language.^^

So yeah, exception as part of explicit function signature is a vast improvement, I completely agree

Hmm, I’m not sure if you are being sarcastic. In my reply I didn’t meant encoding Exceptions into Type system. Is this a type and you probably meant “Error Types as part of” instead “exception as part of”?

Honestly I don’t know how Exceptions as part of type system would even look like. Because each function call in a chain would need to have all information from previous function call, otherwise that information gets lost to the next caller. The problem is the hierarchy of function and method calls. Somewhere some objects and functions can be edited to Throw a new Exception, that is not handled through the entire chain. And for the higher function caller, there is 0% way of knowing that (through code, besides documentation off course).

Read my reply with a handful of sea salt. I just read tutorials and documentation a bit and did Hello World.

Zig is pretty cool too! It can run C code directly just like C++ does (I think), kind of drop in replacement. From my reading so far, Error Handling is kind of a marriage between Go’s and Rust’s Error handling. Actually pretty cool. It has Error Types, but is kept relatively simple and doesn’t force to do all the stuff. It has Try and Catch keywords to handle errors elegantly, but don’t be fooled, this has nothing to do with Try…Catch blocks for Exceptions. Zigs Try and Catch are more like Rusts Result type handling, at least from what I read so far.

I lean more towards Zig than Go, but it still has not reached stable 1.0 release.

My anecdotal experience is that Rust code, for example, has more calls to unwrap than I’d like. The problem here is that simply unwrapping results will crash the program on errors that could have been a user-visible error message with exceptions.

unwrap() is explicitly not handling the error in a Result type. If you must do this, then at least use except(), to unwrap the code but with an error message if program crashes. Its the equivalent of having Exceptions and then not handling that exception. Therefore your critique is not valid here.

One problem with Exceptions is, you never know what code your function or library calls that can produce an exception. It’s not encoded in the type system or signature of the function. So you need to pray and try catch all possible exceptions (I look at this from Pythons perspective), if you don’t want a Catch…All, which then you wouldn’t know what error this actually is. And you still don’t know where this error came from or happened in the code, how deep in the function call chain? Instead Errors as Values means its encoded in type system and you can directly see what errors the function can cause and (in Rusts case) you must handle the error, otherwise program won’t compile. You don’t need to handle anything else in this context. Compiler ensures that all possible errors are handled (again within context of our discussion). Vast improvement!

Copilot is a tool for programmers who don’t want program.

NT is often touted as a “very advanced” operating system. Why is that? What made NT better than Unix, if anything?

NT was very advanced compared to its prior Kernel, not compared to Unix.

I don’t like it either, but I’m not entirely sure why. Maybe the biggest flaw to me is it uses Python style indentation for structuring as part of data logic. It doesn’t feel like a configuration language to me and it does not feel simple too. It’s also unlike most programming language structures (maybe besides Python), so it looks weird to read and write. Other than that, I don’t know exactly why I don’t like this format much. Admittedly, I did not do much in YAML, so because lack of experience take my opinion with a thick grain of salt.

We have JSON and TOML. I quiet like TOML. We have “better” alternatives, that are probably easier to parse. And therefore there is not much need for YAML. Maybe if YAML was the default config format for Python it would get off the ground and be accepted more often.

It’s an AI tool analyzing a Git repo.

Not exactly what you asked, but related; roast your Github profile: https://github-roast.pages.dev/

https://www.apple.com/customer-letter/

This is a letter from Tim Cook himself in 2016, regarding this topic. I might be wrong, but remember those articles talking about this subject and the master key for the iPhone. I’ve not read this document yet (just found it when researching to refresh memories).

The government suggests this tool could only be used once, on one phone. But that’s simply not true. Once created, the technique could be used over and over again, on any number of devices. In the physical world, it would be the equivalent of a master key, capable of opening hundreds of millions of locks — from restaurants and banks to stores and homes. No reasonable person would find that acceptable.

So without having full understanding whats going on, it looks like Tim was talking about an equivalent effect of a master key, when using such a tool (the firmware?). Maybe there comes this misconception in the media?

This is not new to me. While this is about iCloud and not the iPhone device itself, wasn’t there news in the past where Apple didn’t want cooperate and give the FBI the master key to unlock iPhone device? According to Apple, they have a master key and won’t give it to anyone, other than unlocking devices for repair.

If that ever happens, we don’t know. Apple is an US company, so who knows. My point is, this is not new news (to me), because that is known and Apples strategy.

@FizzyOrange@programming.dev I see and think understand what you guys saying. Guess cheating can do only so much. I will go back to the drawing board and write the function (inside of an impl block) from ground up with threading in mind and learn how to do it properly.

Why is it nonsenical? It works and compiles and the output from my code and the new async code is the same. So I don’t know what the problem here is.

BTW both applications download from HuggingFace and I could just place any .gguf file downloaded manually too. And it runs through lamacpp too, so it shouldn’t be too different. GPT4All got a few big updates recently.

But I lack experience and am open for any alternative. Unfortunately oobabooga is not available through Flatpak (I’m on Linux). If it becomes available as Flatpak, I’ll give it a try. At the moment there is no hurry for me, as it works fine now. But the new Llama 3.1 128k is slow and I wonder if its a problem with AMD cards, with GPT4All or if this is a problem with this model in general. So that’s why I’m open to try other software.

I have no comparison, so cannot say much. But what do you mean by memory bottlenecks? Isn’t this a limitation of the hardware itself? I mean if I have a memory bottleneck on GPT4All, then I would have it using with other software as well.

Why is it better?

Not at this scale. The usual outage usually breaks certain parts of Github, but not everything at once. This time, Github broke completely, not even the homepage was working for a while. This is definitely not the usual outage we know and love.

Git repos are still decentralized. It’s just Github was failing, the thing centralized and synced to. The point of Git being decentralized is, being able to take any of the Git repo copies of the current working developer, and host it on a Github alternative. Meaning the code and project did not get lost because of Github. It’s not that such an outage wouldn’t be a problem, it’s just such an outage is still a problem that can be solved and not a showstopper in the longrun.

Even if Github suddenly cease to exist, out of nowhere, everyone who has a repo copy can setup such a server and work on it as nothing was happened (minus the Github features and hopefully nobody uses the Github app). I believe this is not the case with SVN. If the main repo gets corrupted or destroyed, then its an unsolvable problem. Unless you have a backup. And on Git everyone working on the project has basically a backup.

In short, Git itself works offline. But if you are dependent on Github and its features and applications, then it becomes a problem. So I don’t know why SVN is mentioned as the savior here.

I wish Rust would adopt tokio (or any other, if better suited) as a default first citizen async runtime. Then everyone can be sure to write in that runtime , knowingly it will run. If people need a different runtime, they could still opt out of tokio and opt in to whatever they like. The freedom of choice would not be hindered, but we would gain a default runtime.

What’s stopping this from happening?

Do you mean compiler running on the Watch? Because the compiled code is no longer Rust and therefore there is no reason why it should not run on the Watch. Or do you mean specifically applications with the Rust library Egui?