yes, but that's just one part of the equation. machine code from compiler and/or language A is not necessarily the same as the machine code from compiler and/or language B. the reasons are, among others, contextual information, handling of undefined behavior and memory access issues.
you can compile many weakly typed high level languages to machine code and their performance will still suck.
java's language design simply prohibits some optimizations that are possible in other languages (and also enables some that aren't in others).
> java's language design simply prohibits some optimizations that are possible in other languages (and also enables some that aren't in others).
This isn't really true - at least not beyond some marginal things that are of little consequence - and in fact, Java's compiler has access to more context than pretty much any AOT compiler because it's a JIT and is allowed to speculate optimisations rather than having to prove them.
It can speculate whether an optimization is performant. Not whether it is sound. I don't know enough about java to say that it doesn't provide all the same soundness guarantees as other languages, just that it is possible for a jit language to be hampered by this. Also c# aot is faster than a warmed up c# jit in my experience, unless the warmup takes days, which wouldn't be useful for applications like games anyway.
Precisely right, but the entire point is that it doesn't need to. The optimisation is applied in such a way that when it is wrong, a signal triggers, at which point the method is "deoptimised".
That is why Java can and does aggressively optimise things that are hard for compilers to prove. If it turns out to be wrong, the method is then deoptimised.
As others already pointed out, UUIDv7 is a solid choice and if you don't like the default representation, you can encode the underlying byte array with base62 for example, to get short, URL-friendly IDs.
That is not quite true. Google did much of the research OpenAI used to build ChatGPT. It is just that OpenAI came up with the first popular mainstream AI tool.
Just look what Google does with its Tensor Processing Units ... they are developing AI chips for a decade now!
This story reminds of Scala. The language as such is also fine, but has (had?) a cultural problem. There functional programming fundamentalists always promoting the purest solution without solid reasoning - as if god had decided that only pure functional programming is your ticket to paradise. In addition, Scala comes also with powerful language features to build abstractions, like traits, generics, and almost arbitrary names for classes, objects, and functions. All that lead to a culture of unreadably "try to be clever" code.
I'm not sure whether the Scala authors paved the way with methods like :\ (fold left) or whether that happened, because the language had the features, but I tend to assume the latter.
It is a great responsiblity of a language designer to think about what others might do with the language later. Regarding language features the rule "when in doubt, leave it out" applies. See Go (although not my favorite language).
This seems to be an antiquated view on Scala and the people working on it and it's tooling. Referring to :\ as foldLeft suggests the parent hasn't seen Scala code since 2018 and scalaz which is nowhere to be found nowadays. I've been working professionally with Scala since 2019 and have never come across the symbol soup that was scalaz.
Programming language choice is a matter of taste to a large degree so it's possible the different people value different traits of languages.
"When in doubt leave it out", is a design decision that can be taken to extremes in some cases and many of us feel crippled and don't enjoy such languages. There can be languages that provide powerful abstractions and rely on its users' trust to use them appropriately. Of coyrde, like every tool it can be misused but that should not be the baseline we use for comparison. Because surely we can find dreadful code in every language.
As a closing paragraph I'll just say that Scala 3 is very nicely designed language that simplifies a lot of the sticky point with Scala 2 and allows for a nice blend of OOP and functional programming. Functional programming in Scala is opt-in and progressive and is a good choice for greenfield projects on the JVM. Also a final note, tooling for Scala and Scala 3 specifically has improved a lot to the point where it just works without arcane invitations of the past. Overly confident opinions to the contrary for people who haven't touched the language since 2018, scala 2.11 and sbt 0.13 are quite out of touch.
I worked in Scala for a little bit and while it is mostly a fine language there are a couple huge problems; the big two off the top of my head are the return statement (legitimately the most wtf moment I've had learning a language???) and implicits (this one is more of a me problem but I really dislike implicits, both the variable passing in and the implicit constructors).
So, basically Product Hunt has become a paid ads platform - only that you wouldn't pay Product Hunt but external service providers. I wonder why PH doesn't take the money directly and switch the business model to some kind of advertising auction. Might be more fair and transparent.
I had always the same feeling. KDE looks okay at first, but on a second look it would be somewhat ugly in a subtle way. That never changed for me in KDE, so I stopped looking at KDE some years ago. But maybe it is the time for another look!
The simple solution is to write everything (for the browser) in TypeScript instead and treat JavaScript only as the compilation target noone actually talks about. And compiling to JavaScript might also become a thing of the past with Webassembly. So, I think we shouldn't care about JavaScript as a name.
Not everyone doing things on the web is a pro developer using typescript. There are millions of use cases for plain-old javascript in the browser to get work done, probably many more cases of that than there are pro developers using typescript.
reply