The Next Y2K Is Already Here – InApps Technology 2025

I remember the night of New Year’s Eve 1999 vividly. Well, vividly as far as those go. But there’s one part that sticks with me, as we all huddled in a friends basement wondering if planes might, indeed, just fall out of the sky.

At precisely midnight, we picked up the landline (yes, we still had those) because we’d heard that it was expected that so many people would pick up the phones to see if they still worked at the same time, that rather than the Y2K bug taking the phone system down, somehow that very act would instead. I guess if the world was going to burn, we wanted some part in it.

Well, no planes fell and the phones worked just fine and Y2K passed, to us at least, into the realm of joke and dismissive snicker. Of course, the reality is that it was a years-long effort by developers to the tune of $100 billion to make sure those planes didn’t fall out of the sky and that the infrastructure kept on keeping on.

Two decades have now passed since we cruised on by Y2K, and it’s now time to look at the next date-time related bug on the horizon — that of the 2038 problem. Much like the Y2K bug, 2038 is problematic because of “insufficient capacity of the chosen storage unit” explains the Wikipedia article on the topic. More specifically, Unix encodes time in a signed 32-bit integer time format representing the number of seconds passed since 00:00:00 UTC on Jan. 1, 1970, and times beyond 03:14:07 UTC on Jan. 19, 2038 cause an integer overflow.

This is suddenly a popular topic not simply because last Sunday represents 20 years until the problem hits for all Unix-based systems, but rather because it has already begun, at least according to developer John Feminella, whose Twitter thread has more than made the rounds this past week.

Feminella tells the tale of a client whose “nightly batch job” that had “never, ever crashed before, as far as anyone remembered or had logs for” went down last Sunday — 20 years to the day before 2038 was expected. Coincidentally, some changes had been made, so focus first went there, but soon enough the problem was isolated to the one that wasn’t supposed to hit for another couple decades.

“But by then, substantive damage had already been done because contributions hadn’t been processed that day. It cost about $1.7M to manually catch up over the next two weeks. The moral of the story is that Y2038 isn’t ‘coming’. It’s already here. Fix your stuff,” Feminella concluded.

The funny thing about the whole thing is, one moral you might conclude from that story is to not simply let code keep running forever without taking a look at it…and that’s pretty much how we ended up with the 2038 bug in the first place. The video below goes into a bit more detail…

This Week in Programming

• “Another Unsafe Sh*tstorm”: If you’ve heard the rumblings, but missed the story, DevClass has the tale of a Rust framework developer who said “I’m done with Open Source” before apparently having second thoughts. The apparent “ragequit” was used in many examples last week as further evidence for the unsustainability of smaller open source projects, but therein lies so much more in terms of story morals and examples of people behaving badly online. That sounds like a reality TV show, doesn’t it? The project in question here is actix, which was open sourced in 2017 by Microsoft engineer Nikolay Kim. At the heart of the issue is the amount of “unsafe” code used in the project, which many contend was far too much for a language built on the idea of memory safety. The article lays out the numerous back-and-forths, but the further gist of the scenario is that actix is a small but very popular open source project that can’t keep up with the demands of the community using it. In response to a heated Reddit debate (which followed previous heated debates), the project’s sole creator up and quit before deciding that “it would be unfair to just delete repos” and handed over control to a contributor.
• What Is Rust, Anyhow? Speaking of Rust, StackOverflow has an article for those of you who remain unfamiliar with the language that answers the question of what is Rust and why is it so popular? As the article notes, the language has been the most loved language for four years in a row on StackOverflow, but the fact remains that roughly 97% of survey respondents haven’t used Rust. So what is it? “The short answer,” they write, “is that Rust solves pain points present in many other languages, providing a solid step forward with a limited number of downsides.” The blog post breaks it down into different sections for different developers, whether you’re used to garbage collected, statically typed, or other systems languages. So, if Rust is something you’ve just heard of but not really looked at, this is a good place to start, to get all the ups, downs, and in-betweens.

• A Haskell-esque Language for Distributed Systems: InfoWorld brings us the story of Unison, a functional language that touts immutable code that it says can “describe entire distributed systems with a single program.” The open source language is in a public alpha release and was “founded on the core notion that code is immutable and identified by its content,” writes InfoWorld, noting that a production release is expected later this year. The other core idea behind Unison is that it is made for building distributed systems. Now in a public alpha release, with multiple milestone alpha releases planned, Unison is due for a production release this year. If experimental, alpha languages are your cup of tea, head on over to the project website and the Unison GitHub repo to see more.
• Python’s As Fast as Go and C++? When you think of Python, your first thought may not be “blazingly fast,” but iProgrammer brings us a scholarly paper on the topic that compares Python with Go and C++, using the N-queens problem as the benchmark. While the headline says that Python is as fast as Go and C++, that statement of course should be qualified, but is nonetheless warranted. The crux comes here: “Implementing this in Python, Go and C++ quickly demonstrated that Python was slow, but included error checking that was missing from C++. To see if things could be improved, the same code was compiled using the Numba Python compiler. […] once compiled using the Numba compiler it becomes competitive with C++ and Go in terms of execution speed while still allowing for very fast prototyping.” Also of note, upstart language Julia is also found to be among the fastest, although this mention is relegated to the appendix.

• IntelliJ IDE in 2020: Lastly for the week, JetBrains’ IDE IntelliJ offers a peek into its features roadmap for 2020, this time looking at some more high level features. In the year ahead, IntelliJ IDEA will include localization for Asian markets, the ability to use the IDE as a general-purpose text editor (without it annoyingly creating an empty project file each time you do), git staging support, and further text completion based on machine learning. While we’re talking about JetBrains, all you Kotlin users (or non-users — they want you too) can go ahead and fill out the 2019 Kotlin census, which will help the team behind the popular Android Java alternative work in the year ahead to make the language better for you. If that’s not enough, know that by filling out the census, you also enter a raffle for KotlinConf tickets and a Kotlin t-shirt. So, there’s that.

List of Keywords users find our article on Google: