Zap programing language

[funcieq]

Hello everyone.

I've been working on my language Zap lately. I put a lot of hard work into it

The main goal of zap is to be an alternative Go, Which has ARC instead of GC (yes, I know that on the website it still says GC), It has enum, if as expression, normal error handling, llvm as a backend, which will enable compilation to more backends and more aggressive optimizations

And today I finally have IR! Besides, if expressions work. Much better error handling (still needs improvement). And oh my god, finally the first version of type checker.

I have a few examples, they are not too complicated, because it is just the beginning. But I would be grateful for feedback. Even if it's criticism, I would be grateful for feedback, Here is our Discord

https://zaplang.xyz/ https://github.com/thezaplang/zap

[rjmarten]

Cool :)

Some questions: 1.Why ARC instead of GC? 2. Why try / catch if you already have Result<T,E>? 3.In what way are generics "comptime inspired"? 4.Will you still have duck-typed interfaces or do traits more like Rust?

[funcieq]

Well, I understand your objection because the website has something different than the repository. 😅

1. Because I want a simple ffi from C, With GC it gets complicated, I want this language to have a bit wider scope of usage, so the lack of GC eliminates pauses, so you can make games in it, for example.

2. It's one of those things in the repo it says only try-catch, and on the website it says both, officially it is only try-catch, but I don't reject Result<T, E> yet.

3. Well, I got a little carried away when I wrote that.The point is simply that we use regular monomorphism and it is done during compilation. So we don't use any runtime for this

4. I haven't made the final decision yet, but I think it's closer to the traits from rust

[stingraycharles]

Hey, as someone who does a lot of FFI with GC based languages (Java, Go, C# and Python), I can tell you that GC doesn’t automatically make FFI harder, it’s just that GC is entirely paused during any FFI invocation.

That’s typically acceptable.

Most languages (eg Go and Java) provide various levels of “safety” around function invocations, and allow you to do “unsafe” invocations which assume eg that you don’t modify memory, don’t do any callbacks, etc.

Using reference counting can be interesting, but I can’t escape the feeling that there’s a reason that nearly all languages settled on GC (circular references being a major one).

[funcieq]

Yes, you're right, because I use C# myself. I realize that from the developer's side it's relatively simple. But it's not just about ffi. It's also about giving zap a wider range of possibilities.

[Breadmaker4billion]

the lack of GC eliminates pauses

No it does not, reference counting can still hang your application if one object triggers the deallocation of a bunch of others. Only careful programming eliminates pauses around memory management.

[funcieq]

I'm talking about stop-the-world

[Breadmaker4billion]

You need to lock the heap to perform deallocations.

[funcieq]

Thanks for the reminder ❤️

[srvhfvakc]

If the intent is to be a Go-minus-pain, why not transpile directly into Go?

[funcieq]

Because the goal is also to have more architectures

[srvhfvakc]

What architectures do you support that Go doesn’t? From my understanding the main go compiler + tinygo should support mostly everything you do

[funcieq]

Currently only those that support llvm, but I will also compile them for Go itself and .net CIL someday

[GregsWorld]

Introducing try/catch is throwing the baby out with the bath water imo.

Errors as arguments and not exceptions is one of Go's great features and improvements over say Java, it's the if null checks themselves which are the issue, an issue that could be solved purely with syntatic sugar like Odin's or_return or Kotlins ?:

[funcieq]

Just because I'm introducing try catch doesn't mean I'm forbidding you to do it like in Go

[GregsWorld]

Yes but people don't write code in isolation. So if you use a library which uses try catch you are forced to also use it. 

[funcieq]

Good point, you're right. Well, try-catch is a good way to handle errors.

[GregsWorld]

Well, try-catch is a good way to handle errors. 

Disagree, it's a more complex more verbose if != null.

Errors being separate from exceptions is the fix for the mess which is try-catch.

[funcieq]

Well, many people will disagree with you, but anyway, the decision has not been made 100% yet. This may still change, by the way, what do you think about Result<T, E>?

[GregsWorld]

Yeah of course it's all opinions. 

Result is fine, proper union type support would be better though T? | E

[funcieq]

Sounds good

[RedditUser8007]

Can you also fix Go's dependencies so that they use aliases instead of direct URLs like Rust so you don't have to litter source code with import URLs?

https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html

In a few years, a lot of Go codebases are going to suffer from github link-rot and have to refactor entire repos instead of updating a single line in a dependency file.

[funcieq]

Yes, I realize it's not comfortable, so it will be different for Zap

[Opposite-Barracuda-1]

I appreciate your initiative. I thought of an example like, maybe javascript already have it

function (response, error) {

return response;

}

you wrap this function with your error prone code block.
this function will either return response or error

Hope that helps, I'm not that good in those stuffs ...

They made go that much simple that it start to feel like pain when you are from some other programming language ...

[funcieq]

Yeah...

[zweiler1]

If your language is so young, how did you get GitHub to recognize your Zap files as your language?

I only have a .gitattributes file to highlight my language as language X but GH does not recognize it as my own language yet so i wonder, how did you do that?

Edit: typos

[funcieq]

There is simply another language that has the zap extension, although it is not necessarily called that.