Thanks God, we have Javascript, and maybe Rust.

What is being proposed as the alternative here?

For some things Democracy is excellent (governance of nations, because it might be the least bad option). For other things a dictator is good (Amazon seems to be providing a lot of societal value under Chairman Bezos) . For yet other things perhaps a motivated group of technocrats might be better (Go).

I don't suggest I know the answer definitively. I could be wrong. But Go's results are good. Perhaps it would be fair for me to concede that I should examine this question again in 10 more years. What is good for 5-10 years might show problems in 20-50 years time.

After all, even communist North Korea was a relatively functional place for a time.

Some hard decision was made for the better of the language and its users at the end. Thank you for the courage taking the hard decision.

If want to argue, argue that other package manager do better job than modules instead of community did effort and it goes for nothing but experimental.

Essentially Google gets "free" developer time as people work on problems and pitch in possible solutions. Google can influence what is worked on by whining about things, and they are free to take or discard the offerings.

This isn't particularly surprising to me as it feels very similar to the way I felt when working there. Which is that people in engineering worked on projects that they were passionate about, but whether or not those projects got support, or were shipped, or released into products. That stuff was all done "elsewhere" by some group of people who were generally known, but not really part of the day to day. I tended to think cynically of them as 'class A' shareholders, or 'class B' shareholders[1].

I don't think there is anything wrong with managing a program this way, I do however think they go out of their way to create a community illusion to foster more participation. That tells me that if they were up front about things, they feel people might not be as eager to participate. To the extent that they are deceptive in their communications, that I would consider wrong.

[1] Class B shareholders get to vote on shareholder issues, but there is always more voting power in the class A shares so that the class A folks can veto or reject any notion they dislike, no matter how popular with the class B folks.

I developed PHP till 2007, then as a hobby project in 2013. Massive improvement. And I heard very good things about performance the last years. Swoole even can compete with the top tear languages

Until then, it's a bsd inspired license. And you get code from Cox, Griesmer, Taylor, Pike, Hudson and Clements under those terms. It's a big team on several aspects.

So you can remove your tinfoil hat and check the code for yourself. It is valuable.

Suggesting that we should split the community for a feature that you like in other languages is a dumb and lazy argument.

I love open-source and libre software but there needs to be some central authority who oversees the changes and is forward-thinking. I actually love Go in the way it is and it wouldn't be it if you kept asking community what features to integrate. I am looking forward to generics as it solves some cases (containers holding items of a templated type sharing some common methods). But even if Go stayed the way it is, I would be fine. The point of open and libre in this project for me is that Google can't shut it down and that's enough for me in the case of prog language.

Please, if you want to make super-crazy-new community-driven uber-language which will change the world, make yet another and truly yours language or join Rust or whatever more community-driven language you like. Thank you! :)

In an alternative timeline where Go was not sponsored by Google, deciding what to merge into it and what to leave out would fall into some sort of "Core Team". In that timeline, if that Core Team decided to not include the features that the article author is describing, then we would have an article titled: "Go is The Core Team's language, not the community's".

I can only offer one answer. Maintaining an open source project is a lot of work. If you care enough about those changes, make a fork, include those changes, and maintain it yourself. If that's too much work, then you are stuck with what others able to dedicate the effort decide.

But that’s all just my personal opinions. What I found interesting was the callout of OpenJDK as a community-run language, but is it? I feel like OpenJDK is the worst of both worlds. Too much corporate overhang, and all the worst aspects of design by committee. But YMMV.

I value individuals and companies sharing their developments with a community. One has to remember though, to own something is different from benefitting from other's work, and if you want to have a say, you'll need to get your hands dirty, fork, and work.

Strong central leadership is great, but leadership needs to actually listen to the people they're leading (and not just as an after thought).

Also a huge fan of go mod over vgo so I had no issues of them scrapping the community dependency manager and rewriting it to be part of the language

This is laughable. Anything built within Google belongs to Google. There's no way the company will let anyone from the core team leave and take the language with them. Keep in mind, Google's version of Go and the community might be vastly different, as the former has different needs versus the latter.

There is someone who need to govern the project. This is a company in these cases.

The only other option I see is some board like (in case of .NET) the .NET foundation to allow more control.

They extended plan9s c compiler with some syntax Sugar for co routines and fixed some whacky c stuff then threw in some gc.

There's new and innovated about golang.

They just had to open source golang because they used the plan 9 c compiler which was open source.

So ... much like Linux where Linus is the gatekeeper, and he decides what goes in and what doesn't, and also abuses people while at it?

[1] https://medium.com/@valyala/open-sourcing-victoriametrics-f3...

Python looks most promising and I already worked with it, but I am not sure yet. Can anyone recommend a viable alternative for Go? Any web-focused language that is performant, modern andalready well used?

Maybe this is just an inherent problem for all company focused languages/frameworks (react, golang, kotlin, etc), and we need a good example of how to make it work for everyone

For example, FB doesn’t use DraftJS on mobile, so it took a whole year long effort and a person who used to work for FB to fix mobile support. They just didn’t need it, didn’t have resources allocated to dealing wit it, and were understandably unresponsive on the subject. Now maybe they can use it in the future on mobile if they want, but they would have just fixed it if that need had ever arisen for them organically.

[0] https://blog.golang.org/

Most of the time, in my experience at least, someone that wants cheap hosting and is using something like .NET or Python will Google "cheap python hosting" and see what is cheapest/recommended.

PHP tends to be the outlier, because it's absolutely everywhere, but I think the web has matured to a point where people will look for specific hosting for their choice of tech. Hell, back in my freelancing days when I used to rebuild broken WP builds, most people that weren't given hosting by their client chose it from looking up "cheap wordpress hosts".

Then you rather do some new language.

If there are no major non-Google contributors to Go, then the fork may not be successful due to lack of familiarity with the code base.

I belive this means that using this mechanism similarly to try/except in Python is not possible (I write 20 lines in go so this is quite a wild guess)

> PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly. But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes (to put it one way, I have no interest in knowing that I'm always going to be a second class citizen). I'll file bug reports, but that's it. The whole situation leaves me with ambiguous feelings, so I usually ignore it completely.

Sometimes, of course, this does not work out for the best.

What will, on a long enough timeline, come up in board meetings, especially as Google fails to meet Wall Street analyst's expectations, and as the ad-tech space evolves, is how much of Google-the-corporation's money to continue plowing into broader community things, like Golang at all.

Hopefully, by the time that happens, the community will be strong enough to persist, and I use Golang professionally, so I have personal investment for that to be true, but the possible eventuality that it'll end up being in the situation Java is currently in, makes me nervous.

Perhaps there are other ways, but in C you have parametric polymorphism functionality through macros. That's why min() and max() are not functions but macros and they work with any type that can be compared, not just float64.

That's such a cop out answer when our industry is basically doing fad-oriented engineering. It's great when you can greenfield build a project but when you're taking over a project the selection of language has usually been decided. Or you know the management team has decided for hirability reasons to use X. Or just legacy requirements don't match reality eventually.

This is why we need more expressive languages than Go. Requirements change over the course of a projects life and what made sense in year 1 rarely makes sense several years later.

Even not growing, they are indeed paying Oracle.

So when tasked to write his distributed network application in C at Bell Labs, his first step was to build something that would bring his Simula back, instead of bare bones C.

I’m not saying it was all terrible nor that Go is managed better. But whenever there is a conversation about Go on HN people get so caught up in their own snobbery about how terrible they perceive Go to be that they lose all touch with reality.

The fact remains a language backed by a company is far less likely to die into insignificance than a language that isn’t. This is because it takes a lot for a language to gain momentum. You have a bit of a chicken and egg problem where developers won’t use a language without a good ecosystem, frameworks and community. But people aren’t going to write that if there aren’t already developers using it. This is where corporate sponsorship really helps.

Thankfully there are a plethora of good languages out there you can choose from. If you don’t like the direction of one language then you can use another. Or, alternatively, since Java, C# and Go all have open source compilers, you could fork and build your own community.

I personally don't see Go and Elixir's primary domains as being equal, or one a superset of the other. So there's some argument to be made about the region where they overlap, but for something inherently based around fault-tolerance and distribution, seems to me that code written to run on the BEAM will be smaller and clearer and therefore more maintainable.

TensorFlow also has a Swift API in development [3]. The people at FastAI seem quite excited about it [4].

[1] https://developer.ibm.com/swift/

[2] https://github.com/IBM-Swift/Kitura

[3] https://www.tensorflow.org/swift/api_docs

[4] https://www.fast.ai/2019/03/06/fastai-swift/

Swift is actually a very pleasant language, and apple provides some pretty good documentation although it could be better.

It's going to play out like this: Swift or Objective-C (for legacy codebases/people who already experts in objective-c and don't want to switch), and some other, slower languages that will always be second class.

Edit: And to answer the question, no, there’s no philosophical differences. And there’s nothing wrong with that. Python never called itself a community’s language (there are instances core devs said in no ambiguous terms that it is Guido’s project). The problem only arises if a project gives an impression that it is owned by the community when it actually isn’t.

It's that or some magic with larger-than-needed arrays that automatically grow by a bunch extra every time they hit their boundary to make appends faster, while blowing up memory use and making append performance unpredictable.

Lots of (especially) scripting language hide this behind automagic and you see tons of append-in-a-loop where it's not really necessary, as a result.

[EDIT] had insert two places I intended append. Me need coffee.

    names = append(names, "Bob")

The Unity game engine use C# for scripting; I wouldn't call that "barely used".

Top 20?

- The IDE experience with PL/SQL, including graphical debugging of stored procedures

- Compiling PL/SQL to native code for better performance

- Running bare metal without an underlying OS

- Oracle RAC

- The fine tuning options on their JDBC and .NET drivers

- A proper C++ driver API

I don't think this is necessarily true. There are a lot of fuzzy factors that go in to making a language successful and it's tricky at best to get these right, even if openGo was a better language.

As a practical example, go effectively has one person who's full time job is keeping the testing infra happy. It'd take time and money to establish this in a go fork and going without it would make development of the fork much harder.

Java is also used by Facebook, Microsoft, Salesforce, Apple, and many other companies that aren't necessarily known for their Java development.

Java usually is the base for every core banking system that's not old enough to have been written in COBOL (and even those are being migrated to Java in many cases) or hasn't been written from scratch in .NET.

The same Java is also used by governments throughout the world.

If Oracle vanishes completely tomorrow, there's huge incentives for a community initiative to completely take it over ASAP. There's probably tens of billions of dollars in existing code bases that have to be maintained and extended.

More than that, Java's already 23 years old. It's not a new language. Plus: https://en.wikipedia.org/wiki/Lindy_effect

[1]: Edited, thank you maxiepoo.

So not just all the big corporates but plenty of tech companies like Facebook, Uber, Spotify, Twitter, Linkedin, Netflix, Apple, Google etc all rely heavily on it.

Here's an example I put together demonstrating this: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Move constructors are one of the worst parts of C++ and being able to write movable, intrusive data structures is absolutely not worth the cost. If you do need one, Rust shows that it's better to sacrifice movability than introduce move constructors.

This is not uncommon -- there are some things you can do in C++ that you simply cannot do in Rust (either safely, or at all). Usually there's another, better way to achieve the same overall goals.

Making computers do things is fun (usually)! The programming language is (almost) immaterial - depending on the task at hand of course.

Despite myself, I've even found myself enjoying JS in the few times I had no choice to avoid it. shudder

Isn't that also a classic example of "boiling the frog" or Stockholm Syndrome?

I'm sad to see this opinion every time somebody mentions PHP. PHP may have its flaws. But how can anyone deny the instrumental role PHP has played in building the web as we know it today?

The open web, open source, open standards, agile were supposed to be the free market answer to all the flaws of the big old corporations. And for a large part they have succeeded in creating the new and better world we enjoy today. But it looks like we're experiencing some regression. The new big corporations of the web are becoming more like the big corporations of the past. Corporate structures, HR departments, Shareholder meetings, Management layers, system thinking are again replacing the success of uncertain organic growth models that involve chaos, diversity, agility, attitude and pragmatism. To see media outlets advertising social media handles as opposed to their web addresses. Purists are on the rise. Perhaps because everyone is seeking those comfortable high paying jobs at the big corporations?

PHP has fought and won its battles. Outfoxing many big corporate opponents along the way. It should get the respect it deserves. And if you ever find yourself at the front-lines of a new battle. PHP might still very well be your most effective weapon of choice. A worthy consideration at least.

I know a guy who works with laravel, and we’ve teased him so much about PHP over the years, because PHP. The truth is, that his backend is actually more suited for the modern world than what we currently run. .Net core is getting to where it’s competitive, but it’s still a bitch to build something like a mixed asp mvc and Vue components app, which is truly effective/productive alternative to MVVM clients or jquery/Ajax for smaller projects.

So, by adding a feature which works extremely well with OO and enhances the language they have no soul? That doesn't make any sense. Javas soul is being a blue collar language. It leaves the experiments to other (JVM) languages and takes the parts which have been shown in the field to be useful for many cases.

Go on the other hand is a half-finished Java, produced for the sake of saying "We are Google, OF COURSE we have our own language".

But isn't that just an inevitable outcome of aging? The only way to never age is dying young.

And practical use of Java had stopped being textbook OOP (which means using classes to model the world and putting your logic where the data is) long before the streams API etc came along. Actually the shift away from textbook OOP integration between logic and data already started when the beans pattern drowned us in getters and setters, which already happened when Java generics were still the Pizza language sitting as a draft on Odersky's desk. I even suspect that lack of generics was a confounding factor in that shift, because when you look at a pre-generics codebase (which I happened to do just yesterday) you will find that the brave men and women back then spent an enormous amount of boilerplate just for hiding untyped collections behind typed facades which is a form of using OOP features (meant for modeling the world) for program structure, which is basically what post-textbook-OOP Java is all about.

I really respect the slowness of the go maintainers in adding new stuff. I also suggest that we all ponder our tooling some; Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you.

I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?

Streams are inspired by some idioms of functional programming. But they are not functional, and they cannot be made to be functional, because it is impossible to evaluate one without causing a rather glaring side effect.

I want expert code to be concise and uncluttered. When everything reads like a novice wrote it, that's a problem.

PHP has been developed very well the past few years as community project, there is an open RFC process with a codified voting process in place. Sure there have been some drama within the community, but that has not affected either the language nor the implementation.

What makes PHP a great fit for a community driven project is that PHP is a pragmatic language in its core. If the general goal of a project is to design a perfect & consistent language then a community driven process is maybe not the best approach.

Either a foundation is needed, which sets a vision and sticks to it, or a company, or a BDFL. But with none of them, you get each language faction pulling in its own direction, bits of each added/retained, and no coherence.

Well, the basic parts are not that great. Plus, it has almost nothing of Scheme (nothing more than e.g. Python has of Lisp), that's just an old wives tale. It just has closures and that's it. Scheme is a Lisp, whereas Javascript isn't [1]. Not sure what Brendan had in mind when he was inspired by Scheme, but the end product is nothing like it.

Coercion rules are crazily bad. No integer type is stupid. Prototypal inheritance nobody much cared for (where nobody = very few). An empty array is not falsy. And several other stupid decisions besides.

The only reason it wasn't that bad, is that it wasn't big enough to be bad. It was just a handful of features plus a tiny (and bad) standard library (some math, some string stuff, etc). Everything else people had to build on top (and usually the did it badly).

[1] https://journal.stuffwithstuff.com/2013/07/18/javascript-isn...

Those surely are not the proof that Java adds "everybody's favorite feature". I think the parent means the newest Oracle projects (Valhalla, modules, value types, streams, and so on).

The only thing we don’t allow is multiple copies of dependencies that link to native libraries, and the -sys pattern means that this is rarely an issue in practice.

That's not learning from established work.

Whether this is the right decision for this specific issue is a different story. But the fact that they aren't checking boxes for the sake of it is evidence of this style WAI.

...what in the world makes you thing that? I love parametric polymorphism, but nothing stops you from writing the most complex computer programs you can imagine without it.

Personally, I am very happy with what Go offers today, I would rather keep a small and simple language, which allows me to concentrate on doing work, rather than trying to keep up with features added to the language. I am not even sure, I want generics to be added to the language, until they come up with a really great concept which maintains the simplicity of the language.

It is not unthinkable that there could exist other programmatic tools that would be able to solve the same real world issues.

Now when Go 2 gets generics it will be used for all kinds of applications and frameworks, which is fine but isn't really filling a void. I expect the ergonomics (e.g. wicked fast compiles to single binary) to be better than current app dev langs. I stopped using Go and look foward to trying it again. Even then I don't think it will be one of my favorites and likely used for smaller work. Long-term I want Pony to succeed. Medium term I'll take Kotlin, Elixir, or Dart.

Rob Pike is not a member of the Go team anymore, and he has not been for several years.

I appreciate that by moving faster they get more stuff into more hands faster, but they definitely have a lot of hackish solutions with poor ergnomics outside of the narrow scope they were originally intended for.

If you will: the language features have a clear purpose but a general implementation; and outside of the narrow purpose the designs usually feel pretty poor.

E.g.:

- LINQ/expression trees don't support most of the C# language, and new language features are usually without equivalent expression tree. This isn't a full lisp or F# style quotation, but a pretty narrow window that's not easy to use outside of linq-to-sql style usages.

- LINQ trees are again intrinsically inefficient, since the expression trees compile not to a statically shared expression, but to a bunch of constructors (i.e. looping over even a medium sized expression is bound to be slow); and they're not equatable, so it takes a lot of effort for a consumer to detect this case leading to overly complex (and hard to reproduce correctly) hacks inside stuff like EF.

- LINQ is restricted, but the restrictions are fixed, not customizable. That makes it a poor fit for DSLs, including stuff like Entity Framework, because there are usually lots of expressions your DSL can't support, but there's no way of communicating that to the user. Also, if you use expressions as DSL, you need to follow C# semantics, which isn't trivial; witness gotchas in ORMs surround dealing with null and equality.

- lambdas are either delegates or expressions; not both, and this isn't resolved via the normal type system, but by special compiler rules, making it hard to do both, and leading to type inference issues such as that var f = (int a) => a + 1; cannot compile.

- Roslyn: very poorly documented, and ironically very dynamically typed to the point that many casts or type-switches are necessary but finding out what types there are and what they do is generally a matter of trial and error since the docs aren't great. Ergonomics are poor in other ways too; e.g. dotnet is xplat, but the build-api is not - i.e. it's clearly not dogfooded. Also: totally not integrated with expression trees, which is at least mildly surprising.

- string interpolations are unfortunately quite restrictive (compare with e.g. javascript, where this was implememented much better), and intrinsically and unnecessarily inefficient (at least 2 extra heap allocations, and usually lots of boxing, and the parsing the compiler necessarily must do is not exposed in any kind of object tree, but instead reserialized to string.Format compatible syntax necessitating re-parsing at run-time). Also, like expression trees, this was really hacked into the language, so, e.g. you can't participate in other normal C# features like overload resolution the way you might expect, extension methods plain don't work, culture-sensitivity can be a gotcha: basically this works for immediately evaluated expression, but is tricky elsewhere.

- razor (not strictly C#) is hugely complex, and has a very impractical underlying model. Compared with e.g. JSX which is trivial is (ab)use creatively, and which uses mostly language-native constructs for control flow, razor makes it impossible to use even basic features like methods to extract bits of common code; lots of basic programming features are reimplemented differently. Instead of passing a lambda or whatever, you have to deal with vaguely equivalent yet needlessly different stuff like partials + tag helpers.

- optional parameters are kind of a mess (no way to enforce named args, no way to cleanly wrap optionals, restriction on compile-time constant, interaction with overloads can be suprising); tuples are too (names are dealt with differently than everything else in the language, no syntax for empty or 1-elem tuples, no way to interpret arg lists as tuples or vice-versa, no checks on nasty naming errors like swapping order); equality is a mess (how many kinds are there again?), lots of apis are disposable but should not be disposed but for others it's critical, no good way to compose disposables, huge ever expanding api without practical deprecation path is a pitfall for newbs, no partial type inference for generics, no unification of all the various func-and-action variations means billions of pointless overloads (and sometimes per-API ways around it); tuples and anonymous objects are sort of redundant, but not entirely; no good way of implementing equality/hashcode/comparability and yet easy way to detect misused non-equatable types.

I mean, I respect their choices here, and there's a tradeoff with lots of benefit too: they're really quite fast-moving, and I want those new features ;-). But it's not without costs; they definitely aren't "much more methodical" or anything like that.

Java is not trying to "keep up." It is intentionally slow-moving and conservative (this design goal was set by James Gosling when Java was first created), and only adds features once they have been proven in other languages for a while.

    class A {};
    class A<T> : A {};

It is kinda similar to not understanding how something like a jury rigged Vim with a GDB, file list manager and ctags parser differs from a real IDE even after having used the latter. Usually i'd say "you need to experience the real thing" but if you do not get it after you do, then i'm at a loss of words.

For their first implementation of BIDS, initially provided with Borland C++ 2.0 for MS-DOS.

Finding out the release date is left as exercise for the reader.

"In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

https://go.googlesource.com/proposal/+/master/design/go2draf...

Go's goroutines seem okay - but I don't like how much control they take away from the programmer. For example, last year I worked on calling-into a black-box C DLL from a Go program and we learned the C DLL had code that was actually simply terminating the thread inside of it (by design!) because the author of the C DLL assumed ownership of the thread. That caused a problem for us because Go's goroutines are scheduled by the Go runtime and it will never let you give-up ownership of a Go thread - and I couldn't see how I could use my own thread (e.g. getting a thread from a native OS call to keep it outside of Go's control) with goroutines. The project was almost DOA after we learned this, fortunately we convinced the author to always return instead of killing the thread. I'm not sure if anything's changed in Go since then that would have made things easier for us. But since then we haven't used Go for anything new. The only reason we used Go was because it gave us binaries that "just worked" for Windows, macOS and Linux without having to worry about Java, .NET and other dependencies - but I wasn't happy about the ~20-30MB-sized executable output.

Go does have generic collections, and generic functions operating on these collections.

> You cannot e.g. write a generic Go function to reverse an array.

You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements.

> which you can't in Go

Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.

Pike himself is a user.

That seems like a roundabout way of saying that it doesn't have the feature.

>It's overloading

You could just as well regard Go's close, append, copy etc. as overloaded.

> The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.

They've come out with a specific generics proposal. I'm not sure why you would think that they're not serious about implementing it.

There's a reason java had built-in value types from day 1, because it made sense even back then.

Frankly, I think both java and C# kind of got this wrong. There was an overreaction against the C/C++ of the day, and whereas the GC turned out brilliant, the idea that it's not even necessary to express the notion of references/pointers/values etc. was too much; and the idea of a single type system root (object) is similarly dubious, and then particularly the idea that that root type isn't the empty type. Object has semantics, and that was a mistake, because it contributes to the bloat. I'm totally happy with ignoring those features 99.9% of the time, but having them completely unavailable makes those 0.1% cases extremely expensive. (I mean, I think those things are slightly changing, but it's slow going).

Value types were pretty much obvious as necessary.

More so when one dives deep into how languages like CLU and Mesa/Cedar were designed.

Having a AOT support doesn't preclude having a JIT as well, like Common Lisp or Eiffel already had in 1995.

Are there any plans to fix those?

I don't know why there was no emphasis on AOT back then. I guess they started with interpreter/JIT, and then there just wasn't much demand for AOT until now.

If I recall correctly it even depended on WINE.

I can check the respective manuals if you wish.

Yep, I did VB programming for a short while.

And please note that even though my focus is now elsewhere, Java is one of my favourite eco-systems.

As a peasant I just wished that Java 1.0 was more like Go, given the existing alternatives back then.

So it kind of stayed as a pet peeve of mine.

Same applies to .NET, just in a different way.

That's perfectly fine. We think that our priorities are right for the workloads Java is used for (e.g. people care more about a low-latency GC like ZGC, and deep low-overhead in-production profiling, like JFR, than about AOT).