_old_dude_

yes, thanks,

Also AVX-10, E-cores and P-cores having 512 bits vector registers (see the last references).

Technically true, but Haskell forces you to use the IO monad and you can not really recover from a panic in Rust, the thread is dead.

Checked exceptions are a leaky concept in Java. The Java type system has no union types so you can not have a generics method that abstract more than one exception.

That's why Stream::map can not capture the checked exceptions properly.

In Java, no method call is safe (Haskell/Rust safe), the langage will hapilly throws a null pointer exception or an out of memory error.

But I don't think C#, Kotlin or Scala are less safe than Java even if they do not have the concept of checked exceptions.

It's a TOCTOU bug [1], a well known category of bugs.

[1] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use

Defer is more general than using, you can use it for other use cases, for logging

  logger.log("start")
  defer logger.log("exit")
  ...

for keeping alive a reference (because you need to call C code)

  global.keepalive = myvar
  defer global.keepalive = undefined
  ...
  // call C code here

etc

"using" as specified is too OOP for my taste, i think i prefer "defer" like in Golang.

  let connection = getConnection()
  defer connection.dispose()
  ...

being equivalent to

  let connection = getConnection()
  try {
    ...
  } finally {
    connection.dispose()
  }

"defer" unlike "using" does not require a specified entry point method, so no [Symbol.dispose] required.

In this case, you can do it on your CI as part of the deployment, so it's not that bad.

Given that van replace the whole tree each time a value changed, SSR for van is simpler. You run chrome server side, capture the DOM once van has finished its first execution and modify the HTML of the page to includes the new nodes.

No shadow dom, so no mount/unmount logic ! A whole new DOM sub-tree is re-created each time a value change.

There is an example in the tutorial about how state are handled [1]. [1] https://vanjs.org/tutorial#state-binding

That's a lot of lines to say that dynamically loadable agents will not be enable by default in Java 21 [1].

I suppose it's to avoid sneaky libraries that dynamically starts an agent to crack open the code of the JDK.

[1] https://bugs.openjdk.org/browse/JDK-8306275

Almost 10 years ago, i've tested erjang [1] using a medium sized application. Throughput was better than BEAM but latency was terrible.

[1] https://github.com/trifork/erjang/

For the context, I'm re-reading Java concurrency in Practice now so I see publication issues everywhere.

I believe the issue is between the profiler thread and the shutdown hook thread. Both will run concurrently because the profiler thread is marked deamon. So the shutdown hook thread can see the Profiler fields not fully initialized. The call to addShutdownHook() should be done outside of the Profiler constructor.

Hi.

I believe the code of the constructor of Profiler is not thread safe, it has a publication problem. The method onEnd can be called by the profiler thread while the fields options and store are not fully initialized.

From another thread POV, a final field is only fully initialized after the call to the constructor not inside the call to the constructor.

You can add a 'case null' explicitly and merge it with default using 'case null, default -> ...'.

See [1] for more.

[1] https://openjdk.org/jeps/433

It starts that way, with a mark and sweep collector (think Java CMS or the GC of Go). But some applications like games or Facebook are monsters so the GC was changed to a copy collector which has a better throughput, avoid fragmentation at the cost of using more memory.

Also the code is not just AOTed, Android is using profile guided AOT. After several days of usage, the code is AOTed with the profile collected from previous runs.

> the entire mechanism was designed for security ...

I don't have the same definition of security (i've read the JEP). Unlike TypeScript, you can not type the template values.

> built-in template processors, STR and FMT, don't do boxing ...

but all the others user-defined template processors (think a logger) are second class citizens and will do boxing.

Efficient String interpolation is hard without macros, that's why it's a macro in Rust.

This JEP tries to solve a harder problem, user defined template processors but do not provide the tool to make them efficient and never will. Are you suggesting that there is a JEP about macros in the making ?

That's why JS use ` and not reuse ".

You want the lexer to be able to make the difference between a constant string and a template string and you want users to be able to read the code.

This JEP solves the former not the later.

It seems the design team has lost its mojo.

First, the lesson of Log4Shell have not been learnt. Allowing more libraries to do formatting, what can go wrong ?

And String.format() is slow because every values are boxed. This JEP repeats the same mistake with the templates.

There is a concept of internal layoff to invent, where a part of the workforce as to apply to a different teams, being fired from the previous one and hire by the next one.

For the anecdote, i know someone that was let go by IBM and hire by RedHat the same month two years ago.

Java 17 adds records, which are a more blunt tool than using const on method, you have to choose if a class is mutable or not, and not if a method is mutable or not.

For microservices, where you deals with data, it's quite effective because it works like typed JSON.

He played it last month at Santiago de Chile.

yes, Java/C# GCs (Android included) and Go GC are very different beasts.

Go GC does not move objects in memory (mark and sweep) while other GCs (mark and compact) do, to avoid heap fragmentation and better throughput (see generational GCs).

One issue with mark and compact GCs is that you can not move the array of bytes during a system call. A ByteBuffer/Memory object, is an object that allocates its byte arrays using malloc, outside of the heap, so the bytes are not moved by the GC.

I believe this is a case where a named tuple of functions, a record, is better than an interface.

    public record Lens<A, B>(Function<A, B> get, BiFunction<A, B, A> with) {
      public <C> Lens<A, C> compose(Lens<B, C> inner) {
        return new Lens<>(
          inner.get.compose(get),
          (a, c) -> with.apply(a, inner.with.apply(get.apply(a), c)));
      }
    }

    Lens<Confirmation, LocalDateTime> $updatedOn =
      new Lens<>(Confirmation::updateOn, Confirmation::updateOn);

"mold", but the mold is also an instance of a mold.

    i = c()
    print(i.a)
    i.a = 42
    print(i.a)

During the last 10 years, the Java ecosystem has heavily invested in reactive APIs, so it's not like if Java devs have no option.

And IMO, the semantics of any reactive APIs is better than just providing await.

Await serializes the async calls instead of running them concurrently. And too few C# devs are aware of/using the Task API.

This is especially true in JavaScript. Inheritance between classes is implemented using delegation and the global scope is dynamic.

It's the classical representation of affine transforms (translate, rotate, scale, etc) using homogeneous coordinates.

https://en.wikipedia.org/wiki/Transformation_matrix#Affine_t...

It depends if List<double> is an alias for List<@PleaseSpecialize @NotNull Double> or not.