Show HN: Ki Programming Language | Hacker News Reader

Show HN: Ki Programming Language

github.com

40 pointski_70 comments

Alpha preview for the ki programming language. Currently linux-x64, macos-x64 only. Windows users can use WSL for now. Feedback is much appreciated.

Open articleView on HN

Always love to see people tinkering with their own languages. Everyone should write a language, at least once in their life :)

Skimmed through the docs. On the first look, the syntax seems to be a blend of Go and Rust.

Was confused by this sentence [0], perhaps some additional explanation/code example could help:

    When a value has ownership, it can be stored and used anywhere. But you can only store it in one place.

Aside from that, I'd really like to know about

1) concurrency support

2) memory management techniques

As those are the most interesting aspects of any C-like language to me.

Good luck!

[0] https://ki-lang.dev/docs/dev/borrow-ref

I say this every other programming language thread: Please, get some code examples up front and center, simple Hello World, and anything that shows whatever strong features your language has for organizing code like classes and so on.

Python, Racket and a few others do this really well. Even on the GitHub a simple short but significant enough code snippet would do wonders.

Maybe the syntax is exactly what I expect and I'll have more interest, or maybe its way off and I don't want to bother. Whatever the case, put some sample code up front and center.

I could add an example to the git README. Currently there is an example on:

https://ki-lang.dev/

https://ki-lang.dev/docs/dev/intro

For a more indept view of the language you will have to see the docs. An overview might not be bad indeed.

Thanks! I didn't see the link, the thread links to GitHub, I think it doesn't hurt to have it on the README even if its just a small amount of code. I now see the language looks somewhat like Go, do you cover differences anywhere between Ki and other languages?

I think the README and website are great. The example code is above the fold!

I think it’s fine. It’s one link away, on the website.

Using the readme as a landing page kitchensink is a GitHubism.

Confused by the "C#: We do not use languages that expect you to install a 20GB IDE just to compile a 'hello world'." note, the .NET SDK is ~200MB last I checked, and Visual Studio is not required to compile C#. Seems like the https://ki-lang.dev/dist/download/linux/x64/latest build from Ki is ~40MB, so similarly sized.

i'll remove it ^_^ it seemed like they want you to use Visual studio and for me it was like 10GB+ for a minimal setup. idk.

that whole section, imo, could use a refactor until the language is more complete. established languages don't do that, and your language isn't complete, so until you can knock those other languages off their pedestals you should keep it light and objective with the comparisons.

yeah, that might be a good idea.

That is the IDE, but it is not required for compiling. You should actually use C# .NET 6 and see what they are doing to prevent null exceptions. You must explicitly require the assignment of null or you will get warnings in the IDE and compiler. Here is an example:

public MyClass Students { get; set; }

You will need to create a new object before you leave the class or you will get an error. Or, you can use MyClass? instead, and it will give warnings any time you try to use Students without checking for null first. This is done before compiling so you can check for these null references through the IDE. This is a big change for C# and can effectively eliminate null references (object reference not set to an instance of an object) exceptions throughout your application.

An order of magnitude is not similarly sized. Neither size is worth complaining over though.

Reference counting is garbage collection. I mention this because the site claims no GC nut you claim I'm this thread that ref counting is sometimes used, which makes sense because borrowing sometimes isn't enough.

While reference counting is technically a method of collecting garbage, in modern parlance the phrase "garbage collector" is mainly used for systems capable of collecting garbage of an arbitrary reference graphs, which reference counting by itself cannot do (cyclic references).

General programming circles: “garbage collection” means only the “tracing” kind

PL circles: reference counting is also “garbage collection”

I sincerely doubt that those two groups are disjunct, or that they use the phrase "garbage collection" exclusively in the contexts you wrote.

Anyone worried about tracing garbage collection is worried about unpredictable costs of automatic reclamation. Even naive reference counting has unbounded pathological cases like this, like an infinite list with only one reference that dies, which triggers a cascade of infinite free ops.

You can do some gymnastics like various types of deferrals to amortise the cost, but now you're getting into more sophisticated tracing-like runtime behaviour which has it's own unpredictability.

There's no free lunch. Better static analysis that can aggregate various allocation into arenas/regions seems like the only way to make this trade-off better.

Not knocking Ki or any new language but what does it offer over existing systems? I see the criticism of a few languages on the website but they all boil down in reasoning to things like: garbage collection = bad, makefiles = bad. It also doesn't mention or demonstrate how Ki addresses the complaints. For example: if Ki doesn't do garbage collection or manual memory management, what does it do? Smart pointers/reference counting? How are circular references handled? (E.g. doubly linked list)

Would recommend removing the "Other" comparison as pretty much anything that can be said there is wildly inaccurate. Would also like to see comparison with Zig as it seems to have similar goals.

"It does not have any garbage collection and instead uses ownership combined with minimal ref counting to manage memory"

Because we only allow you to store values with ownership inside other objects, you cannot have a circular reference. It uses reference counting to know if something needs to be freed or not. But because we keep track of ownership and moved values we are able to run an algorithm that removes most of these counts.

> let num : u8 = 5; <-- auto converts to u8;

Can we please knock it off with reinventing different ways to declare a variable? This also irritates me about Rust. There’s nothing wrong with having syntax that looks like languages that have existed before. How about

[modifiers] [type] [variable name] = [initial value];

What I want in a programming language is not arbitrary new grammars, I want drop-in improvements to languages that already exist. C++ but with better dependency management. Python but statically typed (Mojo where you at?). PHP but standardize all the weirdness.

(Some or all of these rants could be out of date as my knowledge cutoff for languages ends at various times in the last 15 years.)

"let bindings" were present in ML in the 70s; I'm not sure whether they originated there or go back further. They've been used in many languages since, particularly those drawing on ML as a significant inspiration. It's not new, it's just borrowing from something you're unfamiliar with.

Types before the name have several problems. And "let" is, like, one of the most common ways to declare variables.

As another commenter said, types before the variable has problems.

I don't like `let` because it's an extra four characters every time. But the

    [variable name]: [modifiers] [type] = [initial value];

only has one extra character and avoids all of the problems.

> Go: Go is amazing. But it does have garbage collection, which can cause lag spikes in some cases. The creators were also very late on implementing common sense features, such as package versioning and generics. There are some other small mistakes, but the point is that we lack trust in their descission making.

> Rust: Rust right now might be the best language out there right now. It's hard for us to criticize them because we lack the experience of building big rust projects. We do however think rust has a really slow compiler. We also think that rust might be too idealistic where it restricts the developer too much.

> C: C is obviously the best but... we dont always want to manage our own memory. Also their std-lib lacks alot of basic functions. You are forced to work with makefiles or similar build tools and most of those tools are very badly designed.

> C++: C++ is like a worse version of c. They do have the most features of any language, which allows the developers to write the greatest code and also the worst code. You let a developer work on a project for a year and suddenly you are looking at a codebase full of OOP, templates and the most hacky preprocessor logic you've ever seen. That developer says it's built using todays greatest standards, yet no one is able to understand the code at all. Sometimes you have to limit bad practices.

> Other: All other languages use garbage collection which makes them hard to use for millisecond realtime applications. Secondly, most languages allow you to have undefined behaviour.

I'm not sure if this section is really making the case you wanted to make. Either this needs to be rephrased or scrapped all together, it doesn't present the best foot forward because ideally you are recruiting people from these languages, and in your descriptions of them you make some very facile comparisons.

V-lang doesn't have GC, and how it compares to it?

V-lang is vaporware, designed to get Patreon bux off of gullible enthusiasts.

See this post [0] from 2019. Things don't seem to have got much better in recent years [1] [2] [3].

[0] https://xeiaso.net/blog/v-vaporware-2019-06-23

[1] https://news.ycombinator.com/item?id=20230351

[2] https://news.ycombinator.com/item?id=20229632

[3] https://news.ycombinator.com/item?id=31793554

Vaporwave, or vaporware?

Good catch, thanks. Fixed.

Seems like I've been listening to Crystal Castles too much these days.

I've got no particular interest in V, but the hate it gets from a certain group of people here is really perplexing and I don't think it's at all warranted from what I've seen.

Yeah it's weird. They seem to have the same copy-pasted message ready with some old links and whatever they could gather that's more recent. Never fails.

As far as I can see V is well placed on TechEmpower so it must be doing something right at least: https://www.techempower.com/benchmarks/#section=data-r21&tes...

Maybe they didn't deliver on all their claims yet, so what? They seem to be trying something cool. Certainly not reason for all the vitrol.

The devs burned their reputation by repeated blatant lying.

Was it the V devs lying, or was it their near competitors and various evangelists continually spreading misinformation and doing constant media/social media attacks?

I've had similar sentiment when I first seen V. However, after a brief and unpleasant conversation with the developer who was extremely defensive against any, even valid, criticism - especially related to the false advertising! - made me change my mind. Alex knows very well what he's doing, he's a grifter who is collecting money off of smoke and mirrors, and his language still hasn't reached any remotely usable state.

A certain set of what?

I too found it perplexing, and agree it's the right thing to call it out. As you and hu3 noticed, the methodology and continually spamming the same old posts and websites when the language is mentioned is consistent. When looked at as a whole, it comes across as an continual effort by certain parties (and wherever or whenever possible), to bully others for having different preferences or paint a very misleading and negative picture about Vlang (V-lang) for their benefit or purposes.

It's odd how obvious slanderous remarks and insults directed at developers (like grifter), in addition to provably false statements (like vaporware) are being pushed about the project (like language is unusable), don't seem to get removed. Somehow, that gets left up. Not just here, but other threads too.

Yet, attempts to directly refute or at least push back on the barrage of misinformation about a clearly popular GitHub project get flagged, downvoted, or removed. Don't think that would at all be tolerated if such was done to other open source developers and languages, nor for as long (many years). It isn't right nor is it fair.

I think v-lang is faster than ki, rust, go. But their memory management isnt waterproof. Also, they have been in development for a really long time and there isnt much progress. They should have reached 1.0 by now, but they havent and i think it's because the language might have problems.

oh and, v-lang does have GC. they use boehm gc.

Does a hello world still leak memory?

in v? i have no idea, never used it.

> ...they have been in development for a really long time and there isnt much progress.

> They should have reached 1.0 by now...

These are strange statements. People having any familiarity with newer programming languages are likely to not know or be confused by where this is coming from.

V is a relatively new language that came out in 2019 and is in beta. So comparatively speaking, V has progressed well at the least, debatably quite fast. V also has more GitHub stars than all the listed below languages (in beta) combined (per OSS Github language rankings). Let's look at the starting dates for these popular and newer languages:

1) Zig came out in 2016 and is still in beta.

2) Odin came out in 2016 and is still in beta.

3) Jai started in 2014 (full time around 2017) and is still in beta.

4) Red came out in 2011 and is still in beta.

The languages that we see today, which are popular and at the top of the rankings (like TIOBE) are significantly to quite old. Among the youngest languages in the top 20 (your post mentions Rust and Go), they came out in 2015 (Rust), 2014 (Swift), and 2009 (Go). All of these have huge corporate support.

I thought v was older, hmm, ok. But still, all these languages should have reached 1.0 by now. Except for jai, because jblow has other things todo. Wasnt c created in 2 weeks?

> Wasnt c created in 2 weeks

No, because C was derived from B. B was created in 1969 and was much of the basis of what would become C, which is given the release date of 1972. So we can make the argument of at least around 3 years of development, of what would be named C, before reaching a stable or usable enough state.

Languages and goals were much simpler in the past. Stages of development like alpha, beta, or what was 1.0 get kind of mixed up. It's not as clear a process, as we have today.

> Except for jai, because jblow has other things todo

Surely the other language creators had/have other things going on too. One of the main differences, that was attempting to clarify in the previous post, is that certain programming languages have huge corporate backing, which affects their development time. C (AT&T), Go (Google), Rust (Mozilla), and Swift (Apple) have reached 1.0 or stability faster, because of who they have supporting and pushing them.

Independent and more grassroots projects can sometimes achieve 1.0 in comparable times. But, this seems related to how exceptionally talented the lead developers are, experienced (as created other languages before), goals of the project (simpler is often easier), popularity, or how many contributors and sponsors got involved.

Crystal, looks to have took around 7 years to reach 1.0 (though with Windows support issues). Julia, comes in at about 9 years. Nim, another notable project, appears to have took around 11 years. We might can expect things to go a bit faster now, than back then, but within reason. And referring to programming languages that are reasonably well known and used.

V has flexible memory management. This is stated on their website and documentation:

1) Uses GC as a convenient default and is optional (can be turned off with -gc none)

2) Can use autofree (enabled with -autofree)

3) Can use arena allocation (enabled with -prealloc)

4) Can be managed manually (-gc none)

I removed this section from the website. As others said, the text is not good and not really helpful.

Why not make Swift a truly cross-platform language? I find it to be in a sweet spot between safety, performance and usability.

>"Sometimes you have to limit bad practices."

The way to do it I think is to properly mentor / monitor juniors rather than tying up hands of experienced developers.

Zig seems to have similar goals and be rather further along, thay would be a good comparison language. I feel that zig's error handling is cleaner that ki's

> LLVM is however really slow. There isnt much we can do about this except write our own IR compiler, which we would rather not do.

So compilation times are dominated by llvm so there won't be any significant improvement on compilation speed.

> Ki is a statically typed language. It's advantage over most languages is that you cannot have any undefined behaviour.

Java, C, C++ are statically typed. I understand it's not many languages, but they do represent a pretty large share of coders...

Word to the wise: stay away from reporting benchmarks against establish langs until your language is further along. It's often misleading when you see that your toy language is faster to compile / run than established languages, because what you'll find is that as your language grows and becomes more complete, your timings will times will go up.

Usually "no undefined behavior" also becomes an abrasion for performance when compilers grow to support more instruction sets.

This looks promising. If it ends up as Rust without the line noise, I’m 100% on board.

This is the impression I have. Bus the site is way too slim. This language need more features and bigger standard lib. But I like the way the did with the ownership. Way more attractive than Rust. Having classes does not hurt either even though the implementation looks like very basic. Hopefully all of this will improve in the future.

I think the !! operator is redundant. If your language has a "never" type, then exit/return/break/panic should have a return type of never, so those expressions would be acceptable on the right hand side of !? anyway. I guess it's necessary if your language lacks a never type, or has a distinction between expressions and statements, although I don't know really why you would have either of those

Good effort. It feels like there is still a lot of improvement space for languages with a soundness+productivity focus.

Docs need some polishing tough. The comparison to other languages doesn't make the point of Ki clear to me.

Also, error handling feels like black-box magic with all those exclamation and question marks sprinkled everywhere. Those symbols seem vaguely chosen.

! ignores the function error (only possible with void return types)

!? provides an alternative value when the function errors

!! exits the current scope on an error, e.g. return,continue,exit,...

It doesnt seem that complex. Ofcourse, there is also '??' and '?!'. That might make it more difficult. It's not vague actually. if it starts with '!', it's a function error handler. if it starts with '?', it's a null-check.

If you like C but don't want to manage your memory yourself, why don't you take a look at glib/gobject?

Less effort and and hassle to write a new language down to the compiler itself than to deal with glib/gobject. This is unironic btw.

Or zig.

Why would someone choose this over Rust?

at the moment, if you want a non gc language with automatic memory management, rust is your only choice. ki is an alternative, but my goal is to make it a much simpler than rust. I need to spend some more time writing rust & ki in order to answer your question with full certainty.

Another brand new language with curly braces and semicolons... emphasizing line noise over information /sigh OK, ok, I'll show myself out.

What would you suggest instead? Please do not say Python. Using spaces for syntax is madness.

You never make use of horizontal spacing when, say, making notes on paper?

Notes on paper are for humans.

Programming languages are for humans and machines. Machines do better with braces. (I've written lexers for both.)

Also, try to write an automatic formatter for a whitespace-delimited language; if your indentation is wrong, your logic is wrong, whereas with a brace language, if your indentation is wrong, you run a formatter, and it's all golden.

A parser is something you write once and then it's done, so it shouldn't be the deciding factor. And parsing indentation-based languages is not that hard, just replace indents and dedents with a special token.

In a brace-based language, if your braces are wrong, your logic is wrong. How is that better? At least a mistake in indentation is much easier for a human to spot.

Run the formatter, and the brace-based mistake is easy to spot too.

So what's the point of having braces if you're going to use indentation anyway?

To do more things with the source than just compile it.

And how do braces and semicolons help you with that?

Exactly what I mentioned above: source formatting is just one of the things you can do with braces and not significant whitespace. [1]

Also, forget a brace in your program, just one, and the compiler can tell.

Forget one indentation? No dice.

And while braces can break things too, editor settings can make it much easier to break things with significant whitespace. [2] [3]

Also, refactoring. [4]

Editor stuff. [5]

[1]: https://news.ycombinator.com/item?id=3296782

[2]: https://medium.com/@rwxrob/significant-whitespace-is-still-t...

[3]: https://news.ycombinator.com/item?id=24854090

[4]: https://lobste.rs/s/yyuo7f/significant_whitespace_good_bad#c...

[5]: https://lobste.rs/s/yyuo7f/significant_whitespace_good_bad#c...

Python does have an auto-formatter [6], so clearly indentation doesn't prevent that.

> Also, forget a brace in your program, just one, and the compiler can tell.

Should we duplicate every character, so the compiler can tell if you leave one out? This is not a radiation-hardened quine [7].

> editor settings can make it much easier to break things with significant whitespace.

Then use an editor which doesn't.

> Selecting all code contained in a brace or a parents is so much easier (in vim the % movement) than if you have to walk lines.

I have a plugin for Neovim that adds indentation-based motions. The implementation is trivial.

[6] https://github.com/psf/black

[7] https://codegolf.stackexchange.com/questions/57257/radiation...

Reply on news.ycombinator.com