Not good enough. All previous commits still infringe Spegel's copyright, given they are still available and distributed. I would assume the point release also infringes copyright.

You are Microsoft. You can do better.

Very silly, they can't rewrite the commit history nor would it be proper to update old packaged releases.

What do you mean they can't rewrite the commits? They can, they should, and it's really easy to do so. As for the packages, they should be taken offline.

They should neither rewrite the commits nor take the old packages offline. It's not worth a huge potential clusterfuck when the issue has been fixed on the latest version.

They should absolutely do it. They made a serious mistake and should pay for it, even if that means every Microsoft developer having to rebase all their WIP branches. The more expensive it gets the more they’ll pay attention to those things in the future.

Why not just fire the entire division? Maybe they should shut down the company?

You might be overestimating how hard this is, because it's not hard at all. It takes less than half an hour to create a script that does it.

What is the benefit of re-writing the git history?

Complying with the terms of use instead of infringing copyright

The terms of the license don’t require you to modify the git history that’s a goofy interpretation.

The terms of the license require you to ship the copyright note. Their latest release is in violation…

Rewriting those commits would effectively allow them to erase their mistake, which kind of lets Microsoft off the hook in a way.

Yes, it would be cool, and it's the usual way to do these things. You can license code under a more restrictive license, and clarify licensing by adding an extra section to the main license, adding the license to a subdirectory, or adding license headers to the individual files.

Whether the MIT license is the right one to choose is probably a different debate.

It's in the LICENSE file. With a MIT license, you assign a copyright to the project, or to a certain set of files. The Spegel license attributes copyright to "the Spegel authors", while Peerd attributes it to "Microsoft Corporation".

If some of the peerd code was lifted from Spegel, it's blatant stealing. Code attribution is the only thing a MIT license asks people to honor, and Microsoft couldn't even do that.

Can’t help but feel no matter what they’d done there would be some route of thought that leads them to wronging the author other than just paying and using the code as is. I don’t know why a corporation would do that though as they likely have their own changes and direction they want for it and working with an unknown 3rd party on that could be a nightmare.

From the authors reaction they chose the wrong license for the project.

> If some of the peerd code was lifted from Spegel, it's blatant stealing.

Could we say "it's incorrect attribution"?

> and Microsoft couldn't even do that.

Did you consider it may have been done by an engineer who, in good faith, thought they were giving proper credit by adding it to the README? Would you want that engineer fired because of the bad attribution?

It's not like Microsoft is making millions out of this. Sure, they should fix the attribution. It's a mistake.

Most startups/small companies I've seen rely heavily on open source and fail to honour every single licence. This is bad and nobody cares. Here, Microsoft mentioned the project in the README (which is not enough, but not nothing), and I'm pretty sure that they can fix it if someone opens an issue. But overall, companies like Microsoft do honour licences a lot better than startups in my experience.

BigTech is evil for many reasons, but maybe we could consider that this is just an honest mistake.

Of course it was a mistake. In fact, as of 20 minutes ago, the mistake appears to be sorted out, with both the main license file and the offending files sporting new copyright headers.

But corporations hiding behind their workers is a no-go. Corporations get to enjoy their successes, and it's fair to hold them accountable for their failures. Least Microsoft can do is a bit of public comms work detailing what they will do to ensure these mistakes are not repeated in the future.

IIRC they were senior engineers from Google.

I can confirm. It's not a 100% occurrence, but browsing through that section ends up crashing the tab.

WhatsApp nailed the onboarding experience. In a time where other services asked you to create an account with an email and password, which is enough of a hurdle already, WhatsApp looked up your phone number and said "I'm sending you an SMS, enter the number you received to check we got it right". And then, it never asked for anything ever again.

These kinds of shortcuts are part of Apple software as a whole, and apparently have been a thing since at least OSX. These behaviors were supposed to be covered in the documentation, but I don't know how true this is nowadays.

Special mention to all text input fields in macOS having Emacs-style shortcuts.

It goes back further than that. I remember being able to buy key-combo cheat cards for System 7, and I have no reason to think the shortcuts they covered wouldn't also have been present in System 6.

Scala is not just a good functional programming language. It's also possibly the best OOP language around. The magic happens when these two aspects are combined.

This has been my personal discovery as well. I inherited a bunch of old Scala code and, having had no experience with Scala, it took a while to get up to speed.

But once it clicked, it's been a joy to work in.

The assumption that Cats Effect / FS2 / ZIO is easier than Akka / Pekko is questionable. There's the assumption that the Akka ecosystem requires the entire system to be built using the various features the ecosystem offers, when in reality it easily scales down to simple microservices just as well, if that's the only option or the overall preference.

One reason to reach for the pure functional libraries is a desire to avoid some of the many footguns Akka / Pekko has. For a long time, using Akka meant not being able to rely on the Scala type system for checking messages sent between actors, and for the people attracted to Scala due to the advanced type system, this was a deal-breaking drawback.

All in all, the FP libraries and the actor system libraries are almost direct opposite approaches to problem solving.

Well, Akka/Pekko is typed now. There is a learning curve to Akka, but it took me 3-4 weeks to get my system working. I can't imagine doing it with pure FP, it would break my brains.

There are inspiring talks on the capabilities of actor-based streams, like this one: https://www.youtube.com/watch?v=ilhImUjF53A

As someone said - these are very cool but niche capabilities that companies do not talk about. It's almost like a secret weapon in the sea of over-engineering and hype.

My favorite showcase of Scala to this day is pattern matching on regular expressions:

    val date = raw"(\d{4})-(\d{2})-(\d{2})".r
    "2004-01-20" match
      case date(year, month, day) => s"$year was a good year for PLs."

This reads better than any equivalent Java or Kotlin code, while being much easier to maintain (e.g. matching against more than one regex).

Would the kotlin equivalent just be: val dateRegex = Regex("""(\d{4})-(\d{2})-(\d{2})""") val (year, _, _) = dateRegex.matchEntire("2004-01-20")!!.destructured println("$year was a good year for PLs.") ?

The Scala snippet works for all inputs, it's something you would see on a real codebase. It also scopes the regex captures within the match expression. The code also scales better for more complex cases where a string is tested against multiple regexes, or against specific captured values.

I assume this Kotlin snippet would, at minimum, need to do null-checking on "matchEntire" before it finds its way to a production codebase.

What does the .r do at the end of the first line?

It's a method call on a String that returns a Regex type, courtesy of the Scala standard library.

This is my problem with Scala. Too many fancy things hidden behind text with no meaning. Why the hell is this ‘r’ instead of something with a name that has meaning like toRegex?

It's a convenience method for a specific case where the result is already obvious, because it's called on a string literal that already looks like a regex. Any competent Scala dev reviewer would reject code that uses the "r" method on a variable.

If you want a more verbose option, you can import the Regex type and write:

    val date = Regex(raw"(\d{4})-(\d{2})-(\d{2})")

And of course, explicit type declarations can further document the code.

> Any competent Scala dev reviewer would reject code that uses the "r" method on a variable.

Boy do I have news for you