
Show HN: Bon – programming language designed for simplicity, performance, safety - FBMachine
https://github.com/FBMachine/bon
======
ngcc_hk
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.

------
ubertaco
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!

~~~
FBMachine
Thanks, I really appreciate it!

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

~~~
FBMachine
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!

~~~
bendmorris
What is "zero-cost" garbage collection?

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

~~~
m0th87
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...](https://words.steveklabnik.com/borrow-checking-escape-analysis-and-
the-generational-hypothesis)

------
CJefferson
Simplicity, performance and safety? That's everything!

What's it bad at?

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

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

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

~~~
bunderbunder
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...](https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game#Benchmark_programs)

~~~
zokier
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.

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

~~~
FBMachine
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.

------
zestyping
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?

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

~~~
FBMachine
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...](https://github.com/FBMachine/bon/blob/master/examples/equality.bon)

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

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

[https://dlang.org/spec/function.html#pseudo-
member](https://dlang.org/spec/function.html#pseudo-member)

------
FBMachine
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-...](https://github.com/FBMachine/bon/blob/auto_mem/docs/ch02-01-memory.md)

Thanks for all of the feedback!

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

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

~~~
chrislopez
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.

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

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

~~~
FBMachine
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!

------
chrislopez
Looks interesting! I'll give it a spin.

