pouyathe - 5d
Hi HN,
I've been working on a programming language called G. It is designed to be memory-safe and extremely fast, with a focus on a tiny footprint.
The entire interpreter is written in D and weighs in at only 2.4MB. I built it because I wanted a modern scripting language that feels lightweight but has the safety of a high-level language.
Key Features:
Small: The binary is ~2.4MB.
Fast: Optimized for x86_64.
Safe: Memory-safe execution.
Std Lib: Includes std.echo, std.newline, etc.
GitHub: https://github.com/pouyathe/glangI would love to get some feedback on the syntax or the architecture from the community!
I would just say, on a positive note, it looks exactly like something a 17 year old would create--a brilliant 17 year old who is going places in life, that is.
I would strongly reiterate that the GIGANTIC RAT'S NEST of brackets needs to be cleaned up as that will never, ever fly.
The root of the problem seems to be either a) you're doing some kind of auto-generation of code in a crazy way, or b) a dogged insistence on not putting 'else if' on the same line due to some kind of stylistic concern...the sort of mistake a very bright but slightly autistic young man might make.
Refactor the code to fix this please and you will have to admit it ends up looking WAY nicer, and most importantly, will be a thousand times easier to maintain.
Keep it up, you will go far. The next version will be better. They always are.
Congrats on getting on HN!
Thank you for the kind words and the specific, actionable feedback.
You've pinpointed the exact issue - it's option (b). I developed a personal style coding in isolation and didn't learn conventional formatting. The "else if on separate lines" pattern became a habit that snowballed into that brace nesting.
I'm fixing it now. You're absolutely right that it will be much more maintainable.
The "brilliant 17 year old" comment means a lot. I'm learning that part of brilliance is knowing when to follow established patterns. Thank you for the mentorship through critique.
The cleanup starts today.
Good man. Like I said, it's obvious you're going places.
D is a good language. You chose well. Walter Bright would be happy to see what you're doing here.
If you're not using version control yet, now's a good time to start, as it will help with the cleanup work. Fossil is my favorite as it's easier to use than git, but whatever you like is fine. More people use git than fossil so it's good to learn it and master it. It's very easy to introduce some kind of subtle bug in situations like this, but with version control you can check carefully after each change to make sure the code still works properly, and if not, easily see the problem and fix it or revert and try again.
clang-format would be the perfect tool for this also, even though it's not designed to work on D. The language is close enough to C++ in syntax that it should do the job, at least helping you get rid of the brackets in one go without screwing anything up too much. I recommend basing your styling on the "Microsoft" preset and customizing from there. That's also known as the "Allman" style, with the brackets starting on their own lines. With the brackets lined up like this it helps to see where code blocks begin and end. But you can use whatever style you like of course, just experiment and see what looks good to you.
Ultimately it comes down to just Doing the Right Thing. Sometimes that's the same as following established patterns, and sometimes it means breaking them. As you gain more experience you'll figure it out.
I think HN lets you post the same link once a month, so spend a while cleaning it up good and making it look as pretty as you can, then post it up again next month, on a Friday or Saturday to get more eyes on it. Send me the link when you do and I'll have another look. Here's my email:
domain: killthe.net
name: dave
Here's a good clang-format config file to get you started:
http://killthe.net/clang-format
Use it like this, from your source directory.
find -name '*.d' | xargs clang-format --style=file:clang-format -i
Just make sure to have a backup copy first, or version control, before running that command as it might screw things up. "Update: Wow, this got a second life! Seeing a spike in GitHub clones (328+ in 2 days). If anyone's trying G, I'd love to hear:
What's your use case?
What's the biggest hurdle you faced?
What feature would make G actually useful for you?
Thanks for checking it out! — A 17yo student building this."No offense, but the source code for this is wild. It's almost like outsider art. https://github.com/pouyathe/glang/blob/main/source/dub/sourc...
Still, I have to respect the dedication it must have taken to get this working. I'm sure you'll go far.
My advice to you would be to read Crafting Interpreters by Bob Nystrom (it's free online) and try to apply some of the techniques from it to your project.
https://craftinginterpreters.com/
It hurts my eyes to see spelling mistakes in error messages. I know English is not your first language, but, dude, in the age of autocorrect and AI, it is sloppy and screams incompetence. Not what you want anybody to see when using your interpreter.
Otherwise, what a cluster*uck of a code this is.. I am amazed and appalled at the same time.
"Outsider art" - that's one of the best descriptions I've heard! You're absolutely right.
Thank you for the book recommendation. I've just downloaded "Crafting Interpreters" and will study it properly. I've been coding in isolation (due to circumstances I can't easily explain), so learning from established resources like this is exactly what I need.
The messiness comes from years of solo experimentation without mentorship. I'm now committed to cleaning it up using proper techniques.
I appreciate both the kind words and the tough love.
Oh, we’re talking to an llm. Gross.
Everything was going reasonably OK until I got down to that gigantic rat's nest of if-else statements and embedded for loops. OMG
Yowza! Lines 1566-1637 consist entirely of closing braces. That's 70 closing braces in a row. Beyond the nightmare of maintenance, it's got to be a performance drag on the compilation.
Almost lisp-like, isn't it?)))))))
Man this is art
I think this is a really cool project! The syntax here is interesting. I was wondering if you could shed some light on it, I wasn't able to find what `[@] : ` or `[%] : ` meant.
Also, can I ask why the source code for the interpreter looks like that? This is an honest question. I thought it might have been machine generated (via a sort of self-hosting G transpiler) but the comments at the top dissuade me from this view.
Hello,
I'm currently working on the documentation and I'm close to finishing it. I've been putting real effort into this and hope to have it completed soon.
Best, Pouya (A 17-year-old Afghan teenager from Iran)
I know the source code is messy and not clean. I promise I'll clean it up. I'm sorry about it, but when I was coding, my country had serious problems and coding was my escape.
Honestly, my code is like my school notes. Even my teachers can't read my notes during exams! They always say: "The answers are right, but the handwriting... ah!"
I'll make it better.
Fellow D fan - high five! This is seriously impressive for a 17 year old!
I'll note a few things:
1. 'fast' without benchmarks is just marketing speak. I keep seing "fast", "super fast" on the GitHub page but nothing to substantiate the claims. How fast is it compared to using D, or even C?
2. 'Download glang' link is broken
3. Why would I use G and not D directly? D generates small binaries as well.
4. What does the 'std' library include? You're mentioning 'println' and 'newline', while people expect data structures and components they can reuse. Is the D standard library accessible?
5. I couldn't find a documentation page easily, but I see you plan on overhauling the documentation
6. Including a package manager is awesome.
7. Do you have any interop with C, D or Java?
A few observations related to naming:
8. G Language is already used by a few pieces of software, though nothing too widely known (https://en.wikipedia.org/wiki/G_programming_language).
9. If I thought my language is worthy of a single letter name, I'd swing for the fences and name the compiler executable 'g', not 'glang'. You're already using the .g file extension for G Lang source code, so might as well go big with the command too.
10. Speaking of glang, it's super close to golang by Google
11. Your Fuchsia shell's name conflicts with the Fuchsia OS (fuchsia.dev) by Google
I'm not a big fan of the syntax, but I wish you good luck. I hope to keep hearing about your language in the future.
Do you have anything real to show? Do you have already a working memory safety mechanism?
Check out Janet!