Been working on my programming language https://github.com/buzz-language/buzz for 4 years now (with some down periods). Currently mainly working on the tooling: LSP, DAP and formatter. Also managed to get fuzzing working with AFL++ and found a bunch of bugs with it.
HN user
giann
Web architect at BoursoBank, Lua and Zig enthusiast, working on a small programming language https://buzz-lang.dev
When my son was in the last stages of leukemia, Bluey was on repeat all day. He was completely immersed in that world and we, his parents were there with him too.
Now, 5 years after his death, he's little brother is also in love with the show and we watch an episode at least once a day.
There will never be another TV show like this one for those personal reasons and also because it's just too good.
Fair point
It’s really hard (impossible?) to have a type system with user defined types and do without a declarative top level.
This means the language will never coerce things for you implicitly. Booleans are true and false not 1 and 0 or “true” and “false” etc.
They are more like structs with methods. There’s no inheritance only protocols (interfaces) you can conform to.
Buzz is not an OOP language.
Safety pin? No its an astronaut and some stars.
Author here. A few points make buzz a “scripting language” in my view: - runs in a VM - garbage collected - high level - “simple” meaning there’s only a handful of concepts to understand to use it
It’s true that we’re not used to scripting languages having a type system. But its a trend that is catching on: python has types, php too and typescript is at its peak in popularity to name a few.
It’s planned yes
Lua has the same strategy as Buzz around numbers see https://www.lua.org/manual/5.4/manual.html#2.1
Exposing how? If you mean documentation, Buzz as not yet its reference manual but it'll definitely be there.
I'm not excluding the idea to allow the user to choose between the two. But the language must remain simple and relatively high level so I'm wary of going down that road.
I think I list a good amount of reasons to use Lua. The focus of the article is far from being fixated on JS being bad.
This really is not a good argument. You can still write php like in 98, that doesn’t mean you shouldn’t learn modern php if you want to work ever.
I’m not talking about frameworks. I’m talking about ES5/6/2016/2017/7/8 ... which all add new concepts and complexity.
Reading the sources I used to search for the correct term, I think I may have been fooled by ancient greek allophones. Ex. : ὁ ἄγγελος /ho áŋgelos/ Anyway like I said, too late to change now!
I’m talking about the cognitive load of the language. Learning JS is a real complex task whereas learning Lua is not. Learning JS as is is hard since its moving so fast. I think nobody can deny the confusion surrounding the language. Lua is stable is the sense that 5 years from now you will still know how to use it even if you don’t keep up with the latest updates.
Also if you have ever dealt with any babel/webpack craziness recently you know what I’m referring to :)
It’s stable relative to JS which is a nightmare in this regard.
Yes it’s feggari but I think that with two gammas, it’s pronounced fengari. Could be wrong I’m not greek. But it’s too late to change :)
I think you misunderstand the aim of the article. It’s not a case and point against js but for Lua in the browser. When I list positive points of Lua, I’m not implying they don’t exist in JS.
Interaction with JS with Fengari is as simple as "js.global:alert('hello')" with https://github.com/fengari-lua/fengari-interop
Fengari gzipped and minified is about 75kb
I'm the author of Fengari alongside Daurnimator. Please take a look at https://www.youtube.com/watch?v=xrLIgmd8xik (slides: https://www.lua.org/wshop17/fengari.html) for an introduction to it and an explanation as to why this approach is the only viable one to use Lua in the browser and interact with the DOM.
I'd love to use emacs as my primary editor. But it's too slow compared to sublime.
Great work !
This suffers from the same issue as https://daurnimator.github.io/lua.vm.js/lua.vm.js.html and others: there is 2 GC working side by side and it's bound to lead to never freed objects.