Please note that the JBR is a custom build that contains a number of important changes and fixes, and it's not recommended to replace this. For M1 support, it's much better to use an M1 compatible JVM and .NET runtime. Rider 2021.2 is an Intel build, because when it was released there was no M1 compatible .NET Runtime.

Rider 2021.3 has an M1 build, and makes a big difference. It's currently in preview (https://www.jetbrains.com/rider/nextversion/) but will be released in the next week or so.

Liberica offers an M1 JVM https://bell-sw.com/announcements/2021/03/12/Liberica-on-App...

I wonder if JetBrains has some incentive to keep Mac users happy at the expense of others, because there is no justification for the unacceptably bad performance of CLion, PyCharm, and IDEA with a version 11 JDK on Linux, given how much better it is on JDK 15/16.

I have never seen any indication that they have are going to address this, nor have they even acknowledged that it's a problem, nor that they intend to upgrade from JDK 11 to something more up-to-date. Still, they have 1 year and 10 months from now until the end of active support, so perhaps this might provoke them into action.

The fact that JBR even exists is a red flag. Should every vendor ship their own JVM?!

This YouTrack item

https://youtrack.jetbrains.com/issue/JBR-3729

tells that JetBrains have been working on a JDK17 version of JBR for 2022.1, which amazingly, is almost upon us. I am looking forward to seeing what it's like!

I was under the impression that the JBR is missing a number of important changes and fixes that have already been mainlined into OpenJdk.

Would love to see some examples of this please :-)

You can consider an extensible grammar as a "nested" grammar. You have certain extension points in the "parent" and you can attach a new grammar here.

For example, it would be easy to take a C# grammar and add a new operator, such as the null propagator "?.", since the list of operators is extensible. This wouldn't break anything, as it's just a new token for a binary expression.

Or, you could add something bigger, such as LINQ, by extending C# 2.0's Expression syntax rule with a LINQ query expression.

No, it's always been the plan to open source Nitra. It's come from the team who built Nemerle, which is open source, and the team obviously wanted to continue in this manner. And JetBrains has a pretty good track record with open source - e.g. the IDEA platform that is IntelliJ's Community Edition is fully open source.

We do have a lot of future plans for Nitra, but for now, it's worth pointing out that the products that are cross platform are Java based, while Nitra is based on .net. The project is currently Windows only.

Interesting, what made you decide on .NET (i.e. given you're predominantly JVM based)? Was it just based on the Nermerle's team preference?

I wouldn't say we're predominantly JVM based. We've also got ReSharper, dotTrace, dotMemory, dotCover and dotPeek, which are all .net based.

But basically, it's because Nitra is an extension and evolution of work done on Nemerle, and Nemerle is a .net language.

Is ReSharper written with C#? I thought I heard it was written with C++.

It's written in C#, with some of the Visual Basic support written in VB. Parts of ReSharper for C++ are written in C++ and C++/CLI.

Mono support isn't at the top of our priority list right now. However, the Nemerle binaries work on mono, so it's possible you could build the command line compiler and sample applications under Linux. If you get it working, a pull request would be very cool!

What do you mean? Security of what?