Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: The Mog Programming Language

moglang.org

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Show HN: The Mog Programming Language

#41

Post by Maxatar »

sjrd wrote: post #29
belisarius222 wrote: post #20

Earlier quoted context omitted.

Mog is AOT-compiled, not JIT'd. JIT means the code is interpreted until some condition kicks in to trigger compilation. This is obviously common and provides a number of advantages, but it has downsides too: 1) Code might run slowly at first. 2) It can be difficult to predict performance -- when will the JIT kick in? How well will it compile the code? With Mog, you do have to pay the up-front cost of compiling the pr…

Hum, IIRC, using your definition of an AOT compiler, then V8 is an AOT compiler. V8 never interprets code. It immediately compiles it to machine code. It improves it later, but it's never slow.

V8 is a JIT compiler that uses the Ignition [1] interpreter and only compiles sections of code down to machine instructions once they've been marked as hot via TurboFan [2].

V8 can also go back and forth from machine instructions back to bytecode if it identifies that certain optimization assumptions no longer hold.

[1] https://v8.dev/docs/ignition

[2] https://v8.dev/docs/turbofan

Re: Show HN: The Mog Programming Language

#43

Post by rapind »

zelphirkalt wrote: post #31
JosephjackJR wrote: post #28

Ran into the same thing. SQLite works until you need cold start recovery or WAL contention with concurrent agents. Built a dedicated memory layer for agent workloads - happy to share: https://github.com/RYJOX-Technologies/Synrix-Memory-Engine

Or, when you have a Django project and started out on SQLite, but then begrudgingly introduce M-to-N relationships, but then suddenly notice, that many things you might want to do or implement with those M-to-N relationships are not supported by SQLite. Then you suddenly wish you had started with Postgres right away.

There are definitely some caveats / tradeoffs with SQLite, but I can't think of any that are specifically related to many to many relationships. Which features did you find missing? Lateral joins maybe?

Re: Show HN: The Mog Programming Language

#44

Post by phren0logy »

I am disappointed at the amount of negativity here. HN generally loves an experimental domain-specific language, no matter how janky. To be clear, I don't know if this is janky, but the knee-jerk anti-AI sentiment is not intellectually stimulating.

Re: Show HN: The Mog Programming Language

#45

Post by rapind »

For me this is Gleam. Fairly small lang, type safe, compiled, NO NULLS (very important IMO), good FFI, code is readable, and... you get the BEAM!

Agents can pretty much iterate on their own.

The most important thing for me, at least for now (and IMO the foreseeable future) is being able to review and read the output code clearly. I am the bottleneck in the agent -> human loop, so optimizing for that by producing clear and readable code is a massive priority. Gleam eliminates a ton of errors automatically so my reviews are focused on mostly business logic (also need to explicitly call out redundant code often enough).

I could see an argument for full on Erlang too, but I like the static typing.

Re: Show HN: The Mog Programming Language

#47

Post by shakna »

rapind wrote: post #45

For me this is Gleam. Fairly small lang, type safe, compiled, NO NULLS (very important IMO), good FFI, code is readable, and... you get the BEAM! Agents can pretty much iterate on their own. The most important thing for me, at least for now (and IMO the foreseeable future) is being able to review and read the output code clearly. I am the bottleneck in the agent -> human loop, so optimizing for that by producing clea…

How's Gleam's IO story today? Still need to go via OTP?

Re: Show HN: The Mog Programming Language

#49

Post by rapind »

shakna wrote: post #47
rapind wrote: post #45

For me this is Gleam. Fairly small lang, type safe, compiled, NO NULLS (very important IMO), good FFI, code is readable, and... you get the BEAM! Agents can pretty much iterate on their own. The most important thing for me, at least for now (and IMO the foreseeable future) is being able to review and read the output code clearly. I am the bottleneck in the agent -> human loop, so optimizing for that by producing clea…

How's Gleam's IO story today? Still need to go via OTP?

Under the hood you're still calling into BEAM/OTP but most operations are covered in gleam, at least I've very rarely needed to FFI into Erlang (couple times to extend what a library provides with a custom edge case).

gleam/io, mist, gleam/otp, sqlight, gleam_pgo, etc.

Post reply on HN