Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Garnet – A new remote cache-store from Microsoft Research

github.com

Post reply on HN
Print view View original

71–80 of 120 posts

Re: Garnet – A new remote cache-store from Microsoft Research

#71

Post by CharlieDigital »

zigzag312 wrote: post #32
amir734jj wrote: post #14

Earlier quoted context omitted.

If you look at the store code you see a lot of "unsafe" C# code (i.e pointer manipulation)

Shows how flexible C# is. You can trade high-level expressiveness for low-level control where needed and you don't have to deal with any FFI to do it.

C# and .NET are both truly underrated in the wider community -- I think -- because of some early snafus. The late adoption of an OSS model, Windows-centric in the .NET Framework days, too dependent on Visual Studio for a very long time.

Nowadays, I think it's probably the most natural language and platform for teams that need to move on from TypeScript rather than Go or Rust given the similar constructs and idioms.

Re: Garnet – A new remote cache-store from Microsoft Research

#72

Post by caleblloyd »

> Garnet being multi-threaded, `MSET` is not atomic. For an atomic version of `MSET`, you would need to express it as a transaction (stored procedure).

I am having trouble understanding this. Why wouldn't they wrap that in a transaction internally for you, and make the command atomic? What other atomicity "gotchas" are there.

Re: Garnet – A new remote cache-store from Microsoft Research

#73

Post by zinclozenge »

withinboredom wrote: post #48
jiggawatts wrote: post #18

I just wish they had something like this embedded into Azure App Service, so it wouldn't be necessarily to use a remote service for caching. For reference, something commonly used with IIS for ASP.NET apps was to have an out-of-process "session state" store, so that if the web app process restarted, users wouldn't lose their sessions and have to log in from scratch. Sure, you can put this somewhere central like SQL S…

This is (one reason why) I love k8s with cilium. I can set up a service to always go to the local service (or any other routing topology). It is great for any kind of dns or application cache.

Can you point to any resources to read up on this?

Re: Garnet – A new remote cache-store from Microsoft Research

#74

Post by byteknight »

sumtechguy wrote: post #61
akvadrako wrote: post #47

Earlier quoted context omitted.

It's weird since DNS is one of the most rock solid systems we have, with redundancy at every level. 1. Clients query a list of servers (IPs) and handle failover when you don't quickly get a reply. 2. Most of those servers at the root and TLD level are actually anycasted from multiple locations globally, so you connect to the closest instance. 3. Those instances are often clusters of physical servers. The big ones hav…

In my years of doing this sort of thing. I only had it really be DNS once. The issues I usually see blamed on DNS is when DNS is 'abused' to do things like load balancing and the TTL is very small. Then you need goofy things like 'sticky sessions' and what not to work around that.

Assuming you didnt manage connectivity of systems very long or very many. I find it difficult that not being true with you saying it happened "once".

Re: Garnet – A new remote cache-store from Microsoft Research

#75

Post by danbruc »

caleblloyd wrote: post #72

> Garnet being multi-threaded, `MSET` is not atomic. For an atomic version of `MSET`, you would need to express it as a transaction (stored procedure). I am having trouble understanding this. Why wouldn't they wrap that in a transaction internally for you, and make the command atomic? What other atomicity "gotchas" are there.

Because it would mean a performance penalty for everyone who does not need MSET to be atomic without being able to opt out of that transaction. On the other hand, if you want to be a drop-in replacement for Redis, then this is an issue as Redis guarantees atomicity. Maybe you could have a configuration option that lets you select between compatibility and performance, at least if being a drop-in replacement is a design goal.

Re: Garnet – A new remote cache-store from Microsoft Research

#77

Post by jameshart »

Terretta wrote: post #59
moritonal wrote: post #36

Earlier quoted context omitted.

Could you expand on "It was the opposite of DNS: it was never a problem."? Feel like I'm missing some interesting history here.

Meme this is referencing should be "It's always DNS config ."

Mostly. But it can also be DNS request volume, DNS cache expiry, DNS response times, DNS connection contention, DNS security, DNS error handling, or DNS client configuration.

All variants of ‘DNS is working perfectly, just your expectations of how it will work in your situation are not completely correct’.

Re: Garnet – A new remote cache-store from Microsoft Research

#78

Post by mdaniel »

CharlieDigital wrote: post #71
zigzag312 wrote: post #32

Earlier quoted context omitted.

Shows how flexible C# is. You can trade high-level expressiveness for low-level control where needed and you don't have to deal with any FFI to do it.

C# and .NET are both truly underrated in the wider community -- I think -- because of some early snafus. The late adoption of an OSS model, Windows-centric in the .NET Framework days, too dependent on Visual Studio for a very long time. Nowadays, I think it's probably the most natural language and platform for teams that need to move on from TypeScript rather than Go or Rust given the similar constructs and idioms.

For a while there I had high hopes that one could pull in Java libraries via their JVM interop on top of the Common Language Runtime, but it doesn't seem to have caught on and I'm not in that ecosystem enough to know why. But yes, for the many excellent reasons you cited it means the library ecosystem is nowhere near that of the JVM, and thus I haven't once considered .net for a new project regardless of how much I love C# the language. Well, that, and my experience with the observability and introspection components of the JVM are second to none

Re: Garnet – A new remote cache-store from Microsoft Research

#80

Post by ametrau »

CharlieDigital wrote: post #71
zigzag312 wrote: post #32

Earlier quoted context omitted.

Shows how flexible C# is. You can trade high-level expressiveness for low-level control where needed and you don't have to deal with any FFI to do it.

C# and .NET are both truly underrated in the wider community -- I think -- because of some early snafus. The late adoption of an OSS model, Windows-centric in the .NET Framework days, too dependent on Visual Studio for a very long time. Nowadays, I think it's probably the most natural language and platform for teams that need to move on from TypeScript rather than Go or Rust given the similar constructs and idioms.

It’s great but you’re locked into visual studio if you want the most out of it (they put 95% of their effort in tooling there). You want to use visual studio?
Post reply on HN