Hacker News Reader

Comment by nicce | Hacker News Reader

At the same time Microsoft releases Garnet: https://github.com/microsoft/garnet

Good timing.

And in the HN discussion about Garnet, someone said they’d never go into bed with MS. Their argument was that MS is just going to do bait and switch and will just change the license when it suits them, therefore Redis is superior because they will always be open source licensed. What a prediction.

Garnet is a small side-project for Microsoft, that they can fund with loose change Microsoft finds in the sofa. Redis on the other hand is the bread and butter for Redis.

There's a lot less incentive for Microsoft to muck about with the license and in that sense it's not really about trust.

Companies don't do s*t if they don't see it being beneficial. Perhaps they started it because they anticipated Redis license change.

Or maybe they saw redis had some shortcomings when trying to use in their cloud offering. The thing is that once it will get popular enough that other cloud providers might add it to their offering, the license likely might also change.

Well, Microsoft and Azure seems to be fully on-board with this change: https://azure.microsoft.com/en-us/blog/redis-license-update-...

Well yes, what else would you expect from the folks who once called open source "a cancer" and came up with "SharedSource" as a replacement. Good move on releasing a genuinely open alternative, though.

MIT allows for Microsoft's "our very slightly internally changed version does behave slightly differently enough so the two can't interoperate" shenanigans, though.

> This dual-license model provides greater clarity and flexibility, empowering developers to make informed decisions about how they utilize Redis technologies in their projects.

Yeah sure.

Fully on board, but no mention if they’ll be releasing the source used to run Redis on Azure. Do they have an exemption? A separate license?

On one hand I could see why Microsoft would back the original project, since they likely don’t want Amazon owning a replacement (elasticsearch). But I’m not sure how they plan to honour the new licensing?

Ahh - side deal licensing.

“Redis will continue to support its vast partner ecosystem – including managed service providers and system integrators – with exclusive access to all future releases, updates, and features developed and delivered by Redis through its Partner Program. There is no change for existing Redis Enterprise customers.”

I wonder how exclusive this actually is. Did Microsoft pay a boat load of money to freeze out Amazon?

I think that is more that Amazon doesn't want to pay to support anything, and that includes Redis, so I don't think Microsoft paid for an exclusive deal.

Is it a research product or for production?

> Note that Garnet is a research project from Microsoft Research, and the project should be treated as such. That said, we are bunch of highly passionate researchers and developers working on it full-time at the moment to make it as stable and efficient as we can. Our goal is to create a vibrant community around Garnet. In fact, Garnet has been of sufficiently high quality that several first-party and platform teams at Microsoft have deployed versions of Garnet internally for many months now.

https://microsoft.github.io/garnet/docs

Why would they write such a critical piece of software in C# or Java for that matter what requires a whole runtime + VM installed.

Why not?

And .NET can bundle the runtime, even in a single binary if you prefer that.

> Why not?

The bootstrapping path does not exist. There is (afaik) no way to go from C compiler to working dotnet environment. You are supposed to just download binary blobs from m$soft.

https://github.com/dotnet/dotnet exists for "complete" source build that stitches together SDK, Roslyn, runtime and other dependencies. In fact, it is required by certain Linux distributions for publishing in their feeds, to be built from source in full. All components above can be built and used individually (usually), which is what contributors also do. For example, you can clone and build https://github.com/dotnet/runtime and use the produced artifacts to execute .NET assemblies or build .NET binaries.

Thanks for the information. It seems to contain only versions 8 and 9, so I guess what I said was valid only for the previous ones.

The repository looks promising, however the build.sh trying to reach to the internet during the build is disappointing. I would expect that to not help with having reproducible results. I need to look into how distributions approach this.

Domains that require network-isolated builds usually maintain internal mirrors with corresponding dependencies. It is unreasonable to expect from a project of this size to have all tooling it depends on to be available within repository files (moreover, it should build on multiple ISAs and OSes). I doubt you can build LLVM this way or, let's say, OpenJDK.

Well for example golang builds offline just fine, which seems similar in scope? Runtime-based language targeting multiple architectures and operating systems.

And yet the benchmarks are better than C or C++ alternatives, somehow.

I don't think this is an issue. You can bundle a stripped down runtime with C# binaries. If you want, you can even build it all into a single binary.

???

The JVM and the .NET clr are just runtime JIT engines. It’s not like they ship with a full O/S and a hypervisor.

VM is an overloaded term, it both means virtual computers that run some OS kernels, and runtime that runs some usually* user-space code.

* compare with eBPF

It is not about the hypervisor but a solution that pitches itself as a memory cache relies on GC is the main thing I am pointing out.

Rust would have been a better choice.

You're behind the times:

> Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

While there are limitations, this is an active area of work for future versions of .NET.

This is the best case scenario and lots of stuff would be left out, you can't use all of the APIs as is noted in the documentation.

Garnet doesn’t use those however. A lot of older libraries that do runtime code emit or unbound reflection don’t work, but a lot of others do even though they were written more than 10 years ago and were adapted to netstandard2.0 target. Either way it does not benefit much from NativeAOT given it’s expected to be long-running where JIT is more advantageous.

You can still use a lot more APIs from AOT C# than from C/C++/Zig/Rust :)

At this point C# little to nothing common with Java and builds a perfectly runnable binaries. C# is extremely capable and strong and arguably is one of the best dev platforms there is.

(On the other hand, call me an old fart, but my trust in Microsoft has been completely eroded in early millennium and did not came back.)

Because C# is a nice language that can be fast and C++ is a shit language that can be fast.

Reply on news.ycombinator.com