💾 Archived View for bbs.geminispace.org › s › programming › 21749 captured on 2024-12-17 at 15:09:55. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
What is a good Small Web programing language ? While I like Python, it's corporate driven featuritis is getting me down.... C is an obvious Small Web language, but I'd rather use something a bit higher level than that. Any thoughts ?
Nov 14 · 5 weeks ago · 👍 f008600
What programs do you intend to write? I think that it depends on that as well as on the preferences of programming languages etc.
🎵 alice-sur-le-nuage [OP] · Nov 14 at 17:12:
I associate all things Javascript (Node, React, etc.) with the startup world, totally puts me off. Rust is better in that sense, I've been putting off learning it because the performance gains are not worth the extra complexity for my use cases. I might try - but I'll wait and see if other suggestions come up !
🎵 alice-sur-le-nuage [OP] · Nov 14 at 17:13:
As for what I intend to write: right now networky things (e.g. a gemini server), and text file manipulation things (e.g. static site builder). I know there's plenty of both of those - just writing my own out of interest !
I wrote a few things in free pascal. was fun to learn.
Go lang ?
Go doesn't have much syntax, it's been stable since 1.0 (no Python 2->3 event, no C++98/11 language changes): it's a boring language that's easy to learn and easy to work with
I can second Go as a nice choice. There's a package called git.sr.ht/~adnano/go-gemini that is pretty much for Gemini what net/http in Go's standard library is for HTTP (but with a slightly better interface for the handlers).
Assembly, obviously
Go is great!
lisp?
Small Web is not a good description of the problem space. It can mean any of
🐦 wasolili [...] · Nov 15 at 05:26:
shell scripting feels the most "small web" to me in a vague vibes sort of way. But I don't think I really follow the idea of a "small web programming language."
🦋 CarloMonte · Nov 15 at 08:13:
I wouldn't dismiss Go on ideologic grounds. Go is the last large project of the Unix founding fathers and associates (Thompson, Pike and Kernighan plus Cox and Griesemer) and it shows.
They put in features that you will be hard pressed to find elsewhere. The language is very stable; you can pick up your project where you left one year later. It is statically linked: easy to distribute and install. It cross-compiles on all major platforms and plan9, too. Concurrency support is magnificent.
Of course it has its little problems. I don't like the "snapshot" profiling method. There are small inconsistencies on how the builtins are implemented. The current team drifts into featuritis.
But Go is really bees knees.
🎵 alice-sur-le-nuage [OP] · Nov 15 at 08:33:
@stack It's more of a feeling... Something that feels right, y'know ?
🎵 alice-sur-le-nuage [OP] · Nov 15 at 08:36:
People are making a good case for Go. If Google pulled the plug, would it live on ? How strong is Google's influence on the direction of the project ?
Google's infrastructure relies heavily on Go and the Go core team is mostly Google employees, so they have a solid influence. However, I think Google's interests (efficiency, scalability, and simplicity) are aligned with our interests.
Go has a really strong open source community and I think if Google were to abandon Go the probability of this community or a different organization maintaining it would be really high. Too much important software runs on Go for it to be abandoned.
@HanzBrix
Google sucks. However from the page you linked:
See … the go command documentation for configuration details including how to disable the use of these servers or use different ones.
So I don’t think it’s really necessarily dependent on Google.
🦋 CarloMonte · Nov 15 at 11:44:
I forgot to add: Go has a strong standard library. You can go quite a long way without using any dependencies. This is a different system than Java or Python.
🎵 alice-sur-le-nuage [OP] · Nov 15 at 14:52:
Since no one has mentioned it yet: what do people think about Nim ? I know it exists, looks interesting at first sight - but I've not looked into it more than that. https://nim-lang.org/
I've never used nim but the comment system on my gemlog, nimlikes, works well.
Yeah I am confused about that too. You don't compile *to* C, you compile C to a binary...
Compiling to JavaScript is cool though, although not very useful for the small web.
Zig and Hare are the kind of language you should have a look at.
looking at the tutorial, Nim's structure really reminds me of Pascal/Delphi with the variable blocks at the top.
Transpiling is quite common thing to do now a days, mostly to JavaScript. Translate + Compiling = Transpiling.
While C is human readable and usualy compiled, it is still a virtual machine.
I remember that there was one Pascal implementation that transpiled to C so it could be used on many different systems.
As I am writing this, I remember that many older C compiler transpiles to Asm befrore assembeling to machinecode.
i would like to thank everyone who suggested go.
permacomputing/smallweb related features are low memory footprint of executables, power efficiency, small syntax, fast on weak hardware. go compiler is easy to compile. it takes 2 minutes to compile it withoit libraries.
on tje contrary rust is impossible to compile on 32bit machine, it gets out of memory space limit, it is no more possible to compile it on pinebook, even if it runs 64bit os and zram is enabled. still not enough memory to build it.
now on go and google.
to me go is first of all rob pike. someone who worked on plan9 and inferno, someone who appreciates oberon, someone who knows there are modern ideas neglected in industry.
so rob pike works in google and it so happened he was able to convince goog;e to finance go development.
so for me go is a language created by scientists, not commerce.
still if not google it woulld not be knoen\or widely used. if rob pike designed the language without having anything in common with google, it is very possible that it would me noy more known or uded than rlm ot nim or limbo or oberon ot modula-3. that is why go is google. if go wasnt google we would not even discuss it as an option.
which brings me here:
tjere are very good but marginalized technologies.
for small web you dont need a language which has a corporate money and marketing\and you dont have a deadline for ypur prpject so you dont need a language which has lots of libraries and therefore will save ypu time.
if anythimg so,eone interested in small web might even be motivated by lack og libraries because it is possible to write some.
go is very mich influenced by oberon. and speakimg of transpilers, vishap oberon compiler is very portable because it compiles to c.
why not try to use oberon, the language tjat heavily inspired go but remained in academic walls and never was popular in industry.
voc compiles itslelf in 20 seconds.
other academic, wirthian langage is modula-2. it is now also part of gcc. ots iso standard has oop.
modula-3 though was born in industry, is designed by good computernscientists and has everything contemporary programmer wants: generics, exceptions, parallelism.
there is an own ui toolkit written in m3, called trestle. it is very lightweight.
still fpc is easier to start with. though object pascal was shaped bu co,merce, pascal syntax is not big, it is safe, power efficient, memory efficient.
once written prpgram can be compiled with fpc gor linix or macos or windpws or even amiga\and amigaos or morphos.
is c smallweb? c is small language.efficient but unsafe. not modern.
oh i started to not see well, and on pinephone i just didnt see all those typos i made. i'll try to edit every comment i made in this and perhaps other threads.
i have been written in this thread more about c, fpc, and which languages/compilers are more suitable for permacomputing, i how view those:
— bbs.geminispace.org/s/permacomputing/19024
Go losing Google's support is a valid concern, but let's not forget that even "old" languages like C are backed by large corporations (GCC by Red Hat, LLVM by Apple). However, Go looks relatively 'forkable' compared to languages like Rust, and organizations like CNCF (the branch cloud providers are sitting on) are deeply invested in Go.
so i also wanted to link this
— assessing energy efficiency of programming languages.
i thought i already published it but didn't find. anyway you already found it.
I have been programming Go professionally for some time now (5+ years) and I like it. It is a simple language with a split set of basic packages for all daily tasks.
But Go has one downside, which IMHO does not align with the "smol" philosophy: The compiled binary size is huge. All (ok most of the) dependencies are baked into the binary. This makes porting to other (bigger) platforms easier, but do not use the libs already installed on the system (Linux philosophy). This also makes it extremely difficult to code for embedded and small devices.
🚀 ahappydeath [mod] · Nov 16 at 17:23:
No one else has mentioned Elixir, so I will. It's not sponsored by any big corportations, and it has a vibrant community. What makes is even better for smol web is that the standard library has everything you'd need to build with very, very few dependencies. And it can be packaged up into a portable release. It's my favorite language and ecosystem by far.
I'll second Elixir. It's easy to grok, has nice features for making services and is robust and fault tolerant.
I'd also suggest using tcl. Its all about text processing, has both native SQLite and Metakit support built in so you have your DB support for data and sessions.
Elixir has much more advanced tooling and abstractions and has better documentation
I started diving into the elixir documentation and it does seem good, to me at least. Also found a good intro video. It's caught my interest so I might keep this rabbit hole. thanks.
@ahappydeath - for a portable Elixir release, are you referencing Burrito? I can't find another way to have a simple binary for a CGI app to execute, which would be a non-starter for here. Otherwise, I have wanted to try out a full fledged functional programming language and elixir seems fun.
My capsule is served using Dart ... the other Google language :) which I always recommend, I like it a lot.
🦋 CarloMonte · Nov 18 at 09:02:
Here is fragmentation at work. We have a dozen options; most not mature because they lack traction and we appear not to be able to create real traction anymore.
Now the user wants a stable option, so back to the not-so-fresh options of yesteryear. This state of affairs is pretty sad. Java, Python, C and Javascript forever.
🦋 CarloMonte · Nov 18 at 10:24:
@HanzBrix I beg to disagree. My perceived (it might not be objective) current level of fragmentation is not inherent to FOSS. Do you remember yesteryears, when Perl, Python then Ruby, Go and even Erlang and R emerged? Everyone was after the hot new language. Now we have 10 and cannot decide. My secret hope is that one candidate will win if not popularity at least a long term perspective. It can be Go, Rust or something else. Sadly, I am not sure if Hare, Zig, Nim or Julia will still be developed in 10 years from now.
Same for editors: we are stuck with Vim, Vi or Emacs. Helix, Sam and Sublime have cleaner interfaces but they fail to displace the older ones.
🎵 alice-sur-le-nuage [OP] · Nov 18 at 14:48:
Well this has been a fascinating thread (which is now getting more and more off topic!), thanks to everyone who contributed.
There is one language that comes out as clear favourite amongst the devs here, which is Go - despite the concerns some have over the fact it is controlled by Google. Elixir has some support as well.
Where does that leave me (the OP) ? Well the language that's most caught my attention was mentioned by one person only: it's Zig. Quite low level, not safe, but not as low level as C. Typing precludes null pointers, and while memory allocation is managed manually, defer, errdefer and the way allocators work make it a lot safer than C. I like how memory allocation works on paper - passing allocators as parameter enables patterns such as the ArenaAllocator - will have to see how I like it in practice.
It's very fast, and the memory management makes it ideal for small/embeded devices (not that this is my use case). I read binary size can be large however. The project itself is maintained by the ZSF foundation, whose president and lead developer has values I can totally align with. They're not going to sell out for profit. That doesn't mean the project is free from corporate interests, since it runs on LLVM which is strongly supported by Apple.
So for now I'm going to play around with Zig and see how I like it in practice. I may or may not stick with it !
As I'm the one who mentioned Nim I thought I should report on that too: I've looked into it a bit, and it's got features I don't like (for example function overloading) so while it looks interesting overall, I won't be using that.
Thanks again everyone for your input !
I am a bit torn between Python and Go. I currently port my personal knowledge management system to Go+Sqlite+Gemini (based on pocketbase.io). It runs fine on a Raspberry Pi Zero2 and requires only a lowend desktop machine. On the other hand, for one-off automation tasks, Python has even less syntax and fewer punctuation, which I highly value for readability.
Maybe Nim would be a good compromise between the two, but I don‘t have experience with it yet.
f008600 thank you for sharing that thought.
i too think so, but given the simplicity of the language and fast compilation speed of the compiler, and many other mainstream alternatives being horrible, i think go is the way to go, if one chooses from mainstream.
otherwise - pascal as in fpc has very good memory manager, and the resulting statically linked executable that has no connection with libc (unless u want to) since all low level libraries use kernel calls is very small, 50kb or something like that. i remember whan it was 20kb. well the resulting size depends on if you used smart linking (freepascal invention) or not.
my criticism of go would be the package manager, but every 'modern' language to this or that extent shares the problem.
my concerns are security related: it happens that when you build the go code, the build fails, and you realize it failed because go wasnt able to download one of the dependencies. you enter that domain in the browser and you see the page that domain is on sale.
so you think: luckily nobody bought this domain nd setup a repo with same interface but malicious content. then you realize you dont know if other repos pou already downloaded from weren't malicious.
you would be able to check code of deps one by one if go gave you list of deps before downloading.
it's hard, but in theory you could do that. so my recommendation would be to always try to stick to standard libraries, to not add a dependency because you just need a simple function from it, to try to use go/python/js/etc dependencies that are packaged for your distribution. packaging process is sort of institutionalized so different people and programs have to take a look at the code and it is more probable that malicious code won't reach distribution repositories.
@norayr If you want to be extra safe against disappearance of your dependencies, just use go mod vendor and push the vendor directory to your VCS (same thing you'd do in other languages).
Forcing version of dependencies by cryptographic hashes can do; in addition to protecting against malicious changes, it would potentially allow to find the same file elsewhere. (I still think that it is better to not have too many dependencies, though. Some programs might not have any, and for some, the dependencies can be included with the program.)
Another issue that I had seen with Go is how ASN.1 object identifiers are handled. You shouldn't need to decode object identifiers in order to compare them (although decoding can be useful for display, or for converting to text); decoding them is an unnecessary step for most purposes. The fact that it insists on doing so sometimes causes problems. (If you merely want to validate them (which is also usually unnecessary), you can use a regular expression: /^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/)
(It does not normally need to be implemented as a regular expression; you can also just use a simple loop that does the same thing as the regular expression.)
Lua is small. I just downloaded it and it compiled in about 2 seconds.
https://www.lua.org/about.html
@norayr: Good point, but for that, the go.sum file will contain checksums for all the used dependencies. So it is not possible to "sneak in" some malicious code. You need to be careful when updating dependencies, tho.
But you are right, using less dependencies and stick to the standard lib is in any case better. Just look at the mess in the javascript/npm/yarn/bun/... ecosystem. Every external used source need to be maintained too (do updates, adjust your code to the new API, find alternatives when a project gets abandoned, check for security problems, ...).
My biggest concern with Go, related to security, is the static compilation. As an example: curl, wget, ssh, and countless other tools are dynamically linked against libssl. If there is a security issue inside the SSL implementation, all hands are on deck to fix libssl, updates are provided, notifications pop up and after the next "apt-get update", all tools are safe.
For a statically linked Go binary, sitting somewhere in a container, cranking along, nobody cares. You are in charge of monitor for security issues, update dependencies, recompile your code, deploy it, ...
no no, i am not at all worried about it. i was saying that though i consider go to be the best among mainstream languages, all of them share more or less one security problem, not only go - and that is dependency management.
most of them do not allow to review the dependencies prior to building, let's say how apt or emerge does, they just startt downloading tons of stuff.
that is done by rust's cargo, js's npm, etc.
and go mitigated the problem now - it is possible to import not just by url but by exact git commit with its hash, and when the import mentions the hash, then it is much safer, or maybe very safe.
just go, of course does not require it. it allows it.
@dimkr i need to learn to mention people here on bubble. so yes, that was a reply to your comment.
and again, i think the language go is so good as language, that it doesn't make sense to use most of the alternatives. there can be special needs and tast like taste for lisp metaprogramming but otherwise go suits most of needs of most programmers.
and where it doesn't, i think it could, it is a compiler issue, not a language issue.
static linking mentioned by @f008600 is an example of that - the same language could have different compiler and different linking policy.
oberon is a language go borrowed lots of ideas from, and it is used in embedded world. there are different types of machinery and even aircraft with an operating system written in oberon and control software written in oberon.
oberon is more 'dry' if it makes sense, and i like it.
both compilers are small, go, the compiler part is easy to build.
and it generates native code, how bad can native code be? it almost always will be faster and always will take more memory than interpreted language.
It sounds like you might enjoy reproducible-builds.org ... and for go: go.dev/blog/rebuild
Secure builds is an important topic :)
@f008600 i have been written that go compiler can generate small binaries, and apparently there is
I've tried TinyGo last year and sadly it was not nearly usable. Some hardware was supported, but lacking essential features. For example, there was no way to use the WiFi stack on an ESP32, so it is essentially useless. But maybe this has changed. Will have a second look at it!
🚀 ahappydeath [mod] · Nov 22 at 00:19:
Burrito is one way to package, but I was referring to Mix releases. When building a mix release, you can include the erlang runtime with it and it is somewhat portable (on a machine with the same architecture)