Show HN: Bon – programming language designed for simplicity, performance, safety | Hacker News Reader

Show HN: Bon – programming language designed for simplicity, performance, safety

github.com

99 pointsFBMachine35 comments

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.

This is really neat!

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.

I hope this neat language finds success!

Thanks, I really appreciate it!

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.:

cdef sqrt(x:float) -> float

Thanks again for taking a look!

What is "zero-cost" garbage collection?

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.

1: https://words.steveklabnik.com/borrow-checking-escape-analys...

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.

For interesting ideas in compile-time automatic memory management be sure to check out Wouter van Oortmerssen's approach as well:

https://lobste.rs/s/lp0lou/rust_programming_language_seven_r...

> 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)

Have you seen Crystal? It would fit that description

https://crystal-lang.org/

The type system of Bon is more like an ML or Haskell than Crystal.

Simplicity, performance and safety? That's everything!

What's it bad at?

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]

[0] https://news.ycombinator.com/item?id=18975469

Having an stdlib, having a dependency manager and overall stability.

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.

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.

That said, there are certain classes of program where the story is different: https://en.wikipedia.org/wiki/The_Computer_Language_Benchmar...

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.

Hi Charles,

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!

Is this an extension of Kaleidoscope (the language implemented in the LLVM tutorial)?

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.

Damn caught, lol

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?

This seems to be straight from Haskell. `class` here doesn't mean what it means in oop languages.

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).

[0] https://github.com/FBMachine/bon/blob/master/examples/equali...

[1] https://github.com/FBMachine/bon/blob/master/examples/multip...

You should look into UFCS from dlang, maybe that can give you some inspiration.

https://dlang.org/spec/function.html#pseudo-member

For those who had questions about how memory is to be managed, the documentation for that work is being tracked here:

https://github.com/FBMachine/bon/blob/auto_mem/docs/ch02-01-...

Thanks for all of the feedback!

I would love if there was a language combining the strengths of Julia and Swift.

Swift has: much nicer handling of optional values, static typing, better for OOP, function calls via dot notation, zero-based indexing.

Julia has: better ecosystem for scientific computing, the standard library makes lot of things easier, better REPL, working with arrays is easier.

(Just from the top of my head, there are other things.)

This is a terrible name conflict.

Bon, along with New B, was an immediate ancestor to C. The history gets more confusing with another Bon showing up half a century later.

Bon was created for Multics by Ken Thompson. His wife Bonnie, like this other person's mother, was the inspiration for the name.

Ken Thompson has naming priority.

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.

I esp. like the multiple dispatch and the unifying typesystem. I'll definitely steal something from it

Looks nicely designed, but are lists really implemented as linked lists? That's surely going to be very slow.

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.

Thanks!

Looks interesting! I'll give it a spin.

Reply on news.ycombinator.com