Have a quick look. Quite easy to read. Just not sure does it have an advantage over swift which seems quite easy to read, cross 2 platform at least (linux and macOS, the windows seems not on equal footing and five code not working), target llvm.
The basic features of a new language is hard as you can see the posting what expected. Macro (may not be lisp level but template), memory Managrment, purpose (embedded, os, driver and application, ai library, CUDA, mobile app etc.), library, platform, examples and q&a under stackoverflow etc.
... wonder what is the point of learning a new one.
I'm a big fan of Crystal-lang, and I dig the similarity in the sense of "let's start with Ruby-like syntax, and add more static structure". I can see the difference here as being that Bon appears to behave more like Haskell or OCaml rather than like Ruby, which means that there's still a good niche here.
How is memory managed? I'm assuming some form of garbage collection. So this can be used in any instance C or C++ can? Can it use C and C++ libraries because it runs on clang?
Sorry if these are n00b questions.
Bon seems like it could be a nice mix of the wonderful syntax of a python or ruby, and the speed of a C or C++ (or at least a compiled language)
Hi Chris, thanks for checking it out. The first code push for Bon was today, so many things are of course rough around the edges.
Memory will be garbage collected, though I am aiming for zero-cost as much as possible. At the moment it just leaks memory like a sieve as I work out the semantics.
You can indeed import standard c library calls by using a cdef. You can find examples in the stdlib, e.g.:
I am happy you posted early when things are still fluid.
A fast scripting language that is not a PITA, and not tied to a proprietary ecosystem, could carve out a place.
But please ensure that something like destructors remain possible and uncrippled. There are so many more kinds of resources to manage than memory, and we are beginning to accumulate many kinds of memory, too. When you have a solution for general resource management, memory management itself becomes a trivium, or gets locally tunable.
I've seen both Rust's lifetimes/borrow-checker and Objective-C/Swift's automatic reference counting described as "zero cost" (since the bulk of the work is done at compile time).
Rust's borrow checker is zero-cost because it's not doing runtime analysis. But it's not a garbage collector, unless you're using Steve Klabnik's "static garbage collector" terminology [1]. Reference counting is definitely not zero cost. It reduces GC runtime latency for most workloads, but not to zero, and it does so at the cost of reduced bandwidth.
At the moment, memory. But a better story looks like in the near future.
> Memory will be garbage collected, though I am aiming for zero-cost as much as possible. At the moment it just leaks memory like a sieve as I work out the semantics. [0]
Yeah Rust and Go (and D) all have: decent standard libraries (Go exceeds the other two, somewhat resembling Python), a package manager of sorts (Go needsa improve in this aspect, but the strong standard library makes up for it for now, and they are working on it atm), and they're all usually stable.
I think the biggest game changers for any new language is a highly competitive standard library out of the box: web server of sorts that can somewhat scale out of the box is usually a must, but at least a simple enough one is ok too, file IO, crypto, etc are also useful, the less code I have to write the more productive I feel.
Package management is a must too, even if primitive at first (Go's approach is clean and decentralized to some degree, I love that).
It seems a bit premature to claim high performance without having a story for memory. I'm sure ocaml, swift, and basically all languages that do any type of runtime garbage collection would be significantly faster without it.
That's a fair comment. I will say however that the references to performance are more an attempt to keep it in mind from the beginning, rather than being an assertion at this point. I only began working on it shortly after my mom passed away last month (it's dedicated and named after her), so at this stage I'm mostly goal setting and rapidly prototyping.
I hope you can take time to give it another look when its further along. Thanks!
It's complicated. The best runtime GC nowadays tends to take on some of the performance characteristics of a stack, including that finding a new memory slot is O(1). Heap allocation in many non-GC languages, by contrast, ends up involving some sort of relatively gross search for free memory. The same mechanisms also mean that, if you aren't doing anything in particular to manage your memory layout, the GC language is likely to achieve better locality of reference at run time.
This isn't to say that better performance isn't achievable in languages with manual memory management, but doing so often requires a special effort that just isn't going to happen most the time, for reasons of practicality.
I think the point was that you can make memory allocation very fast if you do not care about ever freeing memory, but obviously that is not exactly sustainable strategy. So that is why making claims about performance before figuring out memory management story is bit premature.
I wouldn't call it an extension, but I did use the tutorial to quickly prototype from. There are still some remnants left in the code, but I don't expect much if any to be left in the near future.
I'm curious about scoping. How come `main` in the typeclass.bon example gets to call `norm()` unqualified? Do all the functions in all `impl` definitions just get tossed in one global namespace? If `Norm` is a class, then why are there no `Norm` objects?
Yeah, 'class' in Bon defines a typeclass. While I plan on adding x.norm() as syntactic sugar for norm(x), typeclasses in general are a bit more flexible. For example, while you can use it for polymorphic operator overloading [0], you can also overload a function by changing the types of multiple parameters [1] (as in multiple dispatch).
Ken Thompson is a person, plain and simple. He is not a god. Naming priority doesn't matter when most programmers haven't heard of old Bon. No one is going to think that new Bon is old Bon if no one knows about old Bon. Maybe there will confusion looking at the history if new Bon takes off, but when is there not in computer science? A simple footnote could suffice to avoid confusion.
Thanks for checking it out. They are currently implemented similarly to OCaml, so yes they are linked lists.
This was purely for simplicity (they can be implemented in a couple of lines of code with algebraic data types). Simplicity of implementation is certainly not my priority, just a short term drive, so it will be revisited in the near future.
The basic features of a new language is hard as you can see the posting what expected. Macro (may not be lisp level but template), memory Managrment, purpose (embedded, os, driver and application, ai library, CUDA, mobile app etc.), library, platform, examples and q&a under stackoverflow etc.
... wonder what is the point of learning a new one.