[HN Gopher] Gliimly is a programming language for web services
___________________________________________________________________
Gliimly is a programming language for web services
Author : todsacerdoti
Score : 56 points
Date : 2024-11-15 17:15 UTC (4 days ago)
(HTM) web link (gliimly.github.io)
(TXT) w3m dump (gliimly.github.io)
| not_your_vase wrote:
| I really love the commit messages. This style adds a lot of
| value.
| Alupis wrote:
| This has the appearance of "developed in private, cleansed,
| thrown over the wall" sort of thing.
|
| 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...
| IshKebab wrote:
| Commit history has to be clean just as much as code has to be
| clean. That is to say, it doesn't - but it's far nicer
| working with clean code than tangled uncommented messes.
| derefr wrote:
| > 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.)
| Alupis wrote:
| > If by "clean" you mean "readable" (in the literate-
| programming sense), then I'd be a strong advocate of that
|
| 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/956f80
| 01890d85a4d3...
|
| 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.
| aeontech wrote:
| Just to comment on your last paragraph - I don't really
| understand people's obsession with having squashed
| commits on main. I may not have a local copy of the
| branch that was merged months ago, so I can't get the un-
| squashed history without jumping through hoops. It also
| makes tools like git-bisect much less useful.
|
| 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.
| lolinder wrote:
| > 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
| ...
|
| 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.
| kaycebasques wrote:
| > The commit messages probably mean something to whoever is
| behind Gliim LLC
|
| To me it just looks like they increment by one with each
| commit. Some numbers might be skipped simply because of fixup
| rebases.
|
| https://github.com/gliimly/gliimly/commits/main/
| leptons wrote:
| >Some people get it in their heads that their commit history
| needs to be "clean". It doesn't...
|
| 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.
| kgeist wrote:
| At our organization, no one squashes or rebases either. We
| never delete branches. It's been like this for around 15
| years. Not a single problem.
| leptons wrote:
| I guess it depends on the developers and how they choose
| to commit. On my team we don't commit unless we're ready
| to push, so we aren't creating 100s of commits for every
| feature or bug fix. Some developers seem to think they
| need to commit every 2 seconds for every tiny little
| change. That's just seems like a waste of time to me, and
| it also creates the need to squash and do more stuff with
| git. Anything that distracts me from writing software and
| putting work into the code is a distraction, and git is a
| distraction. I don't really want to deal with git as
| often or as much as some developers seem to use it
| constantly to commit everything...
|
| _git commit -m "added a blank line"_
| kgeist wrote:
| Dunno for me it's great to commit if I just made
| substantial work but it's not ready yet. It's assuring
| that my work won't be accidentally lost if I mess up.
| Especially it's great to commit at the end of the day or
| if I just wrote tests which all pass. Stuff works, I can
| move on, and forget about it. Next day when I write more
| code, and something breaks (but worked yesterday) I can
| easily see the diff between yesterday and today and see
| what changed and where I'm currently at. Commit messages
| remind me of what I did, step by step. Then I push to the
| dev environment and if QA finds bugs, I commit new
| changes which fix the bugs. It's also great for the
| reviewer - they only have to look at the single bugfix
| commit, the rest of the code is fine (already reviewed).
| I don't find a use for squashing, modern tools allow to
| see several commits as one diff.
| dgfitz wrote:
| When I learned about git commit squashing I was sincerely
| disturbed.
| hathawsh wrote:
| Exactly. We have a beautiful tool that can maintain an
| unbroken historical record without being a burden... and
| then we use it to rewrite history? Nooooo!!
| marcosdumay wrote:
| I can't say I have never had a problem.
|
| 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.
| johnisgood wrote:
| > This has the appearance of "developed in private, cleansed,
| thrown over the wall" sort of thing.
|
| 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.
| agumonkey wrote:
| mystery driven development
| rapnie wrote:
| magic number driven design
| wruza wrote:
| Most of the commit messages in my personal projects say "Temp"
| and yet to see any issues with that. I have some repos where I
| maintain commit messages (by inertia) and it always bugs me as
| an utterly useless routine.
|
| 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.
| benatkin wrote:
| My first impression is that like with HTMX, it's for a style of
| web apps that has few uses nowadays.
|
| 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...
| kgeist wrote:
| >My first impression is that like with HTMX, it's for a style
| of web apps that has few uses nowadays.
|
| 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.
| duskwuff wrote:
| Even PHP had a composable expression syntax (e.g. nested
| arithmetic/string/array expressions, function calls, etc). I
| don't think this does; every statement seems to be a unique,
| standalone thing.
| think970 wrote:
| That may be a good thing. I think it's more natural to have
| it that way. I always wondered why a keyword in a
| programming language must have this rigid meaning. In
| English, that's not the case, there's a context.
|
| 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.
| dvdkon wrote:
| I don't see how foregoing composable expressions makes
| the language any more like English or more natural.
| Gliimly is like Assembly (generally seen as very
| "unnatural"), if it had fewer cryptic mnemonics and more
| SQL-like complex commands.
| OutOfHere wrote:
| I see it is implemented in C. Doesn't this add a substantial
| attack surface, especially relevant for web services? How is the
| "memory-safe" claim justified?
| burnt-resistor wrote:
| There is a pervasive, cultural lack of formal verification in
| software, and it's risky, terrible, and should be stopped.
| Formal verification can takes multiple forms and operates at
| different spans across the layers of the stack. We need more of
| it to prove the correctness of compilers, libraries, and
| programs. It is a lot of work, but it's critical to proving
| things are as good, as say, seL4.
| johnisgood wrote:
| We need more Ada / SPARK!
| tlarkworthy wrote:
| there is a culture of type safety which is a very watered
| down machine checked proof that the thing entering a function
| has affordances X,Y and Z. Its not the end to end functional
| verification you are talking about but its not nothing
| either.
| up2isomorphism wrote:
| Yes, it opens a large attack surface for a group of people who
| thinks "memory-safe" is only possible when that word appears on
| the top of a language's features list.
| flockonus wrote:
| TL;DR for people coming from developer friendly web servers like
| Rails, Go, Node, Python -- this is not it.
|
| https://gliimly.blogspot.com/2024/09/web-service-hello-world...
| antihero wrote:
| Why on earth would you want to use a developer unfriendly
| language to build anything in?
|
| This example URL:
|
| http://127.0.0.1/hello/hello-world/name=Mike
|
| What?
|
| Is the project some sort of joke?
| marcosdumay wrote:
| Those are as short instructions as you can get for deploying
| something on the web. It only seems to be missing a development
| server.
| ks2048 wrote:
| Tip for anyone presenting a new programming language, IMHO:
| include a 10-to-20 line program on the front page to give people
| a quick idea of what it looks like.
|
| 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-handler
| duskwuff wrote:
| There's a more extensive worked example at:
|
| https://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.
| benatkin wrote:
| It's a lot like https://hurl.dev/ or
| https://jqlang.github.io/jq/ - it's an intentionally limited
| DSL.
|
| I think if it were more like https://hurl.dev/ I might find
| it slightly more interesting.
| thephyber wrote:
| The criticism wasn't only about how limited the DSL was --
| it was about how some of the design choices are repeating
| patterns which are very common sources of security defects.
| HTML and SQL are DSLs themselves and have non-trivial
| security contexts.
| duskwuff wrote:
| > it's an intentionally limited DSL.
|
| 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.
| Terretta wrote:
| About that: https://gliimly.github.io/about-gliim.html
|
| _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._
| benatkin wrote:
| Yeah I meant that in a good way. You can build powerful
| stuff with a DSL that doesn't include the normal
| imperative programming constructs that most general
| purpose programming languages, but also some specialized
| programming languages like bash, include. jq is a nice
| alternative to python for sifting through JSON for many
| things.
|
| 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
| darwin11 wrote:
| It's interesting, something to look into. It's not a
| general purpose language, true, and I think that's a good
| thing. General purpose languages are too broad for the
| topic of web services. It's like when SQL came out long
| ago to make database programming specialized. I think we
| need something like that for web services, and Gliimly
| may be a good step forward.
| 1oooqooq wrote:
| from the main doc, I don't think this is the intended use
| case.
|
| 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.
| hathawsh wrote:
| The only owner of this project is "Gliim LLC" and it's written in
| C with cryptic commit messages. This looks dangerous. If this is
| an honest project and not an attempt to inject malware into other
| people's projects, you should: - 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.
| koito17 wrote:
| Tip: use the patch format feature of GitHub to view people's
| e-mail addresses.
|
| 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>
|
| Pasting the e-mail address into a search engine reveals another
| work by the same person. In particular,
| https://vixra.org/pdf/1208.0044v2.pdf . The fact the person
| publishes under Vixra likely means they are not someone
| malicious, just what some in the mathematics community call a
| "crank".
| j_bum wrote:
| Thanks for the sleuthing work.
|
| And by "crank" do you mean a recluse? Or someone off of the
| grid?
| koito17 wrote:
| The first definition in [0], that is: a
| person who has strange or unusual ideas and beliefs
|
| [0]
| https://dictionary.cambridge.org/dictionary/english/crank
| duskwuff wrote:
| Another term for it would be "fringe science". The paper is
| an amusing thought experiment based on some baseless
| assumptions; it would be foolish to assume that it
| describes any kind of physical reality.
| evandrofisico wrote:
| I kinda read this paper, and holy crap, it's what we used to
| call in college "one of those guys", during the early 2000's.
|
| 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).
| rendaw wrote:
| Does personal identification make someone more trustworthy? IMO
| trust comes from history. I.e. maintaining a project for a long
| time, working on multiple projects, various contributions, then
| external factors like community, committers + number of eyes on
| the code.
| InsideOutSanta wrote:
| This was true for a long time, but now that we have state
| actors with the capability and willingness to engage in long-
| term attacks (see: Jia Tan), the way we assess these threats
| probably have to change.
| eddd-ddde wrote:
| How does this change with identities? What stops a state
| actor of investing in a years old persona that builds trust
| to be used in an attack?
| InsideOutSanta wrote:
| For an entity like North Korea, it's relatively easy to
| create a bunch of online personas and invest into their
| long-term online presence by (for example) contributing
| to multiple different projects. Once a person has to be
| personally identified, though, the effort and difficulty
| goes up drastically.
| Rebelgecko wrote:
| It can be a good first order approximation if you don't wanna
| take the time to examine the code like by line looking for
| SQL injection opportunities or whatever
| triyambakam wrote:
| Instead of .gliim I would have gone with .glm
| rfl890 wrote:
| Most of the offered cryptographic primitives (encrypt-data[1],
| decrypt-data[2], derive-key[3]) are not easy to use correctly.
|
| 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
| slmjkdbtl wrote:
| I'm still not getting it, this looks like a standard language +
| swapped keywords + web service libraries, what does the new
| language accomplish?
| ahoka wrote:
| Does this run on Temple OS? Would be a good fit.
| anonzzzies wrote:
| Doesn't seem compatible with Holy C.
| sakesun wrote:
| The phrase "programming language for web services" remind me of
| Borland Charlotte language introduced 20 years ago. Those days
| the term web services means SOAP, however. :)
| proxyf150 wrote:
| I tried Gliimly. I just had to after some really weird comments
| below that start like a gossip club and then degenerate into
| preferences for git commiting (like anyone cares about either).
| Anyway, Gliimly's simple to write code with, and without being
| too pedantic about what some people think "web service" or
| "service-oriented" means, it did what I needed it to do. That is
| to say, I was able to build a web application for work
| (insurance) pretty darn quickly, all in a REST-like structure of
| service calls. I am not a fan of an object oriented paradigm,
| though the company I work for (still) uses C++. I used to be all
| over it. But it's gotten so complicated that I am looking to make
| a 180 and find something so simple it stinks. Gliimly could be
| it, or not, but I like simpler. Is it safe? I did try some nasty
| stuff that would overwrite memory, and the program stopped with
| the appropriate message. I tried SQL injection and couldn't do
| it. So the fact it's written in C doesn't mean anything, I mean
| lots and lots of critical software are written in it. I haven't
| run into any bugs, and compiler error message were pretty
| descent. The performance was better than C++ for the same legacy
| app we have, and that's about 12x larger in terms of source code.
| Overall, Gliimly is something I could work with, assuming it
| stays, which is a big if. Most projects like this eventually lose
| steam unless they get some kind of sponsorship from a
| "consortium" of companies, but hey, some work out without that
| kind of backing just on their merit. Time will tell.
| velcrovan wrote:
| Right click - Inspect element, find `body { letter-spacing: 2px
| }` and uncheck. AHHHHHHHH much better
| antihero wrote:
| The website is hurting my eyes to read, is it mono/overspacing
| Times?
|
| 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.
| gbickford wrote:
| > Create Hello World application:
|
| > sudo mgrg -i -u $(whoami) helloworld
|
| Why does it need sudo to compile?
| whalesalad wrote:
| 2px letter spacing on `body` is atrocious
| pmontra wrote:
| The language has a 60s flavor. This snippet reminded me of COBOL
| like verbosity with kebab cased keywords. set-
| number max_loop = 300 start-loop repeat 1000 use i start-
| with 1 etc.
___________________________________________________________________
(page generated 2024-11-19 23:01 UTC)