Taking a look at how to effectively further the project about onyx-lang HOT 5 OPEN

all available languages suck in one way or another

Damn straight. That's why I'm here.

Ruby and Lisp are AWESOME, but neither are suited for high-performance or static compilation. And C is a complete arse to use. Etc etc ad nauseum.

tl;dr

I dislike that term. Way I see it, if someone can't be arsed to read the damn thing, they should go home.

Be fully usable replacement for C++

Including static compilation with no dependencies.

I was overly optimistic that [Crystal] would be open to good suggestions

They do seem very resistant to new ideas. Which is one reason I no longer play in their yard.

C++ should be the "family" (it's not it, but its' syntax I've loathed)

Actually, with the advent of "C++1y" (closures, move semantics, etc), it's almost usable now. Get rid of those bastard header files, replace templates with generics, strongly type std::function, and allow monkeypatching of classes.... and C++ might yet crawl out of the dark ages and into the light of modern day!

I won't hold my breath though.

Statically linked self-contained musl based binaries

This!

You use the standard landscape of libs of the target (whether Lua, NodeJS-ES, web-ES or whatever) — just use a better language against them

There's a project called Haxe that targets multiple backends. I'd be satisfied with just C++, if it achieved my requirements of [a] zero-dependancy binaries, and [b] not being an utter bastard to use.

Anyhow....what I got out of your above post was essentially "drop the Crystal backend, and suddenly we start making progress at a sensible pace again". If so, I'm all for it. Hell, I'd be prepared to code a large part of the stdlib for you. Provided it wasn't in C.

I'm good at coding. I'm just not good at coding compilers. Give me a language that's nice to use - like Ruby - and I can code lots of stuff.

from onyx-lang.

You sum it up well.

Funny you bring up Haxe, that's an example of what to avoid somwhat, they've made a rather elaborate stdlib-on-top to abstract to multiple systems. But when I think of it; I'm not opposed to it really. I'm confusing objectives here. I'm just not keen on spending time on one — since I myself would target a backend and play with its' libs and features specifically then.

The only onyx-core-stdlib parts will be the basic "always used types" which I think are good to abstract in a minimal-stdlib (Str, Int, ´32, U64, Byte, Map, Set, List, etc. etc.) and stdout/debug funcs (say, _dbg, etc.)

With "lenient" mode code-policy (default unless specific code-policy specified) any core-libs will be helpfully automatically included when definition from them are used (no fixed prelude like in Crystal I reckon)

Regarding C: I have no intention of making a C backend. Only C++. I would be fully open to include one provided whoever PR's that would take responsibility of maintaining it.

The few things (as I've imagined) in stdlib would mostly be mappings from ox-types to backend-types (well, obviously to no types for Lua and EcmaScript) and say, _dbg fn's.

Onyx will promote using strong numeric types with semantic meaning rather than intrinsic "hardware types":

-- Good:
op *(u Volt, i Ampere) -> Watt  -- ignoring AC vs DC for example
   Watt{ u.value * i.value }

power = 48V * 45A

-- Bad:
power = 48 * 45

It won't be forbidden or anything of course. Using non-coercing types will just be Onyx-culture idiomatic recommendation.

I must be clear on the fact that I'm still up to my brain-arse in shit to do — so this chosen path won't magically make development go rocket just yet I'm afraid. But it will not hurt (bar the initial re-write time...)

from onyx-lang.

48V * 45A

Yes, +1 for unit typing. Although explicit casts must be available; and the creation of a unit type should be as terse as possible.

I don't know what a brain-arse is, but I'm fairly sure I don't have one ;)

from onyx-lang.

• Yeah, I have suffixes (suffices?) implemented in current Onyx with the syntax described in #77. The unwillingness in Crystal to include a using declarator was sad in that it makes it hard to include special suffixes for just a portion of DSL, Sci or whatever code. With c++ backend that become possible too. The syntax for the body code of the suffix definition will probably change a little.
• Yes! Explicit casts will of course be the way to juggle between types, which inevitably always ends up having to be done for one reason or another.
• Easily auto-creating common op's! Yes! Definitely! The idea currently is simply that the previously removed "type-def-interpreter"-code connected to specific super-types (similar to on inherited macros) should be brought back into Onyx again. By inheriting a specific type (in the example I wrote NumBuilder or so; that's just a suggestion taken out of the air):
  • My idea so far is — just like enum and flags types has a "builder/interpreter" that accepts a list of costant names that are expanded to an incremental enumeration or doublings — so the NumBuilder takes a list of really terse descriptions of operators and the types they take, and the overloadings are generated automatically. The superior thing about this is that you easily for instance disallow Area to be multiplied by Area, Volt by Ohm, pointers to be added (only Offset can be added), etc. etc. which gives an enormous additional help in not making to-tired-to-crack mistakes.
  • Something along the lines of:

type MyNum < NumBuilder
   *, +, -, <=> MyNum, OtherAcceptableNumT, YetOne
   /, **, % MyNum  -- apparantly only wanted this with self here
   / YetOne  -- but div also accepts type YetOne

   init() -> here goes regular typedef code
   foo() -> and so on

That is:

• multiple operators can be listed, along with multiple rhs-types
• should be simple to define overloads for the reverse type order also
• if the exact same op-signature is defined more than once by the patterns, it will be a warning, or if stricter code-policy is declared for the specific file / scope it will be an error.

I don't know what a brain-arse is, but I'm fairly sure I don't have one ;)

Consider yourself lucky! X-D

from onyx-lang.

Looking good. Always been a fan of unit types.

Is a brain-arse where brain-farts come out?

from onyx-lang.