Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • from the example:

      public class HelloFu
      {
        public static string GetMessage()
        {
            return "Hello, world!";
        }
      }
    
    
    translated into swift this gives a class, which means i'm dealing with reference semantics (and potentially threading issues) and probably not something i necessarily want... i tried struct, but there is no struct keyword in fusion it seems...
  • Nice idea. I'm just wondering how to debug code written in fusion... probably you must focus on one of outputs, debug that one, and then back-fit the changes to the fusion source. :/
  • It’s not a problem in practice if debug data is emitted properly. For example I used the VS Code C++ debugger extension with Zig.
  • As others say ; how does debugging work? I was a user of Haxe and Monkey and both had/have serious debugging issues; I think this can only work if it has an interpreter for itself (self hosted I guess ideally) with a proper debugger.
  • I like it. I just wonder if today transpiling is better then Agentic Programming. Any specific use case where i should use it? With a good model, SKILLS.md, AGENTS.md and prompts I am able to do - allegedly - a better job then a transpiler, no?
  • The idea it's good but hard to make it good. A universal language is hard to optimise for a particular language.
  • The point, AFAICT, is not in using all capabilities of all the target languages. Rather, it's about expressing some narrower class of computations and grafting them seamlessly into the target languages. Think of data formats, parsers, network protocols, stuff like handling and rendering of text, etc.
  • Bad idea. It either takes a useless subset of all languages or do weird abstraction that wouldn't fit in a language otherwise.
  • How (and why) are you targeting OpenCL? It has quite a different programming model
  • Nice stuff, I'm working on something like Kaitai Struct, and it'll be very convenient to codegen to Fusion, to support multiple target languages.

    However, what I like the least in all kind of software is underdocumentation. There's some reference, it's not bad, but actually it's just bunch of examples. If I want to find out exactly how a particular type or statement translates into a specific language, I'll have to dig into the code.

  • > implementing reusable components (libraries) for C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C, all from single codebase

    Why is this needed? I can't imagine that. I am sure writing code in fusion will produce C++ and Python code which is suboptimal and doesn't fit well in these languages.

  • In theory having it in the same language could provide performance benefits, vs reaching out to a C library and dealing with C interop fun. Any language that is JIT'd would have native bytecode to optimise instead of a black box.
  • ORMs and variations like Protobuf or things that have to be cross-plateform in the wide sense. The perspective that the same source will behave the same in various environments, and "velocity" trumps performance considerations. If you want to work on things where performance matters, consider embedded/firmware programming ;-)
  • I think the target application is writing the same algorithm in multiple places with a guarantee that the logic will be based on a single source of truth. Not unlike Protocol Buffers work to standardize data layout across platforms.

    It still feels overcomplicated compared to the standard solution of writing a library in a compiled language you like, exposing a C ABI compatible interface, and hooking it up to any language that can work with that (i.e. any language).

  • I once had a C# server with a TypeScript frontend (this was for work, so I didn't choose the tech stack). We had one part of the code which had a lot of calculations. We wrote the code in a C# library, then used Roslyn to analyse the C# code and generate TypeScript code that matched it identically. This way the client could visualise the results on the client with zero latency, no server roundtrip, but ultimately the server would be in charge of the final calculations. It was a great solution, I would do it again.

    We could have potentially used Fusion for this had it existed, but I don't know if we would. We didn't have to support 12 different languages, only 2.

  • It's a nice idea but the C portion expects an array of unknown size, no bounds checking possible at all and it's also not returned how large the PNM image is. I also don't understand why glib is needed here to get the array to work. It's also missing the stdint.h include to be able to use uint8_t.
  • It seems similar in concept to Haxe, but focused on writing libraries which are then called from the target language, rather than building your whole application in Fusion. Is that correct?

    How are exceptions translated to languages which don't have exceptions, like C?

    The amount of targets seems impressive, but I don't see anything resembling a standard library. Usually, it's in the standard library where diverging behavior between targets shows up. Haxe's documentation tends to cover those issues, and lets you know when a behavior is target-dependent, or unspecified. They do try to be consistent between targets whenever possible in a performant way.

    Loreline[0] is a recent project which leverages Haxe to build a cross-platform library. Is there a similar project showcasing how Fusion can be used for that?

    [0] - https://loreline.app/en/docs/

  • I'd love to see a comparison to Haxe. https://haxe.org/

    I wonder what performance and generated code size/quality look like.

  • Apparently Haxe cannot target OpenCL. It can target PHP and Lua instead.
  • At a time I was very interested in haxe, but their focus on games made it (perceived as) lacking in the area I wanted to use it (cross platform client-server apps). Recently rust seems to have taken this role for me.
  • From https://github.com/fusionlanguage/fut/discussions/119#discus...

    > I've read about Haxe in 2000s, before I started my work on Fusion. They have different design goals: in Haxe you create whole apps, in Fusion you create components to be used from other languages. Haxe has syntax similar to the (now dead) ActionScript, Fusion is similar to C#. Fusion transpiles to C, D, Swift, TypeScript, OpenCL and Haxe does not.