He added GraphQL support a few weeks ago:
https://github.com/manifold-systems/manifold-sample-graphql-...
You can just drop graphql files in your resources directory and start coding against them as type-safe interfaces immediately, no code-gen required.
The @Jailbreak annotation is awesome too.
Probably the most interesting aspect of Manifold is its role as a type name resolver for the compiler. Manifold provides an API to dynamically resolve types corresponding with, well anything, but mostly with resources like JSON files, GraphQL schemas, SQL, DDL, CSV, scripting languages, you name it. So from the compiler's perspective it has no idea what is going on beyond normal type name resolution, but the source files it's loading up are coming from deep, dark places ;)
But yeah, no code generation step in your build, no agents, no custom class loaders, etc.
Re Intellij v. Eclipse. I'm just one guy banging on a project; I only have time to build and maintain one IDE plugin and right now my focus is on IntelliJ. I'd like to start working on an Eclipse plugin at some point... or trick someone else into doing the work ;)
The only contentious point I find is that they are basically replicating Project Lombok's @SneakyThrows annotation via "Xplugin:Manifold stringsexceptions" or ModelMapper in their Structural Typing.
Furthermore it seems it should be structured in sub-projects, eg. the String-templates and ManTL in one lib, Structural Typing in another so we can mix & match.
But overall, very impressive!
The 'exceptions' option is quite a bit different from SneakyThrows. The 'exceptions' option completely mutes checked exceptions in your project -- you don't have to declare a throws clause or catch a checked exception anywhere in your code, thus with the option enabled checked exceptions behave exactly as unchecked exceptions. This behavior is identical to exception treatment in other JVM languages such as Scala, Kotlin, Ceylon, etc.
Regarding sub-projects on extensions, I've been meaning to do that. The project is already divided into separate targets e.g., manifold-graphql, manifold-json, etc. But manifold-ext has probably grown too big for one target.
I have the highest respect for your work, and no idea how you are doing that more or less on your own. I am just a bit sad your upcoming SQL/DDL extensions are going to kill one of my side-projects :) https://github.com/iSnow/sqlWebservice - if you can use a SQL schema as a type provider, you are leaps and bounds ahead of what I am doing there.
So, hats off, great job.
Selling a new language is hard, selling a library is easier, even if this one has a hook deep in the code of javac.
[1] https://en.wikipedia.org/wiki/Gosu_(programming_language)
I like the Extensions option. It works very much like D's UFCS mechanism.
Checked exceptions is a stupid feature because it makes an implementation detail, the fact that a code raises an exception, part of the type of a method.
Scala, C# or Kotlin have no checked exception and it doesn't make them less safe.
http://manifold.systems/docs.html#checked-exception-suppress...
I prefer exceptions to be declared, just like types. Having exceptions declared gives me more information about the operation of the code I am calling and that is useful. To treat exception declarations just as annoyance seems like lazy punting.
Besides, any non-trivial method that calls any set of libraries/frameworks would need to declare tens or hundreds of checked exceptions in your scenario. And that's just the catchable exceptions. What are you going to do about any (subclass of) Error?
convert it to internal types at the point you're exposed to them, then handle them in common ways. or re-throw as a general runtime exception if you don't have a way to handle it in your application. the difference with checked exceptions is that you have a correct, complete list of error scenarios that a library expects you to handle, and they provide a relatively easy way to defer handling.
there's no need for your `public static void main` to inherit all 100+ exception classes that your application is exposed to - that's just plain bad encapsulation.
---
granted, none of this touches on some of java's implementation issues, which essentially suffers from a lack of generics. e.g. you can't build an executor-framework without `raises Exception` or wrapping all errors in an internal wrapper, which loses compile-time safety. typed-exceptions-as-returns (i.e. typed result enums) keeps them within the normal type system, which does have some benefits for sure, but that ship has sailed. few languages are able to force exhaustive error handling at all, java's in a middle-ground with pros and cons.
And if the method can suddenly fail in a new way, that signature should change so that callers of that method can adjust to the new failure case.
Checked exceptions force you to consider error cases, there's nothing stupid about them.