I just want to say that "Ko" is an excellent name for a deadlock-free language written in Go. Kudos.
Ha! I didn’t even notice, thanks for the hint.
Ko – A concurrent, immutable, functional language
51–60 of 67 posts
Re: Ko – A concurrent, immutable, functional language
#52Earlier quoted context omitted.
isn't this a little demanding and entitled? for example, the submitter of this post to hacker news may not be the creator of the language and repository. so the creator is off just having some fun creating a language, with more than minimal documentation, and uploads it to github to track changes and generally make it public. then someone thinks it's interesting and posts it here, and the top comment is someone with…
> isn't this a little demanding and entitled? No. The poster shared it to HN because they want other people to look at it. Which is fine, but they're asking for our attention, and they need to respect that fact—and us—and not waste our time. Sharing a new language but making us dig around to understand one of the most fundamental things about the language—what the code looks like—does not respect us, our time, or our…
you missed my point of the poster not necessarily being the creator of the repository.
Re: Ko – A concurrent, immutable, functional language
#53I love the generic function aspect of this, where there aren't necessarily specific inputs or outputs. This will make code reusable by factors. A simple use being not needing to define both `toRadians` and `toDegrees`, just definite the relationship. But I believe this can be taken to the point of getting backpropagation for free once forward propagation is defined in neural networks. Not to steal any thunder, but I'…
I could be jumping to an incorrect conclusion, but I think you are misreading the description of Ko's genericity. It doesn't mean that inputs and outputs are not distinguished. It just means that arguments and return values aren't explicitly typed. The kind of Prolog-style unification you are talking about is something different.
You're right. This sentence and the general syntax of the language mislead me
> Genericity means that functions do not have to declare argument and return value types, which makes them highly reusable.
Thanks for being kind about pointing out my massive presupposition
Re: Ko – A concurrent, immutable, functional language
#54Earlier quoted context omitted.
> isn't this a little demanding and entitled? No. The poster shared it to HN because they want other people to look at it. Which is fine, but they're asking for our attention, and they need to respect that fact—and us—and not waste our time. Sharing a new language but making us dig around to understand one of the most fundamental things about the language—what the code looks like—does not respect us, our time, or our…
you missed my point of the poster not necessarily being the creator of the repository.
Poster's user handle is petar, and petar happens to have merged the latest PR in Ko repository, so I'd say there's a pretty good chance it is the same person.
Re: Ko – A concurrent, immutable, functional language
#55Couldn't find it easily, but what model are they using to make this dead-lock free as they advertise? I've seen a number of languages try to accomplish this same goal but usually with a huge caveat on what kinds of programs are allowed, or by randomly killing threads when a dead-lock is detected.
If you understand why a purely functional language like Haskell rocks at parallelism without worrying about deadlocks, then: same answer here. I'll agree this isn't ready yet to be the first example of functional parallelism in someone's life, but I'm pretty excited to play with this computational model.
Even with Haskell you can still have deadlocks [1]. They give you the tools to write code that you can prove won't have them, but restricting the kinds of programs you can write. But it's an opt-in thing, it's not a promise of the language that you can't do it. Rust is trying to do a similar thing, but it's still also possible to write yourself into a corner with deadlocks if you work against the feature.
Another language I saw recently that has this promise was Pony which uses an actor and message passing model to try to accomplish this but it doesn't actually prevent you from hitting the case, instead it'll just kill a random actor until the deadlock is gone [2]. This can work but it needs to be up front that you MUST write your software to be ready to be killed at any time and continue to function.
It's really an impossible situation to completely "solve", given that doing so would require a solution to the halting problem. So it's always a fun place for me to start looking at any new language if they talk about locks and dead-locks. So far I think Haskell and Rust (and probably other ML family) have the best balance being struck since you can opt in to statically proving this if you restrict those parts of your program but you're not required to do so by the language itself.
[1] https://www.fpcomplete.com/blog/2018/05/pinpointing-deadlock... [2] https://news.ycombinator.com/item?id=9485333
Re: Ko – A concurrent, immutable, functional language
#56Earlier quoted context omitted.
> isn't this a little demanding and entitled? No. The poster shared it to HN because they want other people to look at it. Which is fine, but they're asking for our attention, and they need to respect that fact—and us—and not waste our time. Sharing a new language but making us dig around to understand one of the most fundamental things about the language—what the code looks like—does not respect us, our time, or our…
you missed my point of the poster not necessarily being the creator of the repository.
The point of posting things on a site with comments is so people can comment on them. Even if we knew for a fact that the poster wasn't the creator, it would still be appropriate to comment on an annoying aspect of the project.
Re: Ko – A concurrent, immutable, functional language
#57Earlier quoted context omitted.
Except that Haskell and OCaml as implementation languages would signal huge academic bias and therefore likely inability to come up with a usable language or at least there exists a negative correlation with those languages.
Just as a sidenote, Rust's compiler was first implemented in OCaml after all, is Rust "academic and unusable"? ;)
I don't agree with "unusable" but "academic" probably has some justification.
The fact that it has a "let" keyword does make it "academic" to me. I'm fairly sure we can now have compilers that don't need such hints to be explicitly provided. Rust enjoys its let keyword so much they have a "If let" syntax.
Languages that use random punctuation without providing real benefit could also use a cleanup. Lua with ~= is a good example: Tilde in mathematics means "approximate". In C != means "not equal". So lua's designers can be accused of either never seeing C or deliberately choosing something different. Given that Lua is implemented in C they can't easily claim ignorance.
Archaic and awkward ways of expressing code shouldn't be propagated into new languages unless here is a clear benefit. Have a look at Erlang. Excellent overall but has lots of old warts from yesteryear you wouldn't want in a modern language. Eg look at its string syntax / naming rules. Now compare it to Elixir. Modern. Same VM.
Moving with the times is useful. Future languages shouldn't be adding debris everywhere just to be different.
Re: Ko – A concurrent, immutable, functional language
#58Earlier quoted context omitted.
Just as a sidenote, Rust's compiler was first implemented in OCaml after all, is Rust "academic and unusable"? ;)
I don't agree with "unusable" but "academic" probably has some justification. The fact that it has a "let" keyword does make it "academic" to me. I'm fairly sure we can now have compilers that don't need such hints to be explicitly provided. Rust enjoys its let keyword so much they have a "If let" syntax. Languages that use random punctuation without providing real benefit could also use a cleanup. Lua with ~= is a g…
“let” us a required feature of the Rust grammar; the semantics would be significantly more complex without it, making tooling harder, etc. we didn’t add it for no reason.
Re: Ko – A concurrent, immutable, functional language
#59There is not a single example in the README. I checked the step-by-step guide, but it starts with installation and documentation instructions, then imports, and I don't know yet how the language feels like. Ok, let's check that handbook then. Computation model, type system, ... Please, I just want to see a program with a dozen lines of code to see what it looks like. Of course, more extended examples with the intende…
The law for making a new language: always include examples up front.
Even in pure mathematics, a good rule is to give examples (if simple) right after the definitions. Examples always help.
Here's a post by the Fields medallist Tim Gowers:
https://gowers.wordpress.com/2007/10/19/my-favourite-pedagog...
Re: Ko – A concurrent, immutable, functional language
#60There is not a single example in the README. I checked the step-by-step guide, but it starts with installation and documentation instructions, then imports, and I don't know yet how the language feels like. Ok, let's check that handbook then. Computation model, type system, ... Please, I just want to see a program with a dozen lines of code to see what it looks like. Of course, more extended examples with the intende…
Thanks, came to the comments hoping someone could point me to code - I wasn't having any luck at all.