💾 Archived View for bbs.geminispace.org › u › Morgan › 21903 captured on 2024-12-17 at 15:52:04. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "What is a good Small Web programing language ? While I like..."
My capsule is served using Dart ... the other Google language :) which I always recommend, I like it a lot.
Nov 18 · 4 weeks ago
🦋 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)
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 ?
💬 alice-sur-le-nuage · 55 comments · 1 like · Nov 14 · 5 weeks ago