Email or username:

Password:

Forgot your password?
13 posts total
yosh

Regular reminder that Bluesky is a VC-funded company which inevitably is headed for the same fate shared by all VC-funded companies. It must maintain hypergrowth until it either:

- folds
- sells
- IPOs

Maybe tuning into another re-run of the social media VC show is appealing to some, but it certainly isn’t for me.

yosh

Headline: “Wow, Bluesky managed to get $8 million in funding”

What you should be reading:

“Bluesky took on an additional $8 million in debt, which they will need to be pay back with interest one way or another”

How are they going to be doing that, you wonder? Well reader, certainly not just by selling domain names at a slight markup.

yosh

Writing RFCs is just producing programming language fan fic.

yosh

(I don't know if I came up with this, or I'm remembering someone else writing this a while back. But either way I'm sitting here giggling at this)

yosh

I found this via Alex Crichton:

A new paper has been published fuzzing Rust’s new Cranelift backend. Being relatively new compared to the LLVM backend, the author hypothesized that it would likely be more buggy.

But nope, not at all. They were unable to find *any* new bugs using their fuzzer (Rustlantis). While that doesn’t mean Cranelift is free from bugs, it’s still a strong signal for how reliable we can expect Cranelift to be.

ethz.ch/content/dam/ethz/speci

I found this via Alex Crichton:

A new paper has been published fuzzing Rust’s new Cranelift backend. Being relatively new compared to the LLVM backend, the author hypothesized that it would likely be more buggy.

But nope, not at all. They were unable to find *any* new bugs using their fuzzer (Rustlantis). While that doesn’t mean Cranelift is free from bugs, it’s still a strong signal for how reliable we can expect Cranelift to be.

Show previous comments
Aiono

@yosh
This can be a good use case to argue favor of formal tools in software development that it actually allows you to develop faster and fewer bugs at the same time.

yosh

To the surprise of nobody whose worked on any collaborative projects at scale — people with toxic styles of engagement burn out the people actually doing the work and negatively affect the entire project.

This paper is specifically about Wikipedia, but like no shot this doesn’t apply to open source as well:

academic.oup.com/pnasnexus/art

Show previous comments
Joan Westenberg

@yosh Astute. And it's also why every DAO has fallen over in the crypto space.

John Allsopp

@yosh will attest that it occurs frequently in my experience in volunteer organizations of all kinds.

yosh

I surprised someone again yesterday by saying that I legitimately don’t think technical issues are the hard part of shipping projects.

I find the constraints are almost always about how to navigate conflicting points of view, deadlines, organization, planning, and budgets. People, planning, and money are the hardest topics. The technical parts seem far less difficult -sometimes even trivial- in comparison.

Show previous comments
The Luddite

@yosh Agreed. I start every client relationship by explaining that every engineering problem is actually a people problem.

ティージェーグレェ

@yosh agreed.

Many places I have worked where they had basically no budget available for projects.

If I could propose a solution that didn't cost them anything, no need for a CapEx budget process to go through, it was a win!

Scrounging around for unused resources (e.g. older hardware) and finding suitably licensed libre/free open source software to run which with some configuration could solve things, meant they were just paying me for my time which they were already doing, and what I was able to present them with to do what needed doing was icing on the cake.

Once upon a time, I also worked for an early online adult content producer. Due to puritanical reasons, some companies would not sell us their products, so once again getting to create in-house alternatives (again, with my preferences for building on top of libre/free open source software) while sometimes NIH syndrome was something which I was able to excel at in getting problems solved, even in instances where "the market" maybe had products, we just were prohibited from purchasing them.

The organizations which can simply buy their way out of whatever needs doing? Probably aren't solving any novel problems in my experience. They're pretending to be businesses while actually just being apex consumers and marketing facades.

The number of companies which simply rebrand some ODM/OEMs' products as their own (e.g. "Amazon Basics" Costco's Kirkland, Alienware, etc.), are indicative of such lack of innovation. In such instances what they are really involved with is branding and margins focused marketing. They don't innovate, so their strategies mimic monopolies so they can push out competitors.

Lamentably, I've also been a contributor to products which have been "white labelled" and resold to others. In some instances, I have observed downstream bugs which were things fixed years earlier, because the downstream clients never grew a clue. Most live streaming for example, to me, is in such a state these days. ;(

@yosh agreed.

Many places I have worked where they had basically no budget available for projects.

If I could propose a solution that didn't cost them anything, no need for a CapEx budget process to go through, it was a win!

Scrounging around for unused resources (e.g. older hardware) and finding suitably licensed libre/free open source software to run which with some configuration could solve things, meant they were just paying me for my time which they were already doing, and what I was able to...

yosh

"An approach to computing and sustainability inspired from permaculture" by @neauoire is a lovely talk which I very much think is worth watching

youtu.be/T3u7bGgVspM

yosh

Holy shit, Rustc (via Ferrocene) being ASIL-D certified is a huge deal! That’s the highest level of verification for automotive applications, which enables it to be used in stuff like braking, steering, and other critical vehicle systems.

I had absolutely no idea what any of the standards were about. But now that I understand what they are, that seems huge! Amazing work by @ferrous!

ferrous-systems.com/ferrocene/

Show previous comments
Mythmon

@yosh What's a ConstAsyncFn? A compile time result for something in the future? Are all of these combinations something that makes sense to use in some situation?

yosh

Writing actual code again for the first time in what feels like… weeks? Months? I honestly don’t know anymore lol.

On the brighter side: maybe I’ll soon have shaved enough yaks that I can continue building out my personal website. Current yak shave: parse the various HTML specs and create a semantically meaningful representation of it in Rust. Aka step 1 of:

blog.yoshuawuyts.com/compiled-

Hazel Weakly

@yosh I love this :)

I'm gonna be super interested in what you're doing here! I've been thinking for a long time that the web needs this sort of thing and I am extremely stoked that you're poking away at it

caleb

@yosh imo #astrodotbuild w/ types gets you part of the way there, though obviously w/o various #a11y or other linters you're not going to get *validity* tested

yosh

What if…

[uncomfortable looks]

… certain problems are systemic…

[a member of the audience lets out an audible gasp]

… and require systemic solutions.

[shock, horror, people frothing with rage]

yosh

“Better things are possible”, I yell, as I’m dragged off the stage.

yosh

New post: Rust 2023

I took some time to share my thoughts on Rust in 2023; what we're working on, what I think is important, and how I'm thinking about the project.

blog.yoshuawuyts.com/rust-2023

Gustav Wengel

@yosh some really interesting thoughts on automation and a great example with cargo-semver-checks!

nora on the weirder earth

@yosh this post is great, thank you for sharing! I'm especially enthused by the way you talk about continuing to be ambitious - I completely agree and I think there is so much more interesting space to cover!

Go Up