Live data from Hacker News

The C3 Programming Language

c3-lang.org

191–200 of 270 posts

Re: The C3 Programming Language

#191
post #180
post #177

Earlier quoted context omitted.

I have never found either (1) or (2) to be a problem in hundreds of thousands of lines of Python. > In particular, C3's "path shortening" ... we'd have to pay by actually writing `std.io.file.open("foo.txt")` or change to a flat module system. You can easily and explicitly shorten paths in other languages. For example, in Python "from mypackage.mysubpackage import mymodule; mymodule.myfunc()" Python even gracefully h…

Of course you can explicitly shorten paths. I was talking about C3's path shortening which is doing this for you. This means you do not need to alias imports, which is otherwise how languages do it. I don't want to get too far into details, but it's understandable that people misunderstand it if they haven't used it, as it's a novel approach not used by any other language.

Oh, I understand it. I just think that (a) explicit is better than implicit; and (b) the amount of characters that Python requires to keep imports explicit is truly minimal, and is a huge aid to figuring out where things came from.

Re: The C3 Programming Language

#192

I've enjoyed using the C3 language to make some simple games [0] and found it really easy to pick up. The only thing that I got hung up on at first was the temporary memory arenas which I didn't know existed and ultimately really liked. [0] https://github.com/Syn-Nine/c3-mini-games

I took a look at your github and saw you implemented the same games in multiple languages, which one did you like the most and why?

To be honest, my favorite language is my own language Tentacode [0], closely followed by my recent experimental language Gar [1]. Tenta is not publicly released yet, but the source can be downloaded on github [2]. I've been experimenting with making games in a bunch of languages to inform the design of Tenta by seeing how much I can strip away and still successfully, efficiently make a meaningful game.

[0] https://tentacode.org/docs/language/basic_types/

[1] https://github.com/Syn-Nine/gar-lang

[2] https://github.com/Syn-Nine/tentacode/tree/llvm

Re: The C3 Programming Language

#193

This seems pretty neat! Still holding out for a language with Go's runtime and compilation and performance characteristics, but language syntax and semantics like Gleam... Maybe one day

That would be C# ?

I understood the sibling comment recommending Ocaml and to a lesser extent Borgo, but OP is looking for a high level functional programming language based on giving Gleam as the reference point. How does C# fit here.

I do think the compilation speed and runtime is at least in the same ballpark, but C#, while a perfectly fine language, is definitely not a functional language in syntax or semantics.

Re: The C3 Programming Language

#195
post #93

Earlier quoted context omitted.

It's not just arbitrary renaming (Rust Result vs C++ Expected is fine) -- it's choosing a conflicting name for an extremely common abstract data type. If they wanted to call it "Elephant," great, but Optional is a well-known concept and Result/Expected isn't the same thing. (I don't really object to the idea of skipping a real Optional type in a language in favor of just Result .)

I would guess the two languages have little overlap in who they appeal to, and this is a bit closer to C semantics which is their north star. In C for functions that don’t return a value you often return a null for success or a return code that is a defined error code, which is exactly how Optional works in C3 (but you don’t write the word Optional in the function head). If you need to return a value in C you often p…

It's not about C semantics it's about the name of a commonly understood concept. What you just described there is the "result" pattern not the "optional" pattern. Of course the designers are free to call it whatever they want but swapping common terminology like that is a blunder from my perspective.

Re: The C3 Programming Language

#196
post #79

Earlier quoted context omitted.

Yes, this is fine for basic exploration but, in the long run, I think LLVM taketh at least as much as it giveth. The proliferation of LLVM has created the perception that writing machine code is an extremely difficult endeavor that should not be pursued by mere mortals. In truth, you can get going writing x86_64 assembly in a day. With a few weeks of effort, it is possible to emit all of the basic x86_64 instructions…

>Adding new backends should be trivial. Sounds like famous last words :-P And I don't really know about faster once you start to handle all the edge cases that invariably crop up. Point in case: gcc

It's the classic pattern where you redefine the task as only 80% of the original.

Re: The C3 Programming Language

#197

Earlier quoted context omitted.

Which one specifically does ending a process not clean up the memory?

Any flat memory rtos. Not everything is *nix. For example microcontrollers or aerospace systems.

Can you link to one that has individual virtual memory processes where the memory isn't freed? It sounds like what you're talking about is just leaking memory and processes have nothing to do with it.

Re: The C3 Programming Language

#200

I keep thinking about perhaps LLMs would make writing code in these lower-level-but-far-better-performing languages in vogue. Why have claude generate a python service when you could write a rust or C3 service with compiler doing a lot of heavy lifting around memory bugs?

You still want to be able to easily review the LLM generated code. At least I want to.
Post reply on HN