For yesterday’s NeoSmart.Collections release announcement, we had need of an updated logo for Microsoft’s .NET, and were unable to find something corresponding to .NET Standard.
For those of us that were around when C# was first introduced, this is probably the logo that most represents the .NET Framework:1
I tried extremely hard to find this in a higher resolution or even just losslessly resized, but to no avail. Give me a holler if you have something better we can preserve! ↩
NeoSmart Technologies is pleased to announce the immediate availability of its open source NeoSmart.Collections library/package of specialized containers and collections designed to eke out performance beyond that which is available in typical libraries and frameworks, by purposely optimizing for specific (common!) use cases at the cost of pretty much everything else.
In many regards, the data structures/containers/collections that ship with pretty much any given framework or standard library are a study in compromise. Language and framework developers have no idea what sort of data users will throw at their collections, or in what order. They have no clue whether or not a malicious third party would ultimately be at liberty to insert carefully crafted values into a container, or even what the general ratio of reads to writes would look like. The shipped code must be resilient, fairly performant, free of any obvious pathological cases with catastrophic memory or computation complexities, and above all, dependable.
It isn’t just language and framework developers that are forced to make choices that don’t necessarily align with your own use case. Even when attempting to identify what alternative data structure you could write up and use for your needs, you’ll often be presented with theoretical 𝒪 numbers that don’t necessarily apply or even have any relevance at all in the real world. An algorithm thrown out the window for having a horrible 𝒪 in Algorithms and Data Structures 101 may very well be your best friend if you can reasonably confine it to a certain subset of conditions or input values – and that’s without delving into processor instruction pipelines, execution units, spatial and temporal data locality, branch prediction, or SIMD processing.
NeoSmart Technologies’ Easy Window Switcher, a nifty utility which brings macOS-like switching between windows of the same application with Alt–`, has been updated to version 1.2.0; the biggest feature in this release is support for Windows 10’s virtual desktops.
Rust, both by design and by convention, has a fairly strongly defined model for strict error handling, designed to force developers to deal with errors up front rather than assume they don’t exist. If you stick to a few conventions and principles for best practice, error handling becomes fairly straight-forward (although what you ultimately do with the errors is a different question) if you are living in an all-rust world. The problems start when you step foot outside of the comfortable world of crates and Results, such as when dealing with FFI to interface with C libraries or using rust in an embedded context.
The typical approach for dealing with errors in rust in 2018 is to have any function that can encounter a scenario wherein it is unable to return a valid value declare a return type of Result<T, E> where T is the expected result type in normal cases and E is a type covering possible errors that can arise during execution. When calling from one such function into other functions with non-guaranteed success, the typical control flow in the event of an error is almost always “early out”:
One of the unique characteristics of Rust (both the language and the community that has evolved around it) is a strong acknowledgement of multithreading, synchronization, and concurrency, as witnessed in the design of the core language (which acknowledges OS concepts of threads with sync and send) and the presence of various structures in the standard library aimed at simplifying development of correct, multithreaded code.
rsevents is a new crate that should be immediately familiar to anyone that has done multithreaded programming under Windows: it exposes a synchronization primitive, namely, an event for use where Mutex – intended to exclusively marshall access to a variable or region of code – either does not convey the correct semantics or is not the right tool for the job. For those that didn’t come fleeing to rust from a Win32 background, in Windows an event is the lowest-level kernel synchronization primitive, which can be thought of as a “waitable bool” – it is either set or reset (on or off, true or false) and if it isn’t set, you can wait on it until it becomes set.
C# developers have long been spoiled when it comes to quickly and easily getting up and running with encryption thanks to the .NET CryptoStream class, which wraps a Stream instance in a second Stream that automatically encrypts/decrypts anything read/written to/from it before passing it along to the underlying Stream. Long story short, it makes it ridiculously easy to add encryption or decryption facilities to an existing pipeline, as after setting up the CryptoStream instance you can just treat it like any other Stream object and read or write to it normally.
Encryption has been somewhat of a sore spot in the rust ecosystem after a few false starts with “native” rust encryption libraries that went nowhere, but today the rust community has fortunately adopted the OpenSSL bindings as the approach of choice, and the rust-openssl crate makes it easy to both bundle and consume the openssl bindings from rust in a cross-platform manner. What it doesn’t do is make encryption and decryption any easier than OpenSSL itself does.
Let’s start this article with an error message right off the bat:1
~> cargo install ripgrep --features 'avx-accel simd-accel'
Updating registry `https://github.com/rust-lang/crates.io-index`
Installing ripgrep v0.9.0
…
error[E0432]: unresolved import `simd::x86::avx`
--> /home/mqudsi/.cargo/registry/src/github.com-1ecc6299db9ec823/bytecount-0.3.2/src/lib.rs:49:16
|
49 | use simd::x86::avx::{LowHigh128, u8x32};
| ^^^ Could not find `avx` in `x86`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: Could not compile `bytecount`.
I’m primarily blogging this as I’ve run into – and worked around – this error several times before running into it again and not being able to remember how I resolved this problem the last time around. ↩
A recurring theme in just about all discussions revolving around the comparison of programming languages – apart from using the wrong tool for the job, adamantly pushing a language objectively/demonstrably inferior at x out of blind loyalty, bashing on languages you’ve never used or studied simply because you’ve seen firsthand how well received such comments can be, and worse – is acting off of stale information that no longer necessarily holds true.
At NeoSmart Technologies, we don’t just have one dog in the race; our software is developed in a multitude of languages, ranging from C/C++ to both desktop/web C#/ASP.NET, rust, [JS|TypeScript]/HTML/[LESS|CSS], (ba)sh scripting, and more.1 So it’s always interesting to observe these discussions (sometimes up close and personal and sometimes disinterestedly from afar) and observe what arguments remain standing once the dust has settled and the troops have gone home for the day.
Gasp, yes, even PHP! ↩
A year and a half ago, I heeded the growing warning signs that indicated the looming demise of macOS, née OS X, as a platform for developer and true computer enthusiasts, and set about trying to find a new ecosystem. Luckily, this was around the same time that updates to Windows 10 combined with the the continued awesomeness of WSL,1 made it a viable option for reconsideration.
While Windows had always remained my primary development platform of choice due to the nature of my work, there were various apps that I’d become accustomed to using and had to seek out alternatives for, chief of which was iMessage. As someone that has never embraced the mobile craze, I sorely missed the ability of texting (or “iMessaging”) from my PC, and came to absolutely despise having to drag my phone out of my pocket and text from its cramped display, constantly fighting autoincorrect and embarrassing myself with typos and misspellings. I tried switching to alternative platforms, including WhatsApp, Skype, and FB Messenger; but nothing came close to matching the pure simplicity and sheer genius of iMessage’s “SMS backwards-compatibility” approach that upgrades iPhone-to-iPhone communications to iMessage while transparently falling back to SMS or MMS where iMessage was not an option.
WSL is the Windows Subsystem for Linux, also known as “Bash on Ubuntu on Windows,” offers a native Linux-in-a-shell with nice (and growing) integration with Windows. Check it out! ↩
