Gliimly is a programming language for web services
gliimly.github.io
gliimly.github.io
After a few clicks, I think I found the "Hello World" example,
begin-handler /hello-world public
get-param name
@This is Hello World from <<p-out name>>
end-handlerhttps://gliimly.blogspot.com/2024/11/multi-tenant-saas-notes...
And, at a glance, I see:
- HTML output being constructed by string concatenation.
- SQL queries being constructed by what looks like sprintf.
- No functions, just HTTP handlers, some of them marked as "private".
- No expression system, just non-composable commands like "hash-string" or "match-regex".
- No evidence of an object or class system.
- Some evidence of filenames with 'magical' behavior like "before-handler.gliim".
None of this fills me with confidence. This is a toy at best.
I think if it were more like https://hurl.dev/ I might find it slightly more interesting.
That isn't the sense I get from the example. It shows an entire user-facing web application being written in this language, with every indication that the author thinks this is an appropriate use case.
Modeling language
Gliimly is a very high-level modeling language. It's about solving problems by modeling the solution and connecting the components to create high-performance, low-footprint executables; and not about managing memory, manipulating bits and bytes or writing complex code.
Syntax matters
Syntax of a language matters, not just for writing code now, but for someone else reading it years later. Gliimly language is designed to be intuitive, easy and rapid in use on both ends, and to be close to the way humans are wired, rather than machines.
Language
Gliimly programming language is memory-safe, meaning it will prevent you from accidentally overwriting memory or freeing it when it shouldn't be. Gliimly's memory-handling is not limited to just memory safety; it also includes automatic freeing of memory at the end of a request, preventing memory leaks which can be fatal to long running processes. Similarly, files open with file-handling statements are automatically closed at the end of each request, serving the same purpose.
Types
Gliimly is a strongly-typed language, with only three primitive types (numbers, strings and booleans) and a number of structured types (message, split-string, array, index, index-cursor, fifo, lifo, list, file and service). Gliimly is a declarative language, with a few lines of code implementing large functionalities. Gliimly is also very simple - it does not even have expressions! That's because it's designed to achieve application goals with less coding.
Statements (see also https://gliimly.github.io/statements.html)
Gliimly statements are designed for safety, ease of use, and ability to write stable code. Most statements typically perform common complex tasks with options to easily customize them; such options are compile-time whenever possible, increasing run-time performance.
I think glimly is an interesting project but I wonder why they don't use something like mustache ({{ param1 }} for escaped and {{{ param2 }}} for unescaped) instead of p_web
it is about apis, not html.
it is about chaining webservice calls, not using sql.
it's for business logic, not generic programming needing classes
my guess is that this wants to be the excell of the aws era.
- Say who you are.
- Commit as individuals, not as the company.
- Explain how this is memory safe. The C language makes that seem very unlikely.Looking at the commit log, the initial commit caught my attention. The author of the initial commit does not link to any particular account on GitHub. See https://github.com/gliimly/gliimly/commit/23e44479d675d3124e...
From here, we can see some identity.
From: gliimly <sergemij@yahoo.com>
And by “crank” do you mean a recluse? Or someone off of the grid?
a person who has strange or unusual ideas and beliefs
A computer scientist or engineer who is reasonably competent in his area, but that for some reason decided that he is the one who is going to unify all of physics with his pet theory based on a superficial understanding quantum theory and relativity (always special relativity, never general relativity).
The encrypt/decrypt data interface uses AES-256-CBC with (seemingly) no authentication, and the key derivation uses PBKDF2 with default iterations of 1000 and vague instructions on which value to choose. No interface to a memory-hard KDF is available.
This, along with the notion of memory safety from untested C code doesn't really instill a sense of confidence in me...
I would suggest throwing away all the cryptographic primitives you currently have and instead interface with libsodium, which is a library designed for the rest of us non-cryptographers.
[1]: https://gliimly.github.io/encrypt-data.html [2]: https://gliimly.github.io/decrypt-data.html [3]: https://gliimly.github.io/derive-key.html
The commit messages probably mean something to whoever is behind Gliim LLC.
Some people get it in their heads that their commit history needs to be "clean". It doesn't...
If by "clean" you mean "readable" (in the literate-programming sense), then I'd be a strong advocate of that.
I would like to one day see a repo that is maintained in such a way that, if you just dump out the commits in chronological order (e.g. `git log --patch --reverse --pretty=format:"%s"`), the result is essentially a jupyter notebook that explains the system being built as it builds it.
Such a thing would require a lot of rebasing, of course.
---
But of course, actually looking at giimly's commit history (https://github.com/gliimly/gliimly/commits/main/), you don't mean "readable." You mean "says nothing."
I think this repo is clearly the result of "development in private", but I don't think the commit messages here were "cleaned up." I think this is just this person's way of using git in a single-user context — they just want to incrementally save WIPs, so they number them. (Maybe they even use an editor plugin that does this for them on save, or through a keyboard-shortcut.)
That being said, I do sometimes also see this in the cases of private repos that were so messy and fraught, with long-lived now unmergeable feature branches, that the best way to integrate everything was to just convert each long-lived branch into a set of .patch files; manually prune and edit those .patch files in a text editor; and then `git am` each patchset into a synthetic commit. Those commits don't really have coherent purposes — they're just incremental steps of a single long integration — so you may as well just number them. (Usually, though, people rebase-squash these all once they're done.)
I don't disagree. However the commit messages should have some meaning.
Looking at the repo closer, it appears the commit messages are release numbers:
Commit 91: https://github.com/gliimly/gliimly/commit/956f8001890d85a4d3...
Release 91: https://gliimly.blogspot.com/2024/11/gliimly-91-released.htm...
Which, if the case, is even more awful. Now to understand the change history, I need to consult/cross-reference some documentation page that might 404 in the future. Additionally, the releases have many un-related changes grouped together (as one would expect for a release, not a commit).
Lately I've become fond of the squash-merge. All development is in a branch, and to merge you open a Pull Request (or equivalent on whatever platform you use). The PR gets squashed into one commit that references the original PR, which retains all of the commit history and discussion/review comments. Best of all worlds in my opinion, and frees developers to commit freely without consequence or care.
With my team, once you are done with your PR, you do a quick rebase pass over your branch and squash any remaining partial/in progress/fixup commits into a final set of meaningful logical commits - this set gets merged into mainline wholesale, without any further squashing.
Each commit has the ticket id in the commit message, so you can find all related changes easily if ever needed. This gives us history that's both granular enough to be useful, and meaningful.
(Granted, if your team is disciplined enough to only have very small and granular PRs that only deliver a small logical unit of change at a time, the distinction between approaches becomes moot... but in my experience most PRs tend to be a little bigger that that, and contain at least a couple of related but distinct sets of changes)
And yeah, the commit history in this project is just hilarious.
A lack of this simple discipline is what causes people to push for squashing. If you squash every PR then your commits may be too coarse, but you don't end up with random "fix tests" commits everywhere. If it's not part of your company culture to do the cleanup then it's harder to get that rolling than to just impose a repo rule that only squash merges are allowed in.
To me it just looks like they increment by one with each commit. Some numbers might be skipped simply because of fixup rebases.
I do not care about git commit history at all. Do not squash. Don't do anything other than commit, push, and merge PRs. I don't delete old branches, I don't do anything beyond the basics. I don't even use rebase. It has never bit me in the ass at all in all the years I've been running this team. The less I have to do with git, the better.
git commit -m "added a blank line"
I have surely seen a handful of cases where squashing and rebasing to keep history clean would make my work way easier. But the squashing and rebasing would waste way more time than those would gain.
I guess if you are managing a popular public repository, at some point the trade-off inverts.
To be honest, I do this with personal projects, and by "this" I mean I finish the project, try to polish it and "cleanse" it as much as possible, and then git commit add with message "Initial commit", and after that of course I have proper commits for bug fixes, feature additions, etc.
In the rare case when I have to investigate history, there are actual code changes and all the tools to navigate them. There’s no “read through the log to find a change” in my workflow, just like there’s no “read through code to find an identifier”.
It doesn’t mean that this works for all projects and workflows. People report their day saved by a commit message. But that blanket belief in sacred commit messages is just that. It’s not unusual to see a 1-person repo to contain synthetic messages cause under no peer pressure people act like it’s natural to them.
> sudo mgrg -i -u $(whoami) helloworld
Why does it need sudo to compile?
set-number max_loop = 300
start-loop repeat 1000 use i start-with 1
etc.Also the language looks...really difficult to mentally process and doesn't seem particularly as expressive as anything that currently exists and is used regularly.
It seems to be doing everything unpleasantly/wrong to the point I'm not sure if it's some sort of elaborate joke.
The web site is clean and easy to navigate.
The language is much less jarring than most commonly used languages today, which unless you're using them day in day out, often look undecipherable.
Gllimly looks like I could pick it up in a day. Very expressive.
I guess for people who worked with complicated languages much of their career, their stuff is easy.
Realistically though, this language would be my choice if I were to learn something new. And that's no joke.
Yeah, they're fucking with the letter-spacing, adding 2px.
Note to devs that want to play web designer: Don't. And especially don't mess with letter-spacing.
https://gliimly.blogspot.com/2024/09/web-service-hello-world...
This example URL:
http://127.0.0.1/hello/hello-world/name=Mike
What?
Is the project some sort of joke?
Do any of you have real jobs, where you need to do things fast and easy without the mess? This seems like a good fit.
Most comments are kind of snooty here, don't ya think?
When I look at the examples, like the top one (currently) on the web page, which is a "SaaS example in 200 lines" (or something to that effect), it looks good to me. Simple, quick to grasp.
I actually ran it, and it worked. I was able to quickly make something useful (especially since PostgreSQL is my bread and butter), and there's an application server that runs just fine. I even tested performance with ab, and got some 3900 requests per second through Nginx. Of course that's meaningless given we all have different hardware, but I can tell you it's pretty zippy.
And what's wrong with the URL above? How's that a joke? In what universe?
Someone below mentioned this is like an assembler. What? It's the opposite you guys. If I look at the example, and I look at the code I'd have to do in just above any language (and I've done it twice so far in different languages), Gliimly looks like a step forward to me. Say when I did this in Go, I'd say that looked like an assembler, and Gliimly looks like a high level language.
I wonder where are these comments coming from. Folks from other projects who don't like competition? Geeks who love their ancient tech to the point of exhaustion?
Come on folks, give the rest of us regular people a break.
The benefit of the HTML syntax quickly goes away if it has a JavaScript frontend. The routing doesn't make sense in a non-trivial app. For a non-trivial app, something more flexible like Django's routing system makes sense.
It says it's service-oriented. It doesn't have what I expect from something service-oriented in its big example, though. For instance the entry point to the app is /session/start and it doesn't route based on HTTP methods. https://gliimly.blogspot.com/2024/11/multi-tenant-saas-notes...
What do you mean? I see nothing common with HTMX. It feels more like old PHP5 projects, where they mixed business logic with controllers, database access and template rendering all in one big soup.
Gliimly seems much simpler than PHP or other "classic" programming languages out there (C++, Java, Go, whatever). I think there's something to the idea of expressing programming closer to English, in a declarative way.
I'll give it a try, I'd love to type (much) less and just sort of "talk" programming, because that's what this looks like.
After all, what do you think AI is all about? It's about replacing tedious expressions with pre-built programmable components. Granted, it's more like a helper at this point, and maybe not a very good one, but that's where we're going.
So a Gliimly idea of an expressionless programming language where you can use "programmable" pre-built components in a way that lets you write web applications, that's very attractive.
I would say Gliimly would be great as a solid base for an AI-programming chatbot.