Nohj Retrac
cccc
How Verizon Convinced Me to Leave
Some background. I'm currently on a three-line plan with my wife and mother-in-law. I had started considering the switch when it came time to buy a new phone: Verizon's removal of subsidies, plus an “upgrade fee” (i.e. I have to pay them for the privilege of using a new phone that I've paid full price for), were already annoying me, and then of course I couldn't find a phone that doesn't have a locked bootloader. No other carrier does this.
I called customer service today to make sure that my leaving wasn't going to play hell with my wife and MIL's bill. As I expected, the rep asked why I was leaving. I gave him three reasons: (1) cost, (2) the locked bootloaders, and (3) Verizon's concerted efforts to undo Net Neutrality.
For cost, he asked where I was looking at, and I told him Google Fi. He looked it up, and we got to talking about the price calculator. He said that based on our plan, it'd cost $110 on Google Fi. But he conceded that this would still be cheaper than what we're paying Verizon. But this is also inaccurate: Google Fi would only cost that much if we used 6GB of data (our cap with Verizon). With our actual data usage, Fi would be $85, which is just over half of our current Verizon bill (and since Fi is month-to-month, if we use less we pay less). So strike one. (I'm not shilling for Fi, and don't know for sure that I'm going there, but I needed to give numbers to show why I was being given wrong information.)
The locked bootloaders thing he just acknowledged and didn't try to argue, because it is what it is. I appreciate that he didn't give me some nonsense about why it's a good thing, or why I shouldn't care.
But then for the Net Neutrality piece, he said that it was his understanding that Verizon favored it. I'm sure this is line he was given, but the problem is that it's wildly inaccurate. Like, so boldfaced that I legit didn't know how to respond. Verizon has been a leading force in undermining and ultimately killing Net Neutrality. They were the ones who sued over the rules in the first place (and did so twice, in 2010 and 2014). They have consistently made incorrect statements, violated net neutrality even when it was a rule, and has lobbied aggressively in favor of federal overriding of state open network laws. The list goes on, so this attempt to re-write history is just insulting.
I was on the fence on leaving and only gathering information prior to the call. But after being lied to (by the company, if not the individual), I am definitely done. Good job, Verizon!
Used Bookstore Haul
My wife and I needed a personal day today, having spent far too much time in the car this weekend. As is our habit when we have a day off, we got breakfast together and then went to our local used bookstore, 2nd and Charles.
It's owned by Books-A-Million, but is far more interesting. It's a combination of new and used books, movies, music, comics, and general nerd/pop-culture doodads. It is amazing, and is one of my favorite places to wander. Plus, since a great deal of its books are used, it's something I can afford to do more often. For example, I walked out of there with 8 books today, and only spent $50. That much at Barnes & Noble might have gotten me 3, if I was careful.
Now, on to the haul.
Children of God by Mary Doria Russell. This is the sequel to The Sparrow, which I read some years ago. The first book's premise is that, in the near future, we discover alien life in Alpha Centuri. The first expedition to meet up with them is undertaken by the Jesuits, and it all goes horribly wrong. Basically “the road to Hell is paved with good intentions”, the novel. Children of God follows up with the main character of The Sparrow several months after his return.
Never Let Me Go by Kazuro Ishiguro. I've heard that, at least to a degree, knowing the background of the plot will spoil some of it. So all I know is that it's supposed to be amazing but a downer.
Too Like the Lightning by Ada Palmer. I don't actually know much about this one, either, but what little I've read of the setting seemed interesting. I was more interested due to the praise (it was a finalist for the Hugo Award last year), and also because I had enjoyed the author's blog in the past (she's a professor of Reinassace history as well).
Under the Skin by Michel Faber. This was made into a small-ish movie starring Scarlett Johannson. I found the movie to be eerie and otherworldly in the best possible way, and so I hope the book is equally good.
Foucould's Pendulum by Umberto Eco. I've had this book on my to-read list for years, and I finally remembered this fact when I was in a bookstore.
The Sorceror's House by Gene Wolfe. The Book of the New Sun is in my top-10 books of all time, so I'm always eager to try something else Wolfe has written.
A book of drawing prompts. I've lately gotten out of the habit of drawing, which sucks because I felt like I was making actual progress in my skill level for the first time in years. I'm hoping this will help me get back to it.
And the find that I am probably most excited about:
The Holy Qu-ran. There are numerous editions and translations out there. I've read some of A. J. Arberry's translation, but since I'm stuck (for now) with translations, I always like to find multiple versions to compare.
And I really lucked out with this one. It's the “official” edition published in Saudi Arabia, at the King Fahd Complex for the Printing of the Holy Quran. But not only that, this particular one was published in 1990, which means it uses an updated version of Abdullah Yusuf Ali's translation. This version is supposed to be a good rendition, and it also includes commentary.
This matters in particular because, regrettably, Saudi Arabia started using the Hilali-Khan translation in 1993, which has been criticized as being heavily Wahhabist (and thus overly conservative, prejudiced, and too supportive of violence) as well as a bad translation from a linguistic perspective. I have heard some criticism of the Yusuf Ali translation as being anti-Semitic in its commentary, so that's something I'll have to watch out for (assuming that's still present). Apparently too the King Fahd Complex's editors made some changes to put it back more into orthodoxy, which is a pity as the original apparently had some Sufi leanings, which is a tradition I resonate with a great deal.
The other reason that I'm super excited about this find is that this version is dual-language! I find Arabic beautiful just from an aesthetic standpoint (both as written and spoken), and Qu'rannic Arabic is next on my list of languages once I finish with Coptic. This version has both, which means I'll have a ready resource once I get there, to supplement the online versions (which thankfully are myriad and offer multiple translations in parallel).
This version is lovely in terms of aesthetics, and given its provenance I like wondering about its journey. I admit I was a little surprised that someone would sell it to some random bookstore, but maybe it was purchased for a class or something. Still, the image of a holy book sitting so unobtrusively on a shelf, having been given up, is a poweful one.
Journaling Coding a Journal | Part 3
This one is a bit of an interlude.
As I explained last time, I had sorted out the basic functionality for terminal output. This means that if I wanted to say, write some text in red someplace else in the program, I just have to call:
TextFormat.colorWrite("text to write", "Red");
I also did a couple of others, including one to do a complete line (the one above doesn't skip to a new line, which allows for multiple colors in a line), and one for centering. This last was also nice and simple: all it had to do was figure out how long the text to be written was, figure out how wide the window was, and from that it's easy enough to calculate how much whitespace is needed on the left to make things line up. (This of course supports color as well.) I was then able to add an optional width, meaning it'll center text within an imaginary bounding box (which is useful for “windows” within the console).
Where I got bogged down was in actual editing. It's trivial to just have the user start typing and show it, but as soon as even basic functionality, like word wrap, comes into the occasion, things become much more complicated.
I won't bore you with the details, but I was getting stuck with trying to keep track of where everything is and display it properly. I think I have a method now that will work, but I haven't been able to put it into practice just yet.
In the meantime, I decided to put some work into the interface, which also meant figuring out what kinds of functionality I actually wanted to include. I also haven't had much time to devote to this project this week, thanks to various other things demanding my attention. But I've managed to get a basic idea for a layout, and have some helper functions to draw the full window border and sub-panels.
The sub panel code was an interesting challenge, but I definitely learned some things. It works as a function that I call, giving it a starting X and Y, how wide it should be (either in absolute columns or a percentage of the window), as well as some further attributes like a title, border style and color, etc. Soon I'll add code for background colors too, but that needs some changes elsewhere (such as in my colored text methods).
The first sub-panel I'm putting together is a calendar, which will show when previous entries have been made and allow the user to jump to them for viewing or editing. I won't be able to do much of this until I have the actual editing code in, of course, but I can at least do some basics. The last thing I've implemented so far was getting it put the first week of the current month into a grid. This is harder than it sounds.
Case Study
Remember, the computer doesn't know anything about anything. It can only do what I've told it to do, and can only use new information that I've told it to figure out.
All it can bring to the party is a date. So that's my starting point.
In C#, there's what's known as a DateTime object. This is its own category of variable, and it can hold various parts of a date and time (from years to milliseconds). So my method works like this.
First: get today's year, month, and day, since the first thing to be displayed is the current month (and scrolling through months later will need a starting point). It then isolates the month, and gets its name (so I can use that as the heading). Then there's a built-in method that returns a number from 0-6 based on what day of the week a given date is (with 0 being Sunday and 6 being Saturday).
This proved to be perfect. From there, I just built a 7-element array, with each element representing a day of the month for a week. Like in most languages, arrays in C# are zero-indexed, which means that the first element is at place 0 rather than 1. Since I also have a 0-6 number associated with the day of the week, I can put the first of the month in its proper place just by assigning it:
arrayOfDays[dayOfWeek] = 1;
The bit in brackets tells the computer which specific element should equal 1.
From there, it's a simple matter of getting the number of days in the previous month (and there's another built-in method for that). That one goes in arrayOfDays[dayOfWeek - 1], then keeps adding smaller numbers until we get to 0. Then it starts at wherever the 1 is and adds in 2-whatever. There's some additional logic to check for edge cases (like I can't tell it to use dayOfWeek - 1 when dayOfWeek is 0, since there is no element at -1).
So now I have an array with 7 numbers, but it needs to be output. That too is easy enough: just go through each element of the array, converting it to a string (since it's stored as an integer) and adding a couple spaces so that it'll print properly:
string weekText = "";
foreach (int day in arrayOfDays) {
weekText = String.Concat(weekText + " " + day.toString());
}
From there, it's a simple matter of putting the cursor in the correct place, then using my centered text function with a width of 2 columns less than the width of the box (so that it doesn't overwrite the box's borders). Done!
This was definitely the hard part, since I had to deal with finding the beginning of the month. From there I can just build groups of 7 days until I get to the end, then start over at 1 to fill out the row.
But even then, I'm not quite done. I have two more main to-dos for this piece:
Update my centered writing function to allow printing more than one color. This is something I wanted to do anyway, and for the calendar it'll let me dim the dates that aren't in the current month, which is a nice aesthetic touch.
Have some logic that will keep track of certain dates as including an entry. I don't have file reading stuff in yet, but I can use some test code to make sure that the pieces will be in place so that when I do, and can load a list of dates when journal entries were done, the calendar will be ready to handle them.
This part shouldn't actually be too hard. C# allows a function to take an unknown number of variables. Although as I think about it, since I'll need to be able to pick random/arbitrary numbers to output this way (i.e. it won't always be the first and third numbers in the row, for example), it'll probably be better to have a separate function within my calendar drawing framework rather than trying to force the more general one into the role.
Phew. I'm sure that was far too much information, but it's certainly helpful for me to put my thinking down into some kind of order so that I don't go in 100 tangents at once.
Objects in Space: If I were to make a space game, it would look like this
When I first thought about coding again, it wasn't long before I started thinking about making a game. I'm a gamer, after all, and there's that whole thing about writing what you know.
Before long, the idea came to me: what about Silent Hunter in space? After all, everything's better when it's in space.
I decided to start smaller, though, which was definitely a good idea given my inexperience. Doubly so, once I discovered that someone beat me to it.
Objects in Space is basically Silent Hunter with a little dash of FTL. And it's the most fun I've had in a game in quite awhole.
How It Works
OiS is at its core your standard Freelancer-esque trading sim. But while games of this type often focus mostly on economics and dogfighting, OiS emphasizes ship management to a much greater degree. Meanwhile, the actual flying of your ship is handled nearly identically to a submarine sim.
Basic, in-system navigation is done on a 2D plotter. You can set where you want to go and let the ship fly you (and you can plot a series of waypoints to go around obstacles and the like).
You also have the option of flying manually. But you're subject to realistic physics, such as inertia, so you have to be careful: turning in a different direction and executing a burn won't magically negate the momentum you had developed before.
Meanwhile, power management is key. Burning your main engines or using your RCS (which is how you rotate) is power-hungry. If you go over what your reactor can produce, you start to drain your back-up batteries. If those run out, you're unable to do anything until they recharge enough, so you can get yourself into trouble by manuvering too much. And it's not just engines: things like a jump drive (which allows you to go to other systems) and defenses also take power, so you have to manage carefully, particularly in combat.
The FTL comparison starts to come in with repairs. You have various components in your ship, from engines and reactor(s) to navigation, defensive measures, weapons, scanners, communications, etc. These all have various little doodads inside them, and those components will start stop working if your ship takes damage (whether from weaponry or flying too close to a star). You have to buy these pieces individually, so if something breaks and you don't have a replacement, you're screwed until you can get to a station that has the right part.
Meanwhile, there are too many for you to realistically keep a store of everything. Repairs then are a serious concern, and it makes flying in the vastness of space more perilous than simply driving your car down the block.
Combat is still fairly rudimentary from the limited bits I've seen. But where the game really shines is in how you avoid it, and this is where the submarine comparisons really come in.
Here we have the main “cockpit” view of one of the ships in game. Clicking on any of the monitors will bring it full-screen, and allow interaction with it. But you may notice the red lighting everywhere, and the fact that communications are “non-functional.” This is because the ship is in EmCon mode, short for “emissions control.”
Every component on a ship has an emissions profile. Certain things are “noisier” than others; for example, the main engine gives out a lot more emissions than your navigational computer. This directly affects how easily you're detected by other ships in the system, some of which aren't necessarily friendly. If you notice the screen in the top-left, this is the scanner. If something isn't trying to be stealthy and is within range, it'll be identified pretty quickly. For something that isn't, though, you can sometimes get blips at certain frequencies that correspond to different ship's systems. Some of these will be sensor ghosts, some won't, and one of the mechanics is figuring out what you're looking at. (The game explains in more detail how this works, so thankfully it's not a guessing game as much as it sounds.)
Meanwhile, going into EmCon mode shuts down the noisier components of your ship (and you can pick which these are). But this often means your reactor, and so you're left with whatever's in your batteries. This can last quite awhile if you're standing still, but manuvering and any defesnive measures can burn through it rapidly. Those green boxes represent the emissions level of your ship, basically meaning 2/5. Things like an IFF also increase this; but in more heavily populated/patrolled systems, you can be fined for having it off.
There's also a “terrain” element that comes into play. In the first screenshot above, you can see the blueish nebulae. These significantly reduce your visibility, and so it's worth sticking to them as much as possible if you're someplace that isn't patrolled very well (or someplace that is, if you're going the smuggling or piracy route).
And this is where the game really shines for me. I got a mission that required me to get a person out of the system we were in, and you're told by the NPC that you'll be pursuied immediately. Sure enough, there are several ships on screen that are identifiable as the type that would be after me. I'm completely outgunned (my ship isn't armed at all at this point), so I have to get to the jump gate by making my way through nebuale and timing my movements to avoid them. Burns and turns are extremely noisy, and so you have to be careful to only do them within a nebula and then make a break for it. It was a relatively short time before I was able to make my way out, but it required a close eye, both on the other ships any my battery reserves, and it was immensely satisfying to watch one of those ships fly past me without noticing I was there.
Does it Work?
The game is still in beta, and there are places where it's a little rough around the edges. Occasional graphical glitches on screens happen, and I've had a couple crashes in my week or so of playing. Nothing major, though, and the auto-saves are frequent enough I've never lost any meaningful amount of progress.
Meanwhile, the writing is fantastic, and it does a better job than most of making tutorials feel like part of the world. There's a news feed that feels far more real than most, and the devs say they're planning on making those events have a direct effect on economics. Patches seem regular from what I can tell, and there're a lot of intriguing features they're planning, including a Linux version (currently it's just Windows and Mac).
But still, it's only worth buying a game in early access if it's worth the money now, not later. And Objects in Space definitely is. It's already got great mechanics and one of the most fleshed-out universes of any space sim I've played. It's well-written, and allows for a variety of approaches, from piracy to honest trader and everything in between. I look forward to seeing where they go with it in the future, but even now i'm enjoying it a great deal.
Journaling About Coding a Journal | Part 2
Part 1 is here.
One of the first things that struck me about how C# works is the fact that it wants everything to be in a class. I vaguely recall classes being a thing in C++, but it was something I never really messed around with.
The nice thing is that the way it handles namespaces and file inclusion makes a whole lot more sense.
First: no include directives! For core libraries, you can include a Using directive to shorten the typing, but like with C++, everything is still accessible by defining the scope at the time you're using it. This includes third-party libraries too (the complier uses a manifest file to know where everything is instead).
Namespace also feels a little more flexible to me, although I'm not sure it's actually that different from C++. What I really like, though, is that you can organize files without having to include them. As long as everything uses the same namespace, it's all accessible right off the bat.
The requirement to use classes for everything also really helps with organization; it forced me to divide things up anyway, so I may as well categorize the various functions I'm putting together.
Now in Technicolor
One of the things I decided early on was that I wasn't going to use any third-party libraries. I'd take a look at how other people had done things, but I wanted to do everything from scratch. I'll learn a lot more that way, and it's more fun to figure out a puzzle than simply apply a tool.
The first thing I wanted to do was style text output. Terminal apps are nothing but text (although I've seen some ways to change that...), so I want to get the most of it.
There's a built in ConsoleColor attribute (actually an enum), but that only works with Windows. Since I'm developing on Linux (and want it to be cross-platform anyway), I had to find something else. Meanwhile, most *nix-based consoles (plus MacOS') support a much greater color depth than Windows.
For the *Nix consoles, I was able to do some tinkering and found that they'll recognize ANSI escape codes. These are a specific sequence of characters where, if you output them to the console, they'll change the color and what-not. I originally had an issue with Konsole, KDE's default console, not recognizing them. I later discovered that this was actually a matter of the escape characters having to be capitalized. It really was that simple, and was something I discovered completely by accident.
So for my original implementation, I figured I'd just detect the OS, and then my color output function would actually style the text based on that. This was simple enough, and worked fine, even if I couldn't help but feel it was a little clunky, or at least inefficient.
I was looking up something else when, lo and behold, I found the escape character that the Windows terminal recognizes. The documentation is a little opaque, in that it spreads the information over a couple of pages, but it turned out to be the upper-case version of what I had been using for *Nix all along. No more duplicate code!
...Or so I thought. The problem is that Microsoft has a pathological aversion to following standards. In order to get the Windows console to use an escape sequence with colors, you have to use the SetConsoleMode function, which is part of the standard C library, but not C#. I could implement this directly in C# by loading a Windows DLL on runtime and then executing the code that way. There are also some third-party libraries that hook in at runtime to give this functionality. But in either case, I'd have to have OS-detecting code (since there's no need for the DLL on anything else). At that point I'm much better off just using the built-in color coding for Windows and escape sequences everywhere else.
The code is simple enough. I have a public class called Globals, which associates a number with some simple color names (and the number depends on the platform, i.e. Windows or something else). Then my color writing function has an if/else block to use the correct language for the OS. Honestly, from what I've seen my approach is smaller in terms of lines of code than any other implementation I've seen, all of which seem hell bent on over-complicating the whole thing.
I also have a couple of additional helper functions, to do things like bold and underlining (even if Windows doesn't support those at all), as well as center text on screen.
Finally, I've got some basic file saving logic, but I'm not getting too deep into this until I get the editor part working. After all, I won't know quite what a given “entry” is going to look like until much further down the road.
Next time, the beginnings of an editor, which causes a great deal of headache.
The Mechanical Keyboard Rabbit Hole
Being somewhere on the “progressive” spectrum means that I have a weird relationship with stuff. (This is made only worse by being at least nominally part of a faith that emphasizes simplicity.) As with anything I try to find a balance, but with a consumer culture on one hand and a push towards minimalism on the other, it can be hard.
But this isn't really about that. One thing that does help balance it out is the “buy it for life” idea. Sort of a reverse version of Vimes' Boots:
The reason that the rich were so rich, Vimes reasoned, was because they managed to spend less money.
Take boots, for example. He earned thirty-eight dollars a month plus allowances. A really good pair of leather boots cost fifty dollars. But an affordable pair of boots, which were sort of OK for a season or two and then leaked like hell when the cardboard gave out, cost about ten dollars. Those were the kind of boots Vimes always bought, and wore until the soles were so thin that he could tell where he was in Ankh-Morpork on a foggy night by the feel of the cobbles.
But the thing was that good boots lasted for years and years. A man who could afford fifty dollars had a pair of boots that'd still be keeping his feet dry in ten years' time, while the poor man who could only afford cheap boots would have spent a hundred dollars on boots in the same time and would still have wet feet.
This was the Captain Samuel Vimes 'Boots' theory of socioeconomic unfairness.
(From Men at Arms by Terry Pratchett.)
At the least, this offers a good way to rationalize spending more money than I strictly speaking need to. I guess, though, that at the end of the day, I'd rather be someone who has to justify and rationalize spending money than saving it.
Anyway, when I got a new gaming desktop (speaking of which) this past spring, the system builder I used had a deal where you could spend $5 for a keyboard upgrade. Sure, why not? I think they mentioned it being a mechanical one, and I kind of knew that this was something people take seriously, but I didn't especially care.
Until I had one, that is. Now, my wife was less enamored, because the switches (basically the things that make the keys go up and down) are very loud (for those who know what this means, they're clones of the Cherry MX Blue). Very loud, very clicky. But that keyboard feels amazing. It's one of those things that I didn't know could feel different or better until I found something that showed me.
For my job, I spend all day typing on either a laptop keyboard or a cheapest-possible OEM keyboard when I'm in the office. At home, I'd either been using an older Logitech one (the G110, about 7 years old at this point) on my desktop, another laptop keyboard, or occasionally a Bluetooth keyboard for my iPad. But I found that once I got over the key height on the mechanical, I never wanted to type on anything else. It just plain feels better, in a way that's difficult to describe. You get more feedback in your fingers, the way my wrist sits is better, and I just plain enjoy the clickiness.
After a few months of this, I decided to investigate getting a new one for my desktop downstairs in order to annoy my wife slightly less. The plan is to use that one upstairs for my personal computer once I'm home. Then eventually I want to get what's called a tenkeyless (basically a normal-sized keyboard but with no number pad on the far right) to use for my job, with the smaller size making it easier to toss in my bag for when I have to be in the office.
So this was my rationalization for dropping $100+ on a keyboard: it's more comfortable, mechanicals last longer, and it's worth it since my job is literally 95% typing.
What I didn't realize was how deep this rabbit hole goes.
I suppose I should've known given that there's an entire (very active) subreddit devoted to nothing else. It's not just that there are a lot of places to buy them, there are a lot of places to buy pieces of them. You can get the caps (the actual part your fingers touch) custom-made, you can assemble them from parts if you're willing to solder. It goes on.
After like 2 hours, I realized I didn't want to mess with all that, and just got this one. Even this required figuring out what the difference in the switches was, which required more time, mostly on YouTube. (I haven't received it yet, as it's only been a couple days. Time from order to shipping was good, though.)
It's an interesting subculture, and I have a hard time judging it too hard. Granted, I have no interest in futzing around with massdrops (basically a thing where if enough people order something someone will make it), and I don't think I'll be sucked in to the point of spending $150 just on key caps. But I admit to understanding how someone could be willing. I think we underestimate the degree to which having tools that make you happy can really make doing a job better.
Journaling Coding a Journal | Part 1
I got my first ever computer in 1990, an IBM-PC clone that my dad and grandfather bought me for my birthday that year. One or both of them recognized, with no small amount of foresight, that these things were the future, and that it was important for me to get in on them early. My maternal grandfather, meanwhile, was an electrical engineer working for various telcos, so I got no small amount of exposure there as well.
It was actually him that first introduced me to programming, showing me some basics of BASIC (heh). I never really got past this, though, since I was rubbish at system-oriented thinking. (This would make a lot of sense when I was diagnosed with ADHD in my 30s). My next real foray was burgeoning web design in the late 1990s, including ActionScript, which was the primary language behind Flash. This was my first introduction to C-style syntax, and I continued chipping away (including a summer C++ class during law school). But I continued to struggle with being unable to see past the piece that was immediately in front of me.
Once I had the revelation that was prescription stimulants, I decided to give it another shot, and it is amazing how much more sense this stuff makes.
Meanwhile, I've started using Linux almost exclusively over the last 6 months or so, after being half-and-half for the previous year. (I now use Windows exclusively for gaming.) I found myself really enjoying the modern generation of console apps, basically programs that work in a terminal window (think a DOS prompt if you're on Windows). Around the same time I decided to start journaling again, and so set out to look for a good console-based journal.
I did find jrnl, which serves, but which is a little too minimalist for me. On the other end of the spectrum is org mode for emacs, which didn't quite work the way I wanted it to.
So, these things came together, and I decided to write one.
Finding a Language
This section may occupy a weird space of being too technical for non-programmers, and too naive for the coders. It's a skill.
Of course, I needed a language to use. I wanted to use something lower-level than python, in the hopes that I could grow into the greater control. Plus there's a performance hit to it compared to something else, which would matter down the line (but obviously not for a text-based journal). On the other hand, I decided that C++ was a little too steep of a learning curve right now, although it's something I'd like to revisit in the future.
I also looked at Rust, which is a relatively new language maintained by the Mozilla Foundation. There are a lot of things that I find intriguing: the way it handles asynchronous I/O (basically the way you set up one part of the code to wait for something while other parts keep going) seems to make a lot of sense to me, and I like that it's really conscious of memory usage and referencing.
On the other hand, its relative youth was also a hindrance. It was only released in 2010; by comparison, C++ was first released in 1985. The documentation isn't the greatest, and as of right now there aren't any particularly good ways to do GUIs. There are a couple projects involving creating bindings for existing frameworks like GTK, but it all felt very piecemeal. (I found the same thing with Go.)
Meanwhile, I had been working on a website redesign for my martial arts school. My cohort in this process is a full-time developer, and so we're using Angular. This has a core written in C#, and I was reminded that this was a thing. I'd previously only seen it as the language the underlies the Unity game engine, but I hadn't used it very much.
What really raised my interest, though, was the discovery that Microsoft had ported the core libraries for C#, the .Net Core, to other platforms. C# could already work as a cross-platform language, but this would make it a lot easier.
In terms of my IDE (the actual program in which I'm writing the code), I had already been using Visual Studio Code to do web-based project I'm working on, and really like it. It's extensible enough, cross-platform (so I can work on my Windows machine too without changing environment), helpful without taking too much control out of the way, and visually enjoyable. I do also use good ol' emacs on my laptop on occasion.
This was my starting point. Next time will be the overall design I'm going for, and my early progress (and wall-hitting).