4 ms·

Freelang – a Libc-free, direct sys/kernel call language with weird concurrency

10 points by keepamovin 5mo ago

manoloesparta 5mo ago
why javascript for implementing this? i mean you can use whatever language you want but i find it surprising lol
- deleted 5mo ago
  [deleted]
- pepa65 5mo ago
  That drastically reduces my level of interest (in spite of the write-up sounding very intriguing).
forlorn 5mo ago
op describe {name, role} ( print "user: " + name + " (" + role + ")"; ) Strange choice of brackets usage
- deleted 5mo ago
  [deleted]
- pepa65 5mo ago
  But then the call makes more sense: `describe {role: "admin", name: "alice"};`
  - keepamovin 5mo ago
    Precisely! Call sites should be traditional syntax shaped, pos args get [ and ] (trad array), and object shapes get trad obj syntax.
MobiusHorizons 5mo ago
Sounds very similar in its approach to magic or hiding as golang. Also the no libc approach is similar, although I believe go was forced to use libc on the BSDs and maybe osx due to the syscall interface not being a stable public interface on those targets
- deleted 5mo ago
  [deleted]
- keepamovin 5mo ago
  Yes i believe call codes in assembly do change between some major macOS versions, but that's okay. So far I think it's only using 20 syscalls, and works from iirc v15 up (macOS). For windows we're hitting the stable layer, and I'm not interested in BSD rn - cannot even run standard chrome on bsd, iirc.
spijdar 5mo ago
I know it's such a cheap thing to say, but this could really use a description/web page that wasn't written by an LLM. What came to mind while reading through it is that all of the information and details appear to be technically correct, but they don't really communicate much about the project to someone who knows nothing about it. It's weird. I feel like this could maybe be interesting, but also... huh? I feel like the idea is to produce a small, self-contained compiler with simple semantics that generates simple executables with a simple runtime model, and a basic supervisor model for scheduling tasks. Okay, that's cool. But "vibe coded mass of JavaScript running in node.js" doesn't really mesh well with that vision, at the least to me. Also, as whatever LLM that generated that table says, the code it generates isn't "seriously optimized". I don't buy the idea that compiler optimization is something you can bolt on to a project like this later, after you've written the IR and all the platform porting code and whatever. It's so hard to tell what the real goal is from the page, that I'm suspecting maybe the author doesn't really know either.
- deleted 5mo ago
  [deleted]
- keepamovin 5mo ago
  Well I also think the docs need a rewrite, but that's because my time is going elsewhere. In truth, I'm probably not "qualified" to write a programming language, but I'm doingg so anyway. I use LLMs (20 - 40/month plans) to implement, so do use 100% of my effort for this on design, model, and goals. JS is most familiar to me and lets me work instantly. I know precisely what I want this to be, but I'm also open to its uses blossoming unexpectedly. I'm building because I want this thing to exist, and bc it also v fun. If it offended your sensibilities or you're look for a trad built, ultra-optimized C++-like compiler/chain on day one, you do miss the point a bit, and it prolly ain't for you, bud. lol
  - spijdar 5mo ago
    My comment came off sharper than intended, for which I apologize. That said, two things: I use LLMs for coding a lot, and I'm not turning my nose at the use of LLMs here, though I do think the user-facing pages/documentation could use more direct, human-written language. The other is I do think this is probably something I'd be interested in. I "maintain" a few modified compiler stacks for worth, using Nim to: - generate libc-less, pure syscall binaries with minimal ELF/PE headers - generate Cosmopolitan-libc binaries for all platforms - cross-compile via Zig/LLVM for those platforms It seems like there is some cool work here, I just think it could be expressed a bit more cleanly and directly on the front-page/docs.
souvik1997 5mo ago
Not sure what is the aversion to libc? The code only supports Intel macOS, seemingly because Apple Silicon (arm64) macOS does not support this.
- deleted 5mo ago
  [deleted]
- keepamovin 5mo ago
  No, just because all x86 in one go for 3 OS was easier than doing arm64/aarch64 at same time. Planned for later! for no-libc because i want tiny self-contained bins, no legacy bugs (legacy human slop ;)), and just no C. Not because I'm against C, I just want to start fresh. Fun + pure :)
q3k 5mo ago
slop
- deleted 5mo ago
  [deleted]
- keepamovin 5mo ago
  Link your compiler lol

10 points by keepamovin 5mo ago

manoloesparta 5mo ago

why javascript for implementing this? i mean you can use whatever language you want but i find it surprising lol

deleted 5mo ago
[deleted]
pepa65 5mo ago
That drastically reduces my level of interest (in spite of the write-up sounding very intriguing).

forlorn 5mo ago

op describe {name, role} ( print "user: " + name + " (" + role + ")"; ) Strange choice of brackets usage

deleted 5mo ago
[deleted]
pepa65 5mo ago
But then the call makes more sense: `describe {role: "admin", name: "alice"};`
- keepamovin 5mo ago
  Precisely! Call sites should be traditional syntax shaped, pos args get [ and ] (trad array), and object shapes get trad obj syntax.

MobiusHorizons 5mo ago

Sounds very similar in its approach to magic or hiding as golang. Also the no libc approach is similar, although I believe go was forced to use libc on the BSDs and maybe osx due to the syscall interface not being a stable public interface on those targets

deleted 5mo ago
[deleted]
keepamovin 5mo ago
Yes i believe call codes in assembly do change between some major macOS versions, but that's okay. So far I think it's only using 20 syscalls, and works from iirc v15 up (macOS). For windows we're hitting the stable layer, and I'm not interested in BSD rn - cannot even run standard chrome on bsd, iirc.

spijdar 5mo ago

I know it's such a cheap thing to say, but this could really use a description/web page that wasn't written by an LLM. What came to mind while reading through it is that all of the information and details appear to be technically correct, but they don't really communicate much about the project to someone who knows nothing about it. It's weird. I feel like this could maybe be interesting, but also... huh? I feel like the idea is to produce a small, self-contained compiler with simple semantics that generates simple executables with a simple runtime model, and a basic supervisor model for scheduling tasks. Okay, that's cool. But "vibe coded mass of JavaScript running in node.js" doesn't really mesh well with that vision, at the least to me. Also, as whatever LLM that generated that table says, the code it generates isn't "seriously optimized". I don't buy the idea that compiler optimization is something you can bolt on to a project like this later, after you've written the IR and all the platform porting code and whatever. It's so hard to tell what the real goal is from the page, that I'm suspecting maybe the author doesn't really know either.

deleted 5mo ago
[deleted]
keepamovin 5mo ago
Well I also think the docs need a rewrite, but that's because my time is going elsewhere. In truth, I'm probably not "qualified" to write a programming language, but I'm doingg so anyway. I use LLMs (20 - 40/month plans) to implement, so do use 100% of my effort for this on design, model, and goals. JS is most familiar to me and lets me work instantly. I know precisely what I want this to be, but I'm also open to its uses blossoming unexpectedly. I'm building because I want this thing to exist, and bc it also v fun. If it offended your sensibilities or you're look for a trad built, ultra-optimized C++-like compiler/chain on day one, you do miss the point a bit, and it prolly ain't for you, bud. lol
- spijdar 5mo ago
  My comment came off sharper than intended, for which I apologize. That said, two things: I use LLMs for coding a lot, and I'm not turning my nose at the use of LLMs here, though I do think the user-facing pages/documentation could use more direct, human-written language. The other is I do think this is probably something I'd be interested in. I "maintain" a few modified compiler stacks for worth, using Nim to: - generate libc-less, pure syscall binaries with minimal ELF/PE headers - generate Cosmopolitan-libc binaries for all platforms - cross-compile via Zig/LLVM for those platforms It seems like there is some cool work here, I just think it could be expressed a bit more cleanly and directly on the front-page/docs.

souvik1997 5mo ago

Not sure what is the aversion to libc? The code only supports Intel macOS, seemingly because Apple Silicon (arm64) macOS does not support this.

deleted 5mo ago
[deleted]
keepamovin 5mo ago
No, just because all x86 in one go for 3 OS was easier than doing arm64/aarch64 at same time. Planned for later! for no-libc because i want tiny self-contained bins, no legacy bugs (legacy human slop ;)), and just no C. Not because I'm against C, I just want to start fresh. Fun + pure :)

q3k 5mo ago

slop

deleted 5mo ago
[deleted]
keepamovin 5mo ago
Link your compiler lol