u/ManningBooks

Hi r/learnrust,

I’m posting on behalf of Manning Publications, with the mods’ permission.

We just released Embedded Software with Rust by Dr David Cabanis, and we’re giving away 5 ebook copies in this thread.

Book page:
https://www.manning.com/books/embedded-software-with-rust

The question I’d love to ask this community is:

What was the first Rust concept that made sense in a normal project, then became confusing again when you imagined it running on a microcontroller?

For a lot of people, embedded Rust is where the language stops being abstract. Ownership is no longer just about avoiding memory bugs in an app. It becomes a way to say: this timer belongs to one part of the program. This GPIO pin has been configured into this mode. This interrupt handler and the main loop cannot casually mutate the same state.

That’s the heart of this book.

Embedded Software with Rust is a practical guide to writing bare-metal firmware with Rust. It starts from the basics of embedded Rust setup and builds toward the parts that usually make people reach for scattered blog posts: no_std, linker scripts, startup code, vector tables, interrupts, memory-mapped I/O, PACs, HALs, BSPs, debugging, emulation, and safe sharing between main code and interrupt handlers.

A few topics covered:

• setting up an embedded Rust toolchain
• building and inspecting no_std binaries
• what happens from reset to main
• Cortex-M startup code and vector tables
• linker scripts, memory.x, .data, .bss, stack placement, and memory layout
• interrupts and safe data sharing
• PACs, HALs, BSPs, and embedded-hal
• flashing and debugging with OpenOCD, probe-rs, GDB, QEMU, and cargo-binutils
• Rust/C integration for existing firmware codebases

The book is written for people who know basic Rust and want to understand how Rust behaves when there’s no operating system underneath it. It should also be useful if you come from embedded C/C++ and want to see what Rust changes in firmware design.

Dr David Cabanis is Principal Engineer at Doulos, with deep experience in Arm embedded software, FPGA and SoC design, and system-level modeling. The book focuses mainly on Cortex-M, with selected RISC-V examples that help explain the ideas.

Giveaway

We’ll give 5 ebook copies to the top 5 commenters in this thread.

To enter, comment with one of these:

• the embedded Rust topic that confuses you most
• the microcontroller or board you’d like to try Rust on
• a Rust concept that finally clicked for you
• a firmware bug you wish the compiler had caught
• what you’d build first if the embedded setup were already done

For anyone who wants the book now, Manning has also made a 50% discount code for this community:

MLCABANIS50RE

I’ll be around in the comments, and I can bring the author to answer questions. I’m especially curious how many people here have tried no_std already, and how many are still waiting for the right project to make the jump.

Thanks for having us.

Cheers,

Stjepan

Hi r/mlops,

Manning here. We got the mods’ permission to share this.

We’ve just opened early access for Quantization and Fast Inference: A practitioner’s guide to efficient AI by Vivek Kalyanarangan.

Book page: https://www.manning.com/books/quantization-and-fast-inference
Community discount: MLKALYANARANGAN50RE for 50% off

This one should be especially relevant to folks here because it’s focused on the deployment side of quantization, not just the math. The book is written for ML engineers and researchers who already know Python and are dealing with the usual production headaches: models that are too large, inference that is memory-bound, GPU utilization that looks wrong, latency that refuses to move, KV cache pressure, and serving costs that keep creeping up.

The book starts from first principles, deriving the affine quantization mapping with scale and zero-point, then moves into the decisions that tend to matter in production:

• when PTQ is enough, and when QAT is worth the trouble
• how to build calibration sets that actually match production traffic
• absmax vs percentile vs MSE range estimation
• per-tensor, per-channel, group-wise, and block quantization
• weight, activation, and KV cache quantization
• activation outliers in transformers
• LLM-specific tradeoffs like KV cache memory growth
• lower-bit formats such as NF4 and FP4
• packaging and runtime concerns across CPUs, GPUs, edge, and mobile

A big theme of the early chapters is that modern inference is often limited by memory movement rather than raw compute. The book walks through concrete examples, such as how a 7B model’s weights and KV cache can dominate per-token memory traffic, and why reducing precision directly reduces footprint and bandwidth.

The current MEAP includes the foundations and PTQ/calibration material, including chapters on:

1. Facing the efficiency wall
2. Building quantization from first principles
3. Choosing what to quantize and at what granularity
4. Applying post-training quantization and calibration

Upcoming chapters go deeper into QAT, cross-framework workflows, LLM quantization, low-bit formats, toolchains, CPU/GGUF deployment, edge/mobile, and capstone projects.

Giveaway

We have 5 free ebooks to give away to the top 5 commenters in this thread.

To keep it useful for the community, comment with one of these:

• a quantization/deployment problem you’re currently dealing with
• a failure mode you’ve hit with PTQ, QAT, ONNX Runtime, TensorRT, llama.cpp, etc.
• a question about calibration, KV cache quantization, activation outliers, INT4/NF4/FP4, or runtime packaging
• what you’d want a practical quantization book to cover that most resources skip

We’ll pick the top 5 comments after the thread has had time to run and send codes by DM.

And again, the 50% discount code for anyone who wants it is:

MLKALYANARANGAN50RE

Curious what people here are seeing in production: are you mostly using weight-only quantization for memory savings, or are you pushing full INT8/INT4 paths with quantized activations as well?

Thanks for having us.

Cheers,

Stjepan

Hi all,

Stjepan from Manning here. The mods said it's fine if I post this here.

I wanted to share a new MEAP (early access) release we think will land well with people here: Quantization and Fast Inference by Kalyan Aranganathan: https://www.manning.com/books/quantization-and-fast-inference

Quantization and Fast Inference

A lot of ML deployment discussions still revolve around model quality first and infrastructure second. Then the bill shows up. Or latency becomes unacceptable. Or the model that worked fine on A100s suddenly needs to run somewhere much smaller.

This book focuses on the practical side of making models cheaper and faster without rebuilding them from scratch. It starts with quantization fundamentals and works its way through PTQ, QAT, runtime packaging, and deployment trade-offs that matter once you’re dealing with production constraints rather than benchmarks.

What I liked about the manuscript is that it doesn’t stop at “here’s INT8.” It gets into the annoying details people usually learn the hard way: activation outliers in LLMs, KV cache pressure, fake quantization workflows, straight-through estimators, and why some sub-8-bit formats behave very differently once you leave the paper and hit actual inference workloads.

There’s also a solid balance between theory and implementation. The derivations are there if you care about the math, but the book keeps returning to operational questions like memory bandwidth, latency, and deployment cost.

Since this is a MEAP release, the book is still being developed chapter by chapter, and readers get access to the manuscript as it evolves. We’ve found that ML books especially benefit from that process because readers often push authors toward clearer explanations and more relevant examples while the book is still in progress.

We’ve got 5 free ebook copies for the first 5 people who comment with their experience using quantization in production or research. Success stories, failed experiments, weird edge cases — all fair game.

If you’d rather grab it directly, we also put together a 50% discount code for the subreddit: MLKALYANARANGAN50RE

Curious what people here think the current pain point is with quantization workflows.

Accuracy collapse? Tooling fragmentation? Hardware-specific behavior? Something else entirely?

I’ll stick around for discussion, and I’m happy to bring the author in for questions if there’s interest.

Cheers,

Stjepan

Hi r/Pentesting ,

Stjepan from Manning here, and I wanted to share something we’ve been working on that feels very relevant to where offensive security is heading right now: AI Agents for Offensive Security by Mark Foudy: https://www.manning.com/books/ai-agents-for-offensive-security

The mods said it's fine if I post this here. I’ll keep it grounded in what matters for this sub.

AI Agents for Offensive Security

A lot of the AI + security discussion online is either hype or surface-level tooling. What this book tries to do is show how AI actually fits into day-to-day offensive workflows without pretending it replaces the human doing the work.

It walks through building agents that can:

• support recon and data collection without turning into blind automation
• Help with triage when you’re buried in findings
• assist in vulnerability discovery, especially in messy, real-world targets
• Generate structured reports that don’t need a full rewrite afterward

There’s also a big focus on how not to shoot yourself in the foot. Things like:

• keeping actions auditable (so you know what your agent actually did)
• putting guardrails around scope and authorization
• understanding where AI introduces risk instead of reducing it

The multi-agent pipelines part is interesting too. Instead of one “do everything” agent, the book breaks workflows into smaller pieces that pass artifacts between each other. Closer to how a real engagement works, just with some of the repetitive work offloaded.

Giveaway (keeping it simple):

• 5 free ebook copies
• First 5 people who comment with their experience (or skepticism) about using AI in pentesting workflows
• I’ll DM the winners

If you’d rather just grab it, we’ve got a 50% discount for the sub: PBFOUDY50RE

I’d actually like to hear where people stand on this.

Are you already using AI in engagements in any meaningful way? Not ChatGPT for quick commands, but something closer to workflow integration.

Or have you tried and backed off because it introduced more noise than signal?

Happy to discuss, and if there’s interest, I can bring the author in for a proper Q&A.

It feels great to be here. Thanks for having us.

Cheers,

Stjepan

Hi everyone,

I’m Stjepan from Manning, and with mods' approval, I wanted to share a book we’ve been working on: High Performance Unity Game Development by Nitzan Wilnai: https://www.manning.com/books/data-oriented-design-for-games

High Performance Unity Game Development

Before dropping the link and disappearing, I’ll explain why this might actually be useful here (and how it’s different from a lot of the free Unity material out there).

Most Unity content - including Unity’s own ebooks - focuses on how to use features. This book is more about how to think about performance from the ground up, especially when your project starts hitting limits.

It leans heavily on Data-Oriented Design (DOD). If you’ve ever:

• hit a wall with MonoBehaviours everywhere
• struggled to keep frame rates stable on lower-end devices
• or tried ECS and felt like it didn’t quite “click”

…this is the kind of material the book digs into.

It walks through building a full game while reshaping the architecture around data instead of objects. Arrays over hierarchies, systems over inheritance, fewer hidden costs. There’s also a lot of practical discussion around CPU behavior, memory layout, and why certain patterns break down as your game scales.

This isn’t tied only to Unity DOTS either. The ideas carry over even if you’re still working in a more traditional setup or doing 2D projects where performance bottlenecks show up differently (lots of entities, tight update loops, mobile constraints, etc.).

Giveaway (mods asked for clear terms, so here they are):

• Prize: 5 free ebook copies
• How to enter: Comment with your experience (or frustration) around performance in Unity — especially in 2D projects
• Eligibility: Anyone in the subreddit
• Deadline: 48 hours after this post goes live
• Winners: First 5 meaningful comments (not just “I’m in”)
• Note: This giveaway isn’t affiliated with or sponsored by Reddit

If you don’t want to rely on luck, we’ve also got a 50% discount code: PBWILNAI50RE

I’d actually like to turn this into a discussion rather than a drop-and-run:

Where do you typically start to notice performance issues in Unity2D?

Too many sprites? Physics? Update loops? Something else entirely?

Let me know.

It feels great to be here. Thanks for having us.

Cheers,

Stjepan

Hi r/Unity3D,

Posting with mod approval from Manning. I’ll try to make this worth your time and not just another promo post.

We recently published High Performance Unity Game Development by Nitzan Wilnai
https://www.manning.com/books/high-performance-unity-game-development

High Performance Unity Game Development

A lot of Unity’s official material (and most tutorials out there) focus on how to use the engine well. This book comes from a slightly different angle: how to structure your code so performance doesn’t fall apart later.

If you’ve ever:

• hit a wall trying to optimize something that “shouldn’t be slow”
• wrestled with MonoBehaviour-heavy architectures that got harder to extend over time
• looked at ECS/DOTS and thought “I get the idea, but how do I actually design around this?”

- then you’re already in the territory this book covers.

It’s centered around Data-Oriented Design (DOD). Not just “use arrays instead of objects,” but how thinking in terms of data layout changes the way you design systems. The book walks through building a game step by step (a survivor-style project), showing how decisions around data shape performance, memory access, and even how easy it is to add features later.

One thing that stood out to me is that it doesn’t treat ECS or DOD as magic fixes. It shows where they help, where they add complexity, and how to apply those ideas even if you’re not going all-in on DOTS.

That’s probably the biggest difference compared to Unity’s free ebooks: those are great for learning features and workflows; this one is more about why your architecture behaves the way it does when things scale.

I’m curious how people here are approaching performance right now:

• Are you sticking with classic OOP + optimizations when needed?
• Moving parts of your project to ECS/DOTS?
• Or avoiding that shift because of complexity/tooling concerns?

Would be great to hear what’s actually working for you in production or even in side projects.

Also, we’ve got 5 free ebooks to give away. First 5 people who comment with how they’re handling performance (or a problem they’re stuck on), I’ll send you a copy.

And if you want to grab it directly, you can use PBWILNAI50RE for 50% off.

It feels great to be here. Thanks for having us.

Cheers,

Stjepan