Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
tedmielczarek
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
tedmielczarek
2y ago
Since Volvo was mentioned in the parent comment, did you know that if you buy a new Volvo you can get two free plane tickets to Gothenburg + one night's hotel stay to go pick it up at the Volvo factory? You can drive it around Europe f
2.
▲
by
tedmielczarek
2y ago
I've heard about this being a known issue with cars from other manufacturers, so I can believe it. It's interesting that nobody thought to include a way to let the vehicle know it should stop trying to communicate to handle a pote
3.
▲
by
tedmielczarek
3y ago
I'd encourage you to read up on the component model. The talk by Luke Wagner linked in other comments is incredibly informative if you can make time to watch it. It's not about replacing WASI, it's about providing a coheren
4.
▲
by
tedmielczarek
3y ago
I saw him give this talk at a work event and I fully agree, it's incredibly informative and he presents the material in an engaging way!
5.
▲
by
tedmielczarek
4y ago
We achieved this for Firefox macOS builds years ago. (Greg was there for that work as well. ) You do need to have an SDK accessible, but storing one internally and using it in CI was deemed acceptable. The impact on CI build times was hard
6.
▲
by
tedmielczarek
4y ago
A lot of the weird bits in the Breakpad codebase were definitely from us finding extremely broken minidumps from Firefox users in the wild and then me tweaking the code to see if we could get something out of it so we had a chance at diag
7.
▲
by
tedmielczarek
4y ago
I integrated Breakpad into Firefox to replace the old closed-source Talkback implementation, we shipped it in Firefox 3. I suspect (but would have to ask Mark Mentovai to confirm) that Breakpad was probably written for use in the not-yet-pu
8.
▲
by
tedmielczarek
4y ago
Original rust-minidump author here: I started out by doing a pretty straightforward port of Breakpad into Rust, which I had just started learning at the time. I figured that learning a new language by porting a codebase I was intimately fam
9.
▲
by
tedmielczarek
5y ago
You're right on the mark here. I saw rr used at Mozilla to diagnose and fix flaky tests that failed just often enough in CI to make life miserable, but were nigh-impossible to reproduce in a local development environment. Being able to
10.
▲
by
tedmielczarek
5y ago
I mentioned this in a different thread, but I'd recommend you take a look at Pernosco, a debugging tool written by the original author of rr: https://pernos.co/about/callees/
11.
▲
by
tedmielczarek
5y ago
I haven't personally used Replay, but from my experience using rr (a native debugger that also provides time-traveling features) being able to replay execution both backwards and forwards in time on a whim is amazing . These tools exc
12.
▲
by
tedmielczarek
6y ago
This seems like a very sensible approach. If you're using Rust in an existing Python codebase you might also be interested in trying out PyOxidizer, which has a few nice advantages and tackles distributing the resulting application as
13.
▲
by
tedmielczarek
6y ago
I think Zig is really interesting and has a lot of great ideas, some of which I hope Rust takes inspiration from. They've also done some difficult engineering work to make parts of the development experience feel amazing , like bundli
14.
▲
by
tedmielczarek
6y ago
Rust was originally built with green threads. The RFC that proposed removing them has an extremely detailed explanation of why the change was made pre-1.0: https://github.com/rust-lang/rfcs/blob/0806be4f282144
15.
▲
by
tedmielczarek
6y ago
I agree with you but I don't think that entirely refutes the original point. Baking does require more precision on average than cooking, but bread recipes don't give you the information you would need to be precise. Adjusting for
16.
▲
by
tedmielczarek
6y ago
Having worked with him at Mozilla I can assure you that he is familiar with Rust. I'm as much of a Rust fanboy as anyone, but "rewrite it in Rust" is not a simple process, and there are many tradeoffs involved. That being sai
17.
▲
by
tedmielczarek
6y ago
The biggest limitation for embedded Rust development tends to be "does LLVM support your CPU?" If not you may be able to hack something together but you're not going to have a great time. If so, there's still a broad ran
18.
▲
by
tedmielczarek
6y ago
Here's the thing these arguments always miss: writing C/C++ is like writing your entire Rust program using unsafe. Sure, unsafe Rust code will always exist and can cause memory safety bugs. It's a lot easier to verify a few
19.
▲
by
tedmielczarek
6y ago
Having been significantly involved in the work to integrate Rust into Firefox I can say that while it's definitely nontrivial it's absolutely worthwhile. Every C++ developer I knew at Mozilla that took the time to learn Rust wound
20.
▲
by
tedmielczarek
6y ago
To be clear here, while Servo is a wonderful project and was definitely pivotal in making sure that Rust was useful for building real-world software, calling it "widely-used" is a bit of a stretch. The individual crates that were
21.
▲
by
tedmielczarek
6y ago
Mobile development still has some unfortunate features, like Apple's App Store guidelines limiting the types of apps you're allowed to distribute there, and ever-changing requirements that mean that apps that don't get update
22.
▲
by
tedmielczarek
6y ago
I believe so, yes, but we have customers that wanted to ship their apps as bitcode (for reasons I'm not aware of) so we need to include bitcode in our framework to support that.
23.
▲
by
tedmielczarek
6y ago
> Have you considered the recent alternative, smol [1]? I've been reading Stjepan's articles and am very interested in what he's doing but we haven't seriously looked into alternatives yet. He reached out to me after
24.
▲
by
tedmielczarek
6y ago
I think the build system side is still a bit rough around the edges. It's not hard to get something working, as your examples show, but I haven't seen a solution that feels really well-integrated yet. I'm hoping that tools li
25.
▲
by
tedmielczarek
6y ago
Thanks for the feedback! You're right that describing our usage a bit better might have helped clarify our thinking. For the record: the FullStory product is a session record and replay tool for both web and mobile. We record details a
26.
▲
by
tedmielczarek
6y ago
I think like so many things we tend to turn programming language discussions into something akin to discussing religion. I really like Rust but that doesn't have to take anything away from other languages. I'll have to take a loo
27.
▲
by
tedmielczarek
6y ago
I don't think this really solves any problems for us unfortunately. The core of the bitcode problem is that you need the rustc you're using to have the exact same version of LLVM as the Xcode toolchain you're using, since bit
28.
▲
by
tedmielczarek
6y ago
I don't think there's a bright line dividing systems programming problems between GC and non-GC languages. We use Go extensively at FullStory and it works great for a large class of problems. Rust has a compelling story for spaces
29.
▲
by
tedmielczarek
6y ago
(Hi!) I agree the bitcode situation with Rust is painful. Our SDK isn't open source so we're able to sidestep a lot of that pain but we still do have to be mindful of interop issues with the LLVM version we use to build our SDK an
30.
▲
by
tedmielczarek
6y ago
> Sounds like they could have had the same things with a much easier language like Nim. Unless they are using a lot of Rust exclusive features? I admit that I don't have more than a passing familiarity with Nim. Rust certainly isn&#
More ›