If you were designing a standard library of a high level language (like Rust, C++, etc.) what would it do if while getting the current time of day (e.g. SystemTime::now()) it encountered a failed kernel system call (e.g. to clock_gettime) and why?

What do you think the existing implementations do?

• Return error or raise exception
• Return 0
• Return undefined values (like stack garbage)
• Panic/crash/segfault

I want clean history, but that really means (a) clean and (b) history.

People can (and probably should) rebase their private trees (their own work). That's a cleanup. But never other peoples code. That's a "destroy history"

So the history part is fairly easy. There's only one major rule, and one minor clarification:

• You must never EVER destroy other peoples history. You must not rebase commits other people did.

[...]

If you are working with git together with other people, it's worth a read.

I've been trying to make an RNG that outputs data in a way that has an entropy that approaches a user defined value as the output gets arbitrarily long. I've been struggling at a certain point that I'll detail later, but the main motivation for this project is just trying to practice on a problem like this. Here's my repo.

In this post, we'll be talking about Shannon entropy. Here's a good refresher for it. If you scroll down there's examples and the equation.

Looking at the equation, when developing this algorithm we have two different input values for it: the target entropy and the number of outcomes, n. From there, we can create a probability vector of length n whose entropy is equal to the target entropy, then we can map objects to elements of the probability vector and sample indices from the vector by using the alias sampling method. From there, we have a nice algorithm for creating sequences of any type that have the target entropy.

So where's the problem? It's in actually generating the probability vector. In order to get to a V0, I implemented two functions: helpers::compute_probabilities and helpers::find_lambda. compute_probabilities creates the probability vector that has the target entropy by sampling from the exponential distribution. find_lambda repeatedly calls compute_probabilities using binary search to converge on a lambda that produces a probability vector with the target entropy. The problem line is right here:

    pub fn compute_probabilities(num_outcomes: usize, lambda: f64) -> Vec<f64> {
        let unnormalized: Vec<f64> = (1..=num_outcomes)
            .map(|i| (-lambda * i as f64).exp())
            .collect();

When calculating the actual probability values, they get exponentially smaller as the probability vector gets bigger. This works. Technically. But in the worst way. When sampling using vectors generated using this function, they realistically only sample the first few elements. That's the problem. I want to more equally distribute the probability in such a way that doesn't make the tenth value arbitrarily small but the first value really large in comparison. For reference, using this function and lambda=1, the tenth element in the vector is 5x10^-5 but the first value .37.

I figured I'd post this before I start throwing a bunch of different distributions at this function to see if anyone sees any inherent flaws with my process.

I think it's very interesting, and something i've been looking for for a very long time. Finally a programming language focused on efficiency

Well, I hope you don't have any important, sensitive personal information in the cloud?

However, there are some important features that WinSock just doesn’t expose. […]

Rust’s current async ecosystem is built atop a particularly cursed concept. It’s an unstable, undocumented Windows feature. It’s the lynchpin of not only the Rust ecosystem, but the JavaScript one as well. It’s controversial. It’s efficient. […] Without it, it’s unlikely that the async ecosystem would exist in its current form. It’s called \Device\Afd, and I’m tired of no one talking about it.

“Jujutsu (jj) is a version control system with a significantly simplified mental model and command-line interface compared to Git, without sacrificing expressibility or power (in fact, you could argue Jujutsu is more powerful). Stacked-diff workflows, seamless rebases, and ephemeral revisions are all natural with jj [...]”

Part 2 of the series is out and is here.

cross-posted from: https://lemmy.bestiver.se/post/526967

Comments

Today I published an update to my remote-docker project.

The purpose of this project is to run Docker on a remote computer while providing container access to specific parts of your local filesystem with X11 support.

For example, you can use this to run your browser inside a container and only give it access to your ~/Downloads folder.

Access is over SSH (and SSHFS) and Docker is not installed on your workstation, just a few bash scripts.

Feedback (and patches .. Ha!) welcome.

Have fun!

O

I am a senior java developer in the cloud/distributed arch/ microservice area.

I've touched on golang in the past, but not learnt it in any formal/extensive way.

I see it cropping up in many java/microservice positions, and I'm curious if this is at some point going to overtake java in my area.

The current benchmarks seem to suggest that if autoscaling is key to your services, golang is the way to, well, go.

I looked at the job market and it doesn't yet seem to have taken over, but I'm curious how this is likely to play out over the next decade and if quakus for example is likely to become more competitive against golang. Interestingly, golang specific roles on average pay less than java ones in my area.

Let me know your thoughts or if you have any good articles / content on the subject.

@programming Unpopular opinion: 95% percent of all modern programming langueges are either bloated/proprietary/unneccesarily complex. pretty sure C & assembly can do it all (even for web development, just compile c to WebAssembly)