mrkline

6 ms·

1.
by mrkline 3y ago
That's my main goal - and Rust seems like the language where we can have our cake and eat it too! The standard library has some amazingly performant data structures and algorithms. Talking to one of the hyper developers, a lot of this
2.
by mrkline 3y ago
Turns out we regularly play flight sims together on weekends, but didn't know about each others' software misadventures - small world, isn't it? If the reason I blogged about my coding hobby was to "get my 15 minutes on
3.
by mrkline 3y ago
The article got me in touch with one of the hyper devs, and we had a very friendly conversation that taught me a lot. If questioning some design decisions and calling a marketing blurb a little disingenuous is mocking and condescending, the
4.
by mrkline 3y ago
> If a library has 100k lines of code but the parts you use are only 1k lines of code then why is that worse than a library with 1k lines of code? There's nothing wrong with not using the whole feature set of some library. But if li
5.
by mrkline 3y ago
- Like others have said, both malloc()/free() touch a lot of global state, so you either have contention between threads, or do as jemalloc does and keep thread-local pools that you occasionally reconcile. - A moving (and ideally, ge
6.
by mrkline 3y ago
Go's GC is hardly state of the art.
7.
by mrkline 3y ago
It's great! But there's nothing about it that requires futures. It really annoys me that something like this isn't built-in: https://github.com/mrkline/channel-drain
8.
by mrkline 3y ago
> Async/await was a terrible idea for fixing JavaScript's lack of proper blocked threading that is currently being bolted onto every language. As fun as it is to hate on JavaScript, it's really interesting to go back and w
9.
by mrkline 3y ago
Hoare Was Right. (But if you're only firing up a few tasks, why not just use threads? To get a nice wrapper around an I/O event loop?)
10.
by mrkline 3y ago
> The lifetime of an Arc isn’t unknowable, it’s determined by where and how you hold it. In the same sense that the lifetime of an object in a GC'd system has a lower bound of, "as long as it's referenced", sure. But
11.
Maybe Rust isn’t a good tool for massively concurrent, userspace software(bitbashing.io)
704 points by mrkline 3y ago|613 comments
12.
What every systems programmer should know about lockless concurrency [pdf](assets.bitbashing.io)
2 points by mrkline 9y ago|0 comments
13.
TeX: A tale of two worlds(bitbashing.io)
3 points by mrkline 9y ago|0 comments
14.
by mrkline 10y ago
Hopefully that fixes it. Sorry I suck at CSS.
15.
by mrkline 10y ago
Is it better now?
16.
Comparing Floating-Point Numbers Is Tricky(bitbashing.io)
73 points by mrkline 10y ago|41 comments
17.
by mrkline 10y ago
You're really making a bunch of uncharitable assumptions about our situation. First, you assume that this behavior isn't well understood, well documented, and even expected in my organization and our corner of the industry. The re
18.
by mrkline 10y ago
I would _love_ to write our firmware in Rust, but that's a much bigger sell than moving from C to C++.
19.
by mrkline 10y ago
I don't follow. If an allocator is optimized for our needs (i.e., allocating everything up front and never freeing), and is easier to set up than the general-purpose allocator in newlib, how is using it "technical debt"?
20.
by mrkline 10y ago
IIRC, the concern was in the details of newlib's allocator. Its sbrk looks for a linker symbol, then starts slicing memory off of that address. There were worries that unless we were careful, it might stomp on FreeRTOS. (These worries
21.
by mrkline 10y ago
Great! But when you have hard timing requirements measured in microseconds, you generally need some fine-grained control over the instructions the CPU ends up running. All the knobs and levers C and C++ offer you are quite useful here.
22.
by mrkline 10y ago
Great points. In our cases, these objects were few in number and were accessed infrequently through a pointer, so I don't think there's much to be concerned about. Avoiding unnecessary vtables is definitely something to keep in mi
23.
by mrkline 10y ago
The main issue with just using newlib's allocator is that we're using FreeRTOS, and (AFAIK), there isn't a good way to make the two aware of each other. One could also probably hook operator new up to to FreeRTOS, but we try
24.
by mrkline 10y ago
> inadvertent copy constructor/assignment operator calls This is much less of a problem (and much more controllable!) now that we have move semantics. > automatic memory allocs It's hard to accidentally allocate memory if yo
25.
by mrkline 10y ago
I'm incredibly interested in getting Rust into embedded devices, but it's a much larger sell than moving from C to C++14. And how will C++17 onward be so much different? C++11 was a huge inflection point, no doubt, but the stand
26.
by mrkline 10y ago
> you just need to start from this point if you know your environment is really constrained and exceptions are too much of a cost - which is usually not the case in modern embedded ARM systems. ARM systems really run the gamut these days
27.
by mrkline 10y ago
The main motivation is just that experienced C++ devs (myself included) have the rule, "base classes should have virtual destructors" drummed into their heads. Defining operator delete (even if the compiler elides it since, like y
28.
by mrkline 10y ago
The approach I laid out makes sure that the constructors for all of your global/static objects get called. AFAIK, there's no reason you couldn't do everything "by hand", but it seems like a lot more work for questio
29.
by mrkline 10y ago
Author here - thanks! I left out advice like, "turn on all the warnings" because I was trying to focus on problems specific to embedded platforms. I'd strongly argue advice like that that is great regardless of what your ta