Hello World in Al and why?

I wrote up a pastebin post that specifies a bit of my little pet language idea.  Just to get into the nitty gritty compared to the status quo languages and new contenders:

• C: C is way too old, and has a ton of problems.  Glyphic syntaxes like pointers, textual inclusion, no baked in template or polymorphism to facilitate dynamic code, no objects, no access modification to help team based development.  Function objects are convoluted and error prone due to their existence as effectively a void*.
• C++: While an improvement on C, a lot of what C++ does also falls flat.  It tacks on object orientation rather than being systemic with it, so interacting with C data types like ints is convoluted.  Structs are preserved as just default-public versions of classes that are default-private.  The smart pointers I feel properly implement memory management, but it is a little too little too late.  There is a lot of duplication of purpose in the standard because it is very committee driven.  As a result, this language is like a bathtub for a kitchen sink with a tendency to spring leaks.
• Haskell: The adherence to the functional ideal is admirable, but I fundamentally disagree with the treatment of the process of constructing tasks for the execution of physical transistors as if it were only math.  Statefulness is an inherent property in computers, and while it introduces overhead, it is necessary for any programming model, and Haskell is no exception in the line of functional languages that try to hide state in a leaky way.  Also, being single paradigm, it isn't all encompassing enough.
• Go: The syntax is pretty cumbersome, it lacks static typing, its memory model isn't fine grained enough for what a real systems language needs to guarantee behaviors.  It throws all its proverbial utility into parallel programming, but by doing so they make the entire language a pain in the butt to use and full of non-determinism.  So it is a good niche language for massively parallel projects, but otherwise insufficient for a generic compiled language.
• OCaml: lacks static typing, and has a really glyphic syntax.  I really do think this is a big deal, static typing makes determinism so much easier.  If you are object oriented having everything discretized into nice object boxes is a miracle for debugging and maintainability.  I do like how you can use OCaml as a script or as a native binary.
• Rust: again, inferred variables.  Not allowing null pointers is an interesting proposition I would definitely want to look into.  The concurrency model of message passing I feel is the appropriate solution, and it has an emphasis on async functionality for small execution units.  I'd rather build a threadpool and queue tasks into that in a program, but to each their own.

So just to summarize my goals with this thought experiment:

• The code should be deterministic.  No construct should be more than a sentence to explain how it runs when assembled, and as such the compiler should never be overtly complex.
• Garbage collection is appropriate in some use cases.  The best way to do it is let users opt into using a garbage collector, like most standard library functionality that would break the previous policy.
• A threading model based off the usage of functions as first class objects and the availability of a concise and easy to use socket interface to send efficient messages across processes.  Inter-process communication can also be done over that socket layer, done over some internalized message passing, or memory can be shared through references.  A thread would not have visibility on another threads stack, but would see global variables and could be given references to stack or heap objects explicitly.
• Smart pointers!  They solve the memory problem nicely.
• Don't fear references / pointers.  Rather than having the glyphic * and & syntaxes of the C's, we can use a ref<> template object to refer to a pointer to something.  I like the non-nullable ideal, so maybe this object needs to be constructed with a reference, and attempting to set it to null throws an exception.
• Exceptions are good!  Goto as well, none of the execution mode switchers are inherently flawed. Code is naturally jumping all over the place, just minimize the hard to trace parts.
• The glyphs should be minimized.  You want an easily read language with an optional whitespace significant dialect.
• Module based inclusion - importing a module could mean importing a text file, something already compiled, an entire archive of files or binaries, or even a function in a file or binary. This means you have a unified access view into other namespaces.
• Access modifiers!  They make peer programming so much easier.
• Designed with the intent to be both callable and interfacable with the other Altimit languages.  You can't kitchen sink all problems.  This language is meant to be able to give you the tools to maximize performance without needing to have overly complex syntax or requiring more work on your part than necessary.  But by default, it needs to be deterministic and safe.  The bytecode language would be easily sandboxed for application development, and the script language would be easily used as glue, easily live interpreted, and high on programmer productivity.  Using them together could give you a powerful toolkit that nobody else seems to try to build cleanly.

I wonder if I'm ever going to go anywhere with all this crazy talk.  We shall see.   I might write more pastebin samples.