Soo joined late, what exactly is Boxlang? Just a VSCode extension?

app engine

Soo open source engine or? And trying to trash on CF or? Just some initial thoughts/questions

an executable that acts as as an application "proxy" for more applications, written in java. Think of caddy, only jvm based - IMHO.

not trashing CF, it parses CF

not sure if the Universe needs another programming language

I'm sure Ortus will announce / is announcing those details, they're busy at ITB and I don't want to get anything wrong

yea I will just sit back and try to understand the actual need for this

my understanding is that it would replace either ACF or Lucee

I think I will continue to support Lucee, save my pennies for my own standard edition acf server

one of the big things they mentioned early on in the presentation is that it needs jdk 21+ and does away with reflection (waaay back from jdk 7) that both ACF and Lucee use, and instead uses invokeDynamic

Just weary of this conceptual language and adopt level it would get. From a gov perspective it wont be supported...basically ever...

You can just keep using cf with it

Check out our awesome website (if you’re not watching the keynote): https://boxlang.io/why-boxlang

Mono, for example, with JIt, is about 5.5 meg in size

BoxLang Core is 6 MB.

Not providing Security Notifications to the open source is a WTF

I’m not sure I understand your comment, @Patrick?

image.png

My guess is that if you subscribe we will proactively reach out to you. If you don't, you can watch the blogs, etc for information. Of course we will tell people about issues. The difference is how you find out.

Is the Redis Integration Module separate from the one that Coldbox already has out there or is it a "boxlang" version that is not supported in open source?

not to be overly critical, but since this really is its own product, not so much coldfusion, maybe it belongs in the box channel? Plus, if running an update is not an option in the open source version, its a deal breaker in general.

Just catching up here... so I can only assume with their own Boxlang product, Ortus and all of their "box" products will begin moving away from Lucee. That's going to be a big hit to the Lucee community I think.

☝🏻to the CF community in general

Right

partitioning is not a good thing, imo, but if it going to run Lucee code as is, maybe it's ok

This reminds me of lightspeed httpd server.

@miguel-f not at all! We are fully committed to both the CFML community (BoxLang will run CFML and will continue to), and also to evolving the capabilities and performance of the language. We will continue to support and evolve our CFML products, as they can run side by side with BoxLang-specific code. 🙂

@Patrick turns out it is a really really simple explanation. Just as @garciadev said, we will reach out proactively to all BoxLang+ and BoxLang++ subscribers about security notifications. We can’t do that for open source users because we don’t collect any of your information. 😅 We will publicly announce security notifications in all the appropriate channels.

Thanks @elpete. Also, what about my question on Containers not in open source + Redis module... ^^

Yes, like Jon said, we love CF, but we needed a way to innovate without muddying the CFML language. This is why we have a dual-parser setup • CFML Parser -- parses all existing CF code as defined by Lucee and Adobe • BoxLang parser -- includes more advanced Java interop, new BIFs, new keywords • Both of those parsers create a shared BL AST (BoxLang ABstract Syntax Tree) which is then compiled to bytecode. THis allows us to iterate features in our own parser without competing with Adobe over the definition of what CFML is

Adone?! Another engine enters the market place.

Late to the party... watched the keynote and this looks like an exit strategy on the part of Ortus more than something meant for the CFML community. So, I'll come right out and ask... is this an exit strategy? Is Ortus leaving CFML behind to pursue its own agenda? Not that there's anything wrong with that... just doesn't feel like that's being conveyed and I think it ought to be if that's the plan.

No, it is not. We did this because we love CF and write CF for a living and want to see it thrive for a long time. If we wanted to exit, we would have just moved to Node or Kotlin.

Fair enough. So the primary driver behind creating an entirely new language that happens to also support CF is part of a strategy that will... bring CF developers into BX and, moreover, Java?

I'll briefly address the question of whether a new platform is necessary. This is a very valid question and one we discussed for years. Watch our keynote if you didn't have a chance, but the short answer is we wanted to take CF to a place it can't currently go. We have our sights set very high and we want to complete with every other major language out there. • our runtime is a 100% scripting language (even web is an add-on) like every other language • our entire runtime with all dependencies is 6.5 Megs! • We support (and have production deployed) AWS Lambdas on BL • We have already a full suite of VSCode IDE tooling, step debugging, and code quality tooling • We are min Java 17 (soon to be 21) Java compat using all modern Java features • We have NOT used reflection, but the invoke dynamic APIs which are faster and more flexible (and available since Java 7 😳 ) • Every part of the core is modular, extensible, and fully documented • We've enhanced Java integration with direct Java imports, extending Java classes with BL classes, etc These are things we simply couldn't do with the current engines or even with a fork of them. We love CF and want to take it to do next level stuff, but we needed to start from scratch to do it.

Thanks for the additional info. I understand that you are still supporting Lucee and Adobe CFML, which is wonderful!! I'm just saying that your own engine will be preferred and eventually will start to take away usage/support from the others as it continues to grow. Not saying this is bad. I understand. It is just a potentially unintended side affect. You guys have pushed the CFML community forward for years. Kudos for sure ❤️. That is just the first thing that popped into my head when I heard the news.

Conversely it can also inspire other engines to innovate more. Competition is a good thing.

☝🏼very true

I think most peoples immediate concern might be the future of Lucee. How will BoxLang effect the size of the Lucee community. Will it be the impetus that ends the development of Lucee? There's already been a surprising amount of silence out of Lucee as of late.

My immediate concern is actually not for the engines so much as for the focus of Ortus away from the CFML platform and *box ecosystem. I assume the end goal will be to rewrite, or possibly augment with, BL versions of the current ecosystem to take advantage of all the new capabilities.

My last thought is... If i use BoxLang for a new project, I'd gravitate towards not relying on a cfml transpiler and just use the new language. Why wouldn't I invest that learning in a larger language community with more open source solutions.

@Patrick The new BoxLang Redis Module is similar to the Lucee Redis Extension — both are paid products.

@elpete will redis and pdf forms be available independently or are they only available in a + subscription?

Redis is an add-on in that + version and pdf allows to generate but not populate

just to toss in our two corporate cents, although we love Lucee and have used it exclusively since 2018, we have PRs that have been sitting around for years and communication with the Lucee team depends entirely on whether Zac is around that day (in which case it's pretty good, bless that guy) but from our entirely subjective standpoint, our confidence level that Lucee a) has a plan b) communicates that plan and c) executes that plan is on the low side. We've even had the experience of offering to subsidize certain fixes or updates and getting no answer from the team. None of which addresses the technical considerations. The thing about Ortus is, whether you're paying for a license, submitting a PR, or asking a question in Slack, the experience is the same. They answer the proverbial phone. They listen to all of us bitch and moan and they take it because they know on some level, we all want the same thing, even if we don't always agree on how to get there. There's nobody more invested in this community than them and while one can make a case that this community won't be here at all in ten years, I think the chances of that are higher if we leave that decision to Adobe and Lucee than if Ortus gets to drive the bus. Or make a different bus. Or ... something to do with busses.

Yes, it has taken a lot of resources to develop BoxLang. But our motivation wasn't, "Hey, we could make a buck doing this...". As a CF shop maintaining CF solutions for our clients, one of our issues has been being able to support the entire stack we deploy for our clients. With CommandBox, ColdBox, etc we've had control over a large portion of their stack, but a bug or missing feature in the CF engine was something we'd need to wait months to get fixed at best and years at worse in the CF engine. One of the things here is this provides us with full control over what we deploy for our clients. There's no bugs we can't fix, no features we can't add, no performance we can't tune. A lot of it is about control-- not in the evil maniacal way, but more regarding our ability tell clients we can meet their needs without delay. We can offer embedded CF solutions now. We can offer AWS Lambdas now. We can offer deeper Java interop now. And, of course, as an open source company we wouldn't dream of going through all that effort without making it available to everyone 🙂