emccue

I'm not really putting too much effort to call attention to that rn, i'd rather wait

This is a book intended to teach someone the Java language, from scratch.

You will find that the content makes heavy use of recently released and, for the moment, preview features. This is intentional as much of the topic ordering doesn't work without at least Java 21.

Right now I have several key areas where I could use some help:

* Writing Challenges. Most of the early sections have challenges students can do to test their understanding of the topics covered and for practice. I've shifted my focus away from these to make more progress on the main content of the book. Any assistance would be appreciated.

* Theming. A lot of the chapters are...bland. Purely technical. I find that when I have the imagination to "theme" the subjects they become higher quality and more engaging overall. See an anime you liked recently and think you can make the math chapters use the characters from it? Give it a shot!

* Fixing Mechanical Issues. I don't have an editor and I don't often proofread. If you find mechanical errors in my grammar or find issues with the way topics are ordered I would welcome fixes.

Notably I do not want to open the floodgates for contributions on the main chapter content just yet. This has the downside of slower progress but the upside of a more coherent result.

My primary goals with this are

* Get the ordering of topics right. By this I mean that every topic covered should have had its prerequisites covered in the topics previous. While "lesson 1: Inheritance" is clearly wrong in this regard, some things are more subtle.

* Be a template for other people. This is a book. Not everyone likes books, some like youtube videos, some like over priced udemy courses, some attend College, etc. Everyone has different learning paths. I hope this to be of use to anyone looking to make a more up to date Java curriculum and hope that the vague order of things (which I consider superior to the content produced with the Java of years' past) is carried through.

* Write as if the newest Java wasn't new. It's obvious when a book was written before Java 8 because it always has newer additions with "addendum: brand new stuff in Java 8." But the order language features were introduced is hardly a good order to teach them. You have to pretend that Java 23+ has always been the Java. Does it really make sense to show terrible C-style switch statements way before switch expressions?

* Write as if the words Object Oriented Programming, Functional Programming, etc. didn't exist. While I understand that these all have definitions and are useful concepts to know about, introducing them early seems to lead to either dogma, rejection of said dogma, or some mix thereof. None of them are actually needed to understand the mechanics of and motivation behind what we would call "object oriented" or "functional" techniques. They certainly don't work as justification for adding getters and setters to every class.

My immediate short term goal is to get this "ready to go" for when anonymous main classes is in a stable Java release. Thats the point at which we could start to:

* Have actual students go through it without also needing to explain the --enable-preview mechanism.

* Use the topic order to build other sorts of non-book resources like videos, curriculums, projects, etc.

* Convince actual teachers to change from "objects first" to something less insane.

I haven't integrated println or readln yet, but will do so eventually.

I do not know enough about vector search to assert pgvector is enough for you, but I do know enough about supply chains to get woozy

Using SQLite locks you out of some platforms as a service and out of some application architectures. It also means you need to be doing stuff like snapshotting your VM every x minutes.

Given minimal certainty about the scale, future, and properties of your application and organization: Postgres is the better default.

In my defense, I hadn't watched his talks _recently_ and we've all been Berenstain Bear'ed a few times.

But also the comparison of DynamoDB/Cassandra to MongoDB comes directly from his talks. He currently works at MongoDB. I understand MongoDB has more of a flowery API with some more "powerful" operators. It is still a database where you store denormalized information and therefore is inflexible to changes in access patterns.

Would you believe I don't have an editor?

    null-marked module accounting {
    
    }

What is the thing you want me to do?

java --enable-preview Main.java

Things generally exit preview after ~2 releases.

(I do really like CheerpJ if only because it enables software preservation.)

This was done as a senior project @ University of Central Florida. Using the github org made things simpler for the students to work on it. (Everyone has to learn git at some point.)

- Its not using the whole orchestrator...thing. That was some complex code and we made a Practical Choice.

- No equivalents for a lot of the rust tools. Choices aren't as straightforward as for the cargo/rust world. I do intend to at least add JUnit testing as an option though.

- Its not building things from source, which means I need to manually update download urls every now and then.

- Might not be running on a big enough machine. Lets see if HN hugs it to death.

    var remoteResultA = callRemoteA(client);
    var remoteResultB = callRemoteB(f(remoteResultA));

What virtual threads give is the ability to write the code like I did above and still get ideal performance, as opposed to.

    callRemoteA(client)
       .then(remoteResultA -> callRemoteB(f(remoteResultA)))
       .then(... your world lives here now ...);

The big difference is that for each regular Thread you have exactly one backing Operating System thread.

I'm a bit perplexed tying to figure out how any of these criteria is a reason to choose D over rust

There are remarkably fewer demented people as a result of people taking Hydroxychloroquine.

But you have to remember that Forbes, the magazine, is run by a bunch of actual human beings. You can find out what criteria they use by asking them or observing their behavior or a million different ways.

You can then craft yourself to fit that to a T. You very clearly have enough money to have the time to make a plan and execute it. Rather than unachievable, impressing a handful or so of people is absolutely table stakes.

---

That being said, there is clearly something deeper going on here. I'm not gonna nail it first try and I'm sure if you get other comments they might make a stab at it too, but why do you want this?

Like hard facts, most people do not give a teleporting fuck about that list. Even looking at it and seeing the faces of some schmucks I still - yep - don't give a shit.

If you think it could open some specific career path or be a useful bit of leverage or whatever...ok? Your plan to get on the list of people "good at business" is effectively right now "be good at business". Seems like a Catch-22 in that for folks they list the publicity of the list probably wouldn't make or break them.

Are you trying to impress some particular people?

You need to not have this as a goal. It's only loosely correlated with being a business success which is in turn only loosely correlated with your happiness.

> I feel like I am on the right track but missing something else entirely.

Memento Mori dude. You have a fucked set of priorities

^ among other "great hits" from those absolute wackos. Hard to emphasize how bad these "fine at first glance" bullshit sites are.

For the first point - val/var

"More importantly, it doesn’t offer its immutable counterpart, val. You still need to add the final keyword, which nearly nobody uses."

This super undermines the criticism. "It has the feature but people don't use it" isn't exactly much to write home about. Just use `final var` if you want. Make "final var over var" the same force culturally as JS's const over let"

"However, the developers of Optional designed it for return values only. Nothing is available in the language syntax for methods parameters and return values. To cope with this, a bunch of libraries provides compile-time annotations:"

This flow of causality here is slightly incoherent. The phrasing implies that if there was a version of optional that was designed for method parameters that would be better and there would be less of a need for compile-time annotations. Here it is

    sealed interface Option<T> {
        record Some<T>(T value) implements Option<T> {}
        record None<T>() implements Option<T> {}
    }

https://www.youtube.com/watch?v=Ej0sss6cq14

It is true though that Kotlin has a more consistent story here, but there are active efforts to improve it for Java.

Also, the discussion of extension functions points out that static methods cannot be chained like instance methods - correct - but doesn't really discuss the other end of the tradeoff. That is that there need to be rules for whether an extension function is "in scope" which can make local analysis for humans harder.

There are also other pretty trivial options for doing static method chaining if that is what you want stylistically.

    record Pipeline<T>(T value) {
        <R> Pipeline<R> map(Function<? super T, ? extends R> f) {
            return new Pipeline(f.apply(value));
        }
    }

    ...

    final var result = new Pipeline<>("abc")
       .map(StringUtils::capitalize)
       .map(String::split)
       .value();

     val result = "abc".capitalize().split();

I would have used .startVirtualThread more if I wasn't under the impression that I needed to do Thread.currentThread().interrupt() when catching and re-throwing as a RuntimeException.

So I was choosing between the noise of that in the examples and the noise of the executor + submit with a lambda that returned null.

I only started doing this recently after this advice here

https://discord.com/channels/544924237773668373/930457954346...

I'll clear it from the examples

Nearly all SQL Database access goes through it and it won't be rewritten in any practical time scale. It can't be meaningfully async without a rewrite and kotlin's coroutines can't change that.

With virtual threads that synchronous api can be used at the performance level of what a hypothetical JDBC rewite would give.

(Not that you want to hit your DB that much, but you know what I mean. You don't need to specially wrap or bundle apis to get into an async call juggle.)