lock-free

If I've learned anything from cloud services, it's that product names mean nothing.

I was just checking the build times from your github repo by running cargo build. If I used it in a project it would be multi-language and require linking against native code through a C shim. It would be great if that was provided and had a stable ABI + .so for the rust code that I could install through a .deb or .rpm instead of building through cargo.

> Though we are pretty lean on dependencies, and I would expect most projects using oso would be using serde anyway.

It would be great if `serde` was opt-in through cargo features, which is pretty common in the Rust ecosystem. While your manifests are small there's still quite a bit getting pulled in. Might want to inspect the dependency graph to see if there's anything excessive or some features that can be non-defaulted.

> That being said those times you're seeing seem very long, even for Rust!

Not in my experience. This was a clean debug build. It's not that uncommon on CI runners to have much longer times than developer machines (MacOS CI runners are especially bad about this, and also cost a lot more money). That's why I do profiling on a weaker one when evaluating build times. Incremental builds are faster, they're also harder to orchestrate.

Not trying to be overly critical, just trying to give a view! Compiling on other people's machines is expensive, a good way for me to buy into something like this instead of doing it myself (which is how I'm doing it right now!) is to reduce the dependency tree and make building stupid fast/easy.

I'd like to buy into Rust for authentication, but the compile times cost too much money and I wound up purging it.

This library needs a lot of work to speed up compile times before I can use it. Procedural macros are usually opt-in through cargo features because of their extreme hits to compile time (this includes stuff like serde), and if you're trying to monetize this I'd recommend having precompiled binaries available somewhere so I don't need to pull things from crates.io to compile it cold.

I timed it on a laptop that I know to have similar power to a CI runner. This is after `cargo build`:

real 5m16.508s

user 10m41.961s

sys 0m44.432s

> The "one place" to find businesses is your local search engine

What businesses want is to show you these things without your explicit desire to find them, which isn't the "one place" a search engine needs to be.

I think 'stateless' is better jargon that conveys what the servers can/can't do when rolling out a service using them.

thanks for the suggestion!

I work with a lot of "non software" engineers that write a lot of software.

To paraphrase an exec at a meeting some time ago, "every company is a software company - some haven't realized it yet" (this was in the context of a moderately sized domestic manufacturer).

There's obviously a difference between production software engineering and day to day scripting, but if you're not heavily investing in developing software skills for engineers of all trades you're losing a lot of ground in design and production automation to competitors.

So I would say that there isn't a transition so much as a decision, just start coding parts of your job. Decent rule of thumb is never do the same task more than twice.

There's also tons of value in being a domain expert that can read and write code - if you're in a highly technical field there's almost certainly a company trying to automate your expertise. Try and find the people doing it and help them out!

I'm playing on a Ryzen 3800x, a GTX 2060 Super with 32GB of 3600 MHz Ram. I think the game looks bad (with playable settings) and hasn't been compelling enough for me to sink that much time into it, while the missions are pretty grindy.

I'd say play GTA V and the Witcher 3 for a comparison in immersive open world story telling and high caliber graphics. I haven't played Spiderman (2018, 2020) but in gameplay footage (which is only on console) it looks much better as well.

I feel like I'm crazy when I say that the graphics are incredibly underwhelming. It looks good, and there's neat stuff. But I don't care how pretty a shadow looks when the hundreds of NPCs walking around look so rough.

Back in my day we threw up PHP scripts using apache and called it a day...

But seriously custom runtimes are real bastards to get working.

> Because it's a waste of very expensive time to develop native desktop apps in 3 different platforms?

and yet the latest-and-greatest cross platform framework is supposed to be Flutter

> Drive’s search is so poor that it’s often easier to get a colleague to resend the invite to a doc than it is find the thing via search.

For a search company, it's embarrassing how hard it is to search for things in their office suite.

Kind of an example of a "bigger fuck up" I was alluding to

Assume that secrets are going to be leaked or discovered and change them regularly. Everything else is a delay tactic, people mess up (or get tricked into messing up).

The article/twitter thread don't offer anything definitive. It could be this leaked password was how their supply chain got compromised, it might not be.

Just anecdotally I'm looking at my own release infrastructure and it would take a bit more work to get compromised binaries to our customers than a leaked secret in a public git repo - and if it was reported that we leaked some key or password that gave the keys of the kingdom away, it would be trivial to change it and verify that we didn't push malware.

This article can explain how malware made it into a download server, maybe. But does it explain the fact the malware was signed? Maybe, but that suggests a bigger fuck up than leaking a password.

I was replying to the comment you made about XCode not running on other platforms. That's neither here nor there. My point is it is not a good developer experience for anything but client apps on their operating systems - things like iOS apps and consumer programs, not web design, backend engineering, high performance computing or the slew of other kinds of software that Macs are getting worse at.

This goes deeper than developer tools. The documentation for their core frameworks have been purged from official sources and is relegated to deprecated sites and comments header files tucked away in /Library. Kernel modules are being deprecated. There's no alternative to IPP or MKL on ARM for the M1 chip. Docs for plugins architectures are being more and more hidden away, and Apple's Developer Conference consistently only focuses on consumer facing applications - while support for professional applications and advanced computing is only available if you work for a partner organization, making it less accessible.

The reason I say that Apple is making their platform harder to use for general purpose computing is from my experience shipping code on MacOS for the last decade. It's fine if you disagree, but that hasn't been my experience. Every year it costs me more time and money to target Macs than the year before.

General purpose development includes more than developing applications for Apple devices.

XCode is a good example of what I mean. It's a terrible developer experience for anything but targeting Apple's platforms in the way you want to (meaning writing Swift, using their frameworks, and their devtools, and keeping your code base small to keep their devtools functional, and never caring about that code running on a different OS).

Compare to Visual Studio, which also only runs on Windows, yet is a pretty damn good developer experience and not a nightmare to support for cross platform projects of late.

AVX 512 isn't available on consumer CPUs, it's not relevant here.

I think Apple is banking on coprocessors on their SoC to handle heavy workloads instead of general purpose SIMD. The applications that benefit enormously from SIMD outside the GPU (like ML, multimedia codecs, etc) are being migrated to proprietary function blocks interfaces through Swift frameworks, and not hand rolling optimized blocks of code in C and assembly.

I would not be surprised if we see similar things added for audio DSP to support their creative software (it was alluded to in some marketing materials, haven't read much on it yet).

Other applications like language parsing and compiling is likely going to be a second class citizen moving forward, since Apple doesn't care about using their machines for general purpose development regardless of how many of us buy them for being solid Unix platforms.

Forgive me for not pitying the poor conservative, who has controlled the legislature for a decade, the White House for a term, and the Supreme Court for decades to come.

McCarthyism has little bearing on current political realities other than a passing resemblance.

I don't see a functional difference in denying spaces in paths from denying new lines in paths.

My dream OS would forbid path names that don't match \w in grep.

Who wants mass consumer appeal? Consumers don't pay for things.

Discord has like a $2billion valuation and no exit. Slack had a $24 billion IPO. Consumer software is not as valuable as enterprise.

Not until the population is vaccinated, like polio, smallpox or most other diseases where you can be reinfected...

Discord isn't enterprise software and I feel really bad for anyone who wants to use it as such. Microsoft Teams is without a doubt the only thing threatening Slack, Discord is an entirely different beast.

Shared channels are a godsend for startups trying to figure out their support story. Forums have been long known to suck, shared channels are much more responsive.

There are obvious downsides but the benefits outweigh them. I really don't want to go back to forums and email for customers.

What was the typical tenure of a Fortune 500 CEO in the 1950s?

It's less than tone deaf, it's plain ignorant. As much as I find Musk's unabashed ego distasteful, he has actually built companies and hired thousands of people. Musk is a doer - and you know the old saying about "those who can't do, teach." So if we're appealing to authority, I'll take Musk's over "business-school leaders."

Side note: I've rarely met a top b-school grad who could say they valued much taught during their MBA (aside from statistics). The consensus is usually that it's a great networking opportunity.

I've been using it in C/C++ projects going back at least 15 years, I thought it was commonplace for every language

Salaries are negotiated with far less information on one side and with less vigor than contracting rates, so that doesn't surprise me. If every hire knew what you paid every one of your reports, and they did likewise, the bands would probably be narrower.

That's a bad comparison and I'm not sure why people are making it - you're mistaking fundamentals. This isn't a UI problem, it's datastructures and algorithms. There are plenty of desktop apps with similar issues (representing a complex problem as a set of constraints and writing a solver to find a solution, and querying the solution for the data to display to a user).

I don't reject that there are troubles in concerting real world data into a representation for the constraint solver. But this isn't untrodden ground, and there's no reason a front end developer should need to care about it. The problems you're describing are far behind the UI; and if they're not your organization has immense problems.