<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Tanmay</title>
    <description>The latest articles on DEV Community by Tanmay (@nonnonhere).</description>
    <link>https://dev.to/nonnonhere</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3982594%2Fa402ac2b-7ee7-4fdf-9227-ceadeba9fb6e.jpg</url>
      <title>DEV Community: Tanmay</title>
      <link>https://dev.to/nonnonhere</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/nonnonhere"/>
    <language>en</language>
    <item>
      <title>Kicking off GSoC: Under the Hood of PR #352 of serialport</title>
      <dc:creator>Tanmay</dc:creator>
      <pubDate>Sun, 14 Jun 2026 07:43:22 +0000</pubDate>
      <link>https://dev.to/nonnonhere/kicking-off-gsoc-under-the-hood-of-pr-352-of-serialport-452d</link>
      <guid>https://dev.to/nonnonhere/kicking-off-gsoc-under-the-hood-of-pr-352-of-serialport-452d</guid>
      <description>&lt;h2&gt;
  
  
  About Serialport:
&lt;/h2&gt;

&lt;p&gt;The serialport-rs library is a foundational cross-platform crate that enables Rust applications to communicate directly with hardware via serial ports. It serves as a vital bridge in the Rust embedded and robotics communities, allowing developers to reliably interface host machines with microcontrollers, sensors, and autonomous systems. To kick off my Google Summer of Code journey, my PR (&lt;a href="https://github.com/serialport/serialport-rs/pull/352" rel="noopener noreferrer"&gt;#352&lt;/a&gt;) overhauls the codebase by stripping out the library's legacy dynamic dispatch architecture in favor of a faster, strictly encapsulated concrete implementation.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Death of &lt;code&gt;Box&amp;lt;dyn SerialPort&amp;gt;&lt;/code&gt;
&lt;/h2&gt;

&lt;p&gt;Maybe the most prominent feature of this version of the library is the elimination of the &lt;code&gt;Box&amp;lt;dyn SerialPort&amp;gt;&lt;/code&gt; type. Before, much use was made of trait objects within the framework of dynamic dispatch to deal with various ports. This was an efficient solution, although it came with some overhead in the form of run-time costs and awkward APIs.&lt;br&gt;
Elimination of dynamic dispatch allows us to take full advantage of all that the compiler can do for us from optimizing our code to performing inline substitution where possible. In essence, this results in a more robust library with a nicer API overall.&lt;/p&gt;
&lt;h2&gt;
  
  
  Unifying the Structs and Hiding the Internals
&lt;/h2&gt;

&lt;p&gt;Platform-specific implementations, such as &lt;code&gt;TTYPort&lt;/code&gt; in the case of POSIX systems and &lt;code&gt;COMPort&lt;/code&gt; in Windows, were directly exposed to the outside world. The result of this approach was that OS-specific implementation details were getting leaked into user space, thus breaking a fragile contract between the library and its users&lt;br&gt;
PR #352 fixes this by unifying the platform-specific implementations into a single, clean public interface:&lt;br&gt;
&lt;/p&gt;

&lt;p&gt;&lt;code&gt;pub struct SerialPort(pub(crate) sys::SerialPort);&lt;/code&gt;&lt;br&gt;
&lt;/p&gt;

&lt;p&gt;Both &lt;code&gt;TTYPort&lt;/code&gt; and &lt;code&gt;COMPort&lt;/code&gt; have been removed completely from the public API. As a result, we have provided the maximum amount of freedom for future refactoring to the people who will be maintaining the library in the future by ensuring that we can now change how things work internally without worrying about breaking downstream code that relied on those specific struct names.&lt;/p&gt;

&lt;h2&gt;
  
  
  The POSIX Extension Trait
&lt;/h2&gt;

&lt;p&gt;However, once again there appeared a new problem. How can we make platform specific implementations available when all is encapsulated in our new &lt;code&gt;SerialPort&lt;/code&gt; struct?&lt;br&gt;
And the very nice way to deal with this situation was the introduction of extension traits. The platform specific methods such as &lt;code&gt;.pair()&lt;/code&gt; and &lt;code&gt;.exclusive()&lt;/code&gt; have been moved into the new trait &lt;code&gt;SerialPortExt&lt;/code&gt;. Thus, the SerialPort itself remains cross-platform but you can add POSIX abilities if necessary.&lt;/p&gt;

&lt;h2&gt;
  
  
  Re-exporting the Extension Trait
&lt;/h2&gt;

&lt;p&gt;At first, I had implemented the extension feature by putting it in the mod.rs file. But my mentor Sirchel suggested an alternate method where I would implement the code in a separate file and re-export it at the root.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Road Ahead
&lt;/h2&gt;

&lt;p&gt;PR &lt;a href="https://github.com/serialport/serialport-rs/pull/352" rel="noopener noreferrer"&gt;#352&lt;/a&gt; was certainly something which was most needed and was successfully implemented right at the start of the project. With a switch towards concrete types, tight encapsulation, and use of extension traits, there’s been a huge improvement in architecture that we’re dealing with here. Not only is the next generation of serialport-rs way better in performance and security, but it's much more maintainable as well!&lt;/p&gt;

&lt;p&gt;This gives an excellent starting point for the upcoming weeks, and I couldn’t be happier about how things are shaping up thus far!&lt;/p&gt;

</description>
      <category>rust</category>
      <category>linux</category>
      <category>opensource</category>
      <category>github</category>
    </item>
  </channel>
</rss>
