It would allow him to brutally roast anyone who submits a sub-optimal merge request.

Linux still works by email-submitted patches, the workflow for which git was originally designed.

And if an unacceptable patch made it to Linus's desk, someone downstream hasn't been doing their damn job. The submaintainers are supposed to filter the stupid out, perhaps by more gentle guidance toward noob coders. The reason why Linus gets so angry is because the people who let it through should know better.

I made a pretty convenient C vector library a while back that lets you use the [] operator directly on the vector pointers: https://github.com/Mashpoe/c-vector

A neat project that was posted here a while back uses it: https://x.com/kotsoft/status/1792295331582869891

The author talked about cursor latency being worse with Wayland, and claimed that it was likely a consequence of the major architectural differences between X11 and Wayland. Is this an inherent drawback of Wayland, or is it just something that's true for one implementation, e.g. GNOME?

It's a implementation issue(or a driver), Wayland don't dictate the mouse latency, and compositors are free todo whatever they want with it

I figured. I'm not sure if the author meant that it was an inherent drawback, but it does seem like he still has a bit of lingering bias towards X11 in his reassessment article.

Scratch is the only type of visual programming I've enjoyed using. It's easy to read if you're an experienced programmer because it has the same structure as regular code, and it's easy to read for beginners because everything is broken into large blocks that have what they do written right on them. The way code is structured in most programming languages is actually very logical and intuitive, and it's the most successful system we have so far. The problem for beginners is that they can't figure out if they enjoy programming until they've learned the syntax, which can be very discouraging for some people. I've seen Scratch bridge that gap for people a couple of times, and I think it's probably the best model when it comes to teaching people to code.

I think other types of models would only be useful for situations where writing code isn't the most intuitive way to make something. From my limited experience, a visual system for making shaders is a pretty good idea, because ideally, you don't want to have many conditional branches or loops, but you might have a lot of expressions that would look ugly in regular code.

It's weird being able to highlight animated text like this

It's very cool that on Android the text selecting tabs will even rotate around too with the text

Anyone who knows anything about VPN services knows that they don't stop people from looking in on what you're doing; they only stop people other than the provider from doing so.

Most if not all of the big VPN providers collect data and give it to law enforcement, which isn't exactly news to us.

Tom Scott had a pretty good video on what VPNs can actually deliver on, despite the claims of many sponsored content creators. He lost his VPN sponsorship because he pointed out, among other things, that you don't actually have guaranteed privacy with these services.

My read is that it was more about the stuff he was calling out as legitimate[1] use-cases (which iirc included piracy).

ETA: I'm surprised these providers are even able to market with the use-case of evading geo-locking without getting sued (tbc I'm against drm in general and geo-locking in particular)

[1] from the standpoint of, "is this a good reason to use a vpn", not "does society/the law consider this a legitimate thing to do"

I doubt it is against the laws where the provider is located.

Geo-locking isn't a law. It might have been part of the tpp that the US never signed.

Certain marketplaces don't allow vpn advertising or wording like that.

In reality they act as a Canadian store selling drugs to the US customers at a discount.

> It lets a lot of innovation happen in other languages, then takes the successful parts for itself

The only time I've ever had to use Java was for a computer science class, and I thought it was a solid language (pun intended), but I hated its half-assed attempt at operator overloading.

I think it's a major feature that's long overdue to be fully implemented in Java, because it's already used for some of Java's built-in classes and it's proven useful in many other programming languages.

Most of Java seems very well-thought-out to me, but for some reason they decided to add only some operator overloading, instead of planning ahead more.

I remember hearing somewhere that they were planning on adding operator overloading, but last I checked it didn't look like it was going anywhere.

Java chose not to implement (general) operator overloading because it's really hard to do right. We're left with just a fluent syntax for appending text to strings.

Java was one of the first language specifications to be written by adults (maybe Common Lisp was the first, but it drives Common Lisp fans crazy to compare Common Lisp to Java, Python, etc.)

Python's operator overloading works remarkably well given that it has a very simple model (always look to the left hand side to decide how to interpret the operator.) C++ on the other hand ought to make anybody skeptical of the idea, but C++ would make anybody thoughtful and sensitive question the idea of computers entirely.

> Java was one of the first language specifications to be written by adults (maybe Common Lisp was the first, but it drives Common Lisp fans crazy to compare Common Lisp to Java, Python, etc.)

I think ALGOL was first, in the ALGOL 60 Report (https://en.m.wikipedia.org/wiki/ALGOL_60#History). COBOL may have had a good spec around that time, too.

There were older languages with specifications, but those specifications were looser, with languages partly defined by their prime implementation.

Well, neither Java, Common Lisp nor ALGOL60 support operator overloading, so there does seem to be a trend there.

Common Lisp in fact, as most lisps, has no support for "operators" in the infix sense at all. If you have a need for a very algebra-heavy portion in your program (say, a linear algebra library), the best idea would be to define a DSL for that particular algebra - especially since this will give you much more control over efficient evaluation than using the built-in evaluation order.

A good example of the limitations of simplistic operator overloading is matrix algebra: A+B•C can be computed efficiently as a ternary operation, more efficiently than doing A+B then multiplying the result by C. Now of course, you can implement this in C++ by having operator+() return some kind of matrix_addition object, and then defining the efficient operations in operator*(matrix_addition, matrix) etc, but that is much more roundabout than defining a simple addAndMul(A,B,C), or an explicit optimizing DSL.

There are reader macros which provide a more math-like notation. Those are translating the math syntax into Lisp s-expressions at read-time.

Yes, that's the DSL concept I was talking about.

The lack of operator overloading makes it impossible to implement new numeric types in a consistent way. For example imaginary numbers or numbers with units.

You can make the case that both intX (x=16, 32, 64) and floating point are bad for general purpose computing. Like Common LISP and Python, Java has bigints and rationals in the stdlib, but Java makes you use non-operator syntax to get at them. Contrast that to Clojure which puts them on your fingertips.

Java has always been in a strange place of not deciding if it wants to be a systems or application language. (The standard architecture is that demanding systems, say video games, are written in both a systems language and a scripting language. A Python coder feels smart when the incorporate, say, number is written in C or FORTRAN but Java’s xenophobia makes that feel like a personal failure. Java is ‘good enough’ for applications programming that you might find something like Spring or Guava gives you all the dynamism you need with less hassle than adding an embedded scripting language like Groovy or Clojure.)

If there's no implementation on the left, python then looks on the right.

If you are serious about using the JVM, I would suggest Kotlin or Scala as a better alternative to Java as they have all the libraries and greatness of the JVM but they have less of the historical baggage that Java brings with it.

Both can be written in a Java like fashion to start, and have 100% interop with Java (you can mix the languages in projects) so the learning curve is pretty alright.

That is the frying pan to the fire.

JDK 17 has most of the good features of Scala and Kotlin.

Scala seems to be designed so that you can write a short book with very fluent and natural looking demos. Make a small deviation from that and there is nothing fluent or natural about it.

Kotlin is OK but isn't sufficiently better than Java to be worth using when any Kotlin dev is going to have to know Java and Java-Kotlin mapping pretty well to use libraries. (It's a similar problem to Typescript.)

Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit. I'd point to Clojure as a language that is radically different from Java AND that takes advantage of the strengths of the JVM to be worth the cognitive load of having to know both a new and old language to be productive.

> JDK 17 has most of the good features of Scala and Kotlin.

I keep reading on HN that "Kotlin isn't much better than Java X". Having used Java and Kotlin (mainly targeting JVM) full-time for 6 years, this doesn't match my experience at all.

Here are some of my favorite Kotlin improvements over Java that I leverage all the time:

* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)

* Local variables are final by default ("val")

* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)

* Much improved collection API

* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)

* Extension functions (incredibly useful in practice)

* Much better DSL capabilities (great for UIs, generating HTML, etc.)

* Lazy properties (more generally: delegated properties)

* Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years)

* Great serialization support (kotlinx.serialization)

* Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate)

* Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)

Although I'm glad to see that Java is still improving, it will never get close to Kotlin. The most obvious reason is that many of Java's early design decisions were revised in Kotlin but are impossible or impractical to revise in Java. Also, Java carries the burden of being a platform language, whereas Kotlin can focus on being the best possible application language.

These days, I only use Java for libraries intended to be used from languages other than just Kotlin. In that case, I don't want to force Kotlin on users (stdlib dependency, debugging, etc.).

> Kotlin is OK but isn't sufficiently better than Java to be worth using when any Kotlin dev is going to have to know Java and Java-Kotlin mapping pretty well to use libraries.

One of the big benefits of Kotlin is that if you know Java, you pretty much already know Kotlin, too. A good Java dev can get spun up on the basics in a day or two.

> Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit.

Kotlin provides a ton of ergonomic features that I absolutely adore. Named parameters and default parameter values alone save me tens or hundreds of lines of code.

I think of Kotlin as what would happen if a Java developer looked at Javascript and asked "okay, but what if this didn't suck?"

> I think of Kotlin as what would happen if a Java developer looked at Javascript and asked "okay, but what if this didn't suck?"

I think you mean "what if we took C# and put it on the JVM"? /s

Honestly, C# has had most of the features Kotlin "adds on" to Java for years, even decades.

Kotlin's future is tied to Android, on the JVM I don't even care it exists.

How so? While yes Android is one of the most common uses at the moment for Kotlin (thanks to Google making it a first class supported language for the platform) it is still dependent on the JVM, thus can do anything that Java Can.

> Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit

Sorry but "no real benefit" seems to come from a position of ignorance.

I can only talk about Scala which I know pretty well.

While Clojure is a radical departure from Java, being a Lisp, Scala is a departure thanks to its type system and features that help you writing more functional (as in functional programming) code. And I mean this in a good way: it helps you avoid mutations and side-effects, while giving you the freedom to use good old OOP if you wish so. In general it provides tools that help you better express your intent that Java doesn't have.

I think that Java has too much baggage to ever become as good as Scala, especially on the type system side, and, in addition, Scala is also moving forward.

Also don't forget Scala.js [1], which is rock-solid and just plain amazing, and Scala Native [2].

[1] https://www.scala-js.org/

[2] https://scala-native.readthedocs.io/en/latest/

Honestly, the null safety and constructor initialisation of properties in Kotlin alone make it worth it.

> JDK 17 has most of the good features of Scala and Kotlin.

I'd be sooo happy if that were the case, but sadly, it's not. From the point of view of Scala, I still see many features missing. Roughly in the order of importance:

* Immutable persistent collections in the standard library (and thus lingua franca in the libraries). Just so much better than mutable collections. Way less headache. Once you start using them, you realize how rarely you actually need mutable ones.

* Pattern matching. Java will surely improve on what is currently available. But why wait? It may take a long time.

* Sophisticated string interpolation. It's powerful, and yet is still easy to read. Again, Java is on its way to get it, but with Scala you can have it right now.

* Type Classes. Sometimes it is very good design to separate data from functionality. Java designers (Brian Goetz IIRC) mention they would like to get this eventually. Scala has an interesting design of Type Classes -- "givens" -- which is also modular (in contrast to Haskell). Scala also has an elegant mechanism for Type Class derivation using the "derives" clause. https://docs.scala-lang.org/scala3/reference/contextual/deri...

* for-comprehension syntax and IO/Task/ZIO for async programming. Project Loom still hasn't delivered. But Scala has you covered. It gives you for-comprehension syntax, so that you don't have to suffer from nested callback hell. And there are many great libraries for async programming, like ZIO or Cats Effect. These are easier to work with, compared to other Futures from various Java libraries, because they're lazy, not eager. for-comprehension syntax is also useful for other things, it's just that async is the typical usecase.

Higher-kinded types. Not everything has to be super fancy higher-kinded type-level craziness. And very often one gets away without needing to use higher-kinded types and that's good (just as often a solution without parametric polymorphism aka generics is enough). But other times it's awesome to have this power of abstractions. Typically, but not only in libraries.

* Object. Sometimes you just need to have an object (which might implement an interface/class/trait). But Scala doesn't force you to create a whole class, if you only even want just one instance anyway. A small thing, but way more elegant.

But I'm really happy to see Java/JVM improve. The 17 release has brought some great features, but in the language level (records, embryonic pattern-matching, ...) and the VM level (GCs in particular). We all benefit more or less directly, one way or the other.

Also, Scala’s optional null checking (where null becomes a type that is not at the bottom of the type hierarchy) is really cool!

All in all, I do find using Scala can absolutely worth it, but I really don’t feel it with Kotlin. It feels like a watered down Scala, and add to that where modern Java currently is, I feel it is not needed.

Also Java doesn't run on android? Not 17 anyway...

I guess you could try to argue mobile is bad or something, but you get Kotlin not JDK on mobile.

Yes, Clojure is probably better, but on the flip side as a developer knowing Java 8 and Kotlin is better than knowing Clojure and JDK 17. Perhaps you can point to some salaries here but Java developers are not in short supply, if you wanted to play that game there are better languages for more lucrative payout (assuming you can even get them, these tend to be boutique shops not generally hiring publicly)

Scala has just as much historical baggage imo. It's community is split between functional zealots and "better java". You also have the Scala 2/3 split that is currently going on and just the general complexity of the language makes it not so appealing.

IMO if you're serious about using the JVM you should be using Java 17 and following the latest version. Kotlin is usable, but it doesn't bring that much more to that table other than longer compile times.

Why do you feel that Scala has just as much historical baggage? Isn't the whole point of the Scala 2/3 split to remove historical baggage.

The community split is what makes Scala better in my opinion. The fact that you can have the split between functional first and better java people is a nice thing to see over Java where if you want to do functional programming, you are a second class citizen.

I was really into Scala ten years ago, but felt that a "Scala--" might be more accessible to most devs and hurt Scala adoption. Lo and behold, we got Kotlin.

But isn't the great thing about using the JVM supposed to be not using Java?

Or at least the perf advantages it brings. Java has nice stuff today maybe but one could argue that it is primarily defending market share that caused Oracle to move forward with its language updates.

I'm inclined to say the opposite, the more the JVM stays healthy and the stronger the third party ecosystem the more likely it doesn't become a 'dead' language like COBOL or FORTAN (not dead but in terms of marketshare).

They may have a little less of the historical baggage, but that's still a lot of baggage. Same goes for F#. It's a shame that three of the best programming languages in existence are built on top of Java and C#, instead of doing their own thing. Admittedly their VMs are mostly fantastic, but trying to reuse libraries and language constructs has just created more problems.

Some say "historical baggage", others say "backwards compatibility"... two sides of the same coin...

I don't even get the idea of these web versions. They just seem like buzzwords to me.

Sure there are differences in the general trends with how people interact with the web and internet, but it's more complicated than that.

I understand the difference between Web1 an Web2 since web pages have become a lot more interactive over the years, but that doesn't justify making special terms for old and modern sites. Nobody goes around saying "this website is Web1 and this one is Web2." If a website looks old you just say it looks old.

There's no specific cutoff point that makes sense for web versions. Websites have slowly become more and more interactive over the years. Since pages started to become interactive, there have been so many changes to the web that are arguably just as worthy to get their own version numbers. CSS has gained so much more functionality, JavaScript has become a compilation target, and with the advent of WebAssembly, virtually any programming language to be used on the web.

All of the things that make Web3 different from Web2 seem like niche use cases for the web, not something that will replace everything like more interactive web pages have. There won't be any decentralized websites, there will just be a bunch of regular websites where you create an account to interact with technology that has been around for over a decade.

The other changes I mentioned actually pertain to the web, while the trendy stuff like the "metaverse" and "blockchain" actually have nothing to do with the web. Maybe they can interact with the web, but a lot of things can interact with the web. With the click of a button I can have virtually anything delivered to my doorstep, but for some reason owning a picture of a monkey is more impressive to some people.

> I don't even get the idea of these web versions. They just seem like buzzwords to me.

They are buzzwords. There was no Web 1.0. The "Web 2.0" was coined as an umbrella term for AJAX-using sites that allowed a lot more interactivity. It's not like some product got a version bump. It became vogue to refer to older style static or HTTP form POST sites as "Web 1.0".

Now the cryptobros are trying really hard to push "web3" as a buzzword for their dystopian blockchain based nightmares. Tim Berners-Lee had already started pushing "Web 3.0" to describe the semantic web technologies he's very excited about.

I feel like the added complexity of digital storage just means there are more ways to attack and there's more that can go wrong in general. Physical documents can only exist in one place at any given time and are probably much easier to protect.

In case you aren't joking, inheritance in the context of computer programming (for simplicity's sake) is just a metaphor that's supposed to make computer programming easier and has nothing to do with economics.