troupo

Any time you introduce any type of cost, you create a system where it is extremely easy to disadvantage a group of people.

Ads don't require pervasive and invasive tracking, and surveillance that Stasi would have wet dreams about.

> Safari and Firefox should isolate the cookie by default

Doesn't mean you won't be tracked by about 15 other means.

Derogatory "Free-riding users". "Free riding users" should have the same privacy as the paying ones.

> Google Chrome doesn't block third-party cookies by default, only in Incognito mode

And the focus on cookies only is also intentionally misleading. Tracking is not just cookies. Chrome will track you in Incognito mode.

> . Then the majority might want something (or not want) but wouldn't consider it important enough to spend their vote on.

Rule of the thumb: everyone will not 'just' [1]

The majority is not a single person that will somehow behave like a rational being that will count their votes and vote only for "things that matter". People view very different things as "things that matter", and the system is easily gamed. Run a few popular, but pointless votes, exhaust available winning votes for the period, then try to pass a meaningful legislation. You will have riots form people who have spent their votes, but still want to vote for something truly important.

And that's before we start talking about whether people should directly vote on removing building code regulations for example. Or whether or not measles vaccines should be mandatory.

[1] https://www.tumblr.com/squareallworthy/163790039847/everyone...

> Frankly I think the people should have direct veto power on any legislation.

Counterpoint: see any NIMBY meetings where they shut down any and all proposals and legislations, even the obviously beneficial common sense ones.

Rule by mob has rarely been productive.

Punctuation is easy in English. Especially compared to Russian.

Spelling is horrendous, and it takes a lot of time to memorize it and internalize it. And even then: https://people.cs.georgetown.edu/nschneid/cosc272/f17/a1/cha...

> if they were true direct democracies we may still see some.

I think we would see more.

Turkey is in NATO. And had no issues downing a military Russian jet that entered its airspace for a few seconds.

Meanwhile Russian military jets violate NATO airspace in the Baltics. Russian Geran drones leisurely cruise in NATO airspace.

And nothing happens. Not even when a drone strikes a residential building.

Oh, I guess "it's just Romania who cares". It's also in NATO.

At the time when the jet violated Turkish airspace it wasn't a territorial threat either. Strangely enough no jet has violated Turkish airspace since (but a few drones have landed in Turkey during the war in Ukraine).

Meanwhile Russian drones, cruise missiles (!) and planes violate NATO airspace almost daily it seems. And are being launched from within NATO arispace quite frequently (see Germany).

And no, the drones are not the "Amazon delivery drones".

E.g on September 8 Geran-4 flew 120 km unopposed through Romanian airspace, took a leisurly turn above a small town with population of ~20k people, and then flew back, eventually crashing in Moldova.

No big deal.

Some years back when a Russian jet breached Turkish airspace just for a few seconds, it was shot down.

Now it's nothing but strongly worded thoughts and prayers

So.. The market didn't actually support differentiation?

Russia has been probing NATO for several years now. NATO is a paper tiger that seems to be content to do nothing. As long as the probing is in the lesser members: the Baltics, Romania.

When (likely not if) Russia decides to attack the Baltics, NATO will just shrug and send a strongly worded memo.

Strangely enough virtually no materials on the internet show that. Everything is Executors, and Futures, and joins etc.

Even if you read much faster than you type, it's easier to read fewer lines of code than dozens of plumbing boilerplate.

> an understated update that in other years might have been called a “Snow Leopard release.”

No. It wouldn't. Snow Leopard was two years in the making, and then took another few years to actually become the Snow Leopard people remember.

Fixing some transparency and re-drawing a few icons is not a Snow Leopard release.

Like, which features in this 150000-character blog post actually warrant the title of "Snow Leopard release"?

What's Java's equivalent of

   x = await someFunction()
   await waitForSomeOtherFunction()

(both are async)

> Anyway, getters and setters are an antipattern as well since one can just as well make all the fields public.

I Java? Yes. Because of the language design, and not because of some inherent "encapsulation" or something.

Somehow `x with { a = b }` doesn't break encapsulation and offers nice DX. But object initializers? Lol

> And a class will be able to choose which things can be set, which is not the case for initializers.

The class in C# can easily chose what can and cannot be set. Because unlike Java it actually cares about things like this.

Quick example

    class Test {
        public int x { get; set; }
        public int y { get; }
    }

    var t = new Test{ x = 1, y = 2 };

I can give you a hint: this will not compile.

Another example:

  public class Matrix
  {
    private double[,] storage = new double[3, 3];

    public double this[int row, int column]
    {
        // The embedded array will throw out of range exceptions as appropriate.
        get { return storage[row, column]; }
        set { storage[row, column] = value; }
    }
  }

  var identity = new Matrix
  {
    [0, 0] = 1.0,
    [0, 1] = 0.0,
    [0, 2] = 0.0,

    [1, 0] = 0.0,
    [1, 1] = 1.0,
    [1, 2] = 0.0,

    [2, 0] = 0.0,
    [2, 1] = 0.0,
    [2, 2] = 1.0,
  };

Incomprehensible abilities for Java-land

> That code won't look that much different with async/await.

Lol. https://news.ycombinator.com/item?id=49726868

await implies async functions.

Looks like Java's "there is no simpler syntax than plain old synchronous code" is just a lot of extra manual wrangling of stuff

So, only one use case on only one part of the language.

It lists all instances, you can drill down into each one of them, see which services are affected, and each affected service pops up the incident timeline?

Isn't it actually amazing, and not "the most salesforce thing ever"?

> but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you.

So do properties in C# which object initialization relies on. With significantly less manual code, or the need for tedious builder chains and withers.

`{ prop = x }` is no more encapsulation breaking than ` .setProp(x) `, but actually makes developer experience better.

> No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds

What's Java's equivalent of

   x = await someFunction()
   await waitForSomeOtherFunction()

> Probably not a good idea since they break encapsulation by exposing internals of the class.

And thousands of manual get/set functions don't?

Thousands of lines of builders don't?

Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

> for the simple reason that there is no simpler syntax than plain old synchronous code.

But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and...

Java always opts out for "let the developer handle all the complexity all the time even for the simplest most used parts of the code".

> They really aren't, and they are IMHO an antipattern since they break encapsulation.

They don't. Java had to come up with the extremely verbose builder pattern for the exact same thing. And withers are basically the same tedious manual builder pattern, just with a different name.

For withers C# just has the with keyword: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

> Are you referring to generators?

Both I guess.

Main thing is https://learn.microsoft.com/en-us/dotnet/api/system.collecti... which seems to be everywhere in the language and the library.

> I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen.

This is mostly due language design. Java heavily relies on properties and provides no facilities for them. Hence the builder pattern instead of object initializers.

In C# object initializers synergize with properties: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

> The approach they took does not need any extra syntax.

You mean it needs 15 lines whete C# needs one? ;)

> a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do.

If you need IDE to autocomplete, then you definitely spend more time to understand what a line does ;)

Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java.

That's why you get `new List<T> { };` Because it could be `new ComplexObject { <fileds and properties> }`.

Same for `new`.

Some come from type inference which Java also has.

That's why you can have `List<T> foo = new List<T>();` and `var foo = new List<T>();`

It's not really "7 ways to assign a new empty List<T>". It's "7 ways to create an object", and Java several of them, too.

Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with.

Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two:

- Proper IEnumerable with proper iterators that in turn enables Linq (but in general permeates everything and is insanely easy to use and build upon). E.g. building an async service that behaves like an IEnumerable? Implement two methods.

Collection is halfway there, but I honestly cannot remember what was irking me about it in comparison to C#.

- Properties. Yeah, yeah, sealed classes, records and all that. Often you still need plain old classes.

- object initialisers. Which makes constructing anything a breeze. And on top of that you don't need manual .of methods for anything Colleciton-like if it'sa an IEnumerable.

- extension methods.

- named and optional arguments in functions

- null coalescing operator

- generics over primitive types (unless it was already implemented, I remember seeing a JEP about it)

- async/await. Yes, I know: different approaches to concurrency and all that. A lot of unnecessary verbiage could still probably be hidden behind a friendlier syntax.

- (sadly impossible in JVM to type erasure, only including this because I remember needing it many moons ago) generics metadata in runtime

- .... definitely a bunch more I don't remember at this point ...

> Java has a faster release schedule to get features out sooner

While still being behind on most features?