Post B7rP2FUOhbN9hkrhui by wolf480pl@mstdn.io
(DIR) More posts by wolf480pl@mstdn.io
(DIR) Post #B7qB7ohsxF2E3qdfg8 by wolf480pl@mstdn.io
0 likes, 1 repeats
what should an stdlib include?- data structures (list, hashmap, bst tree, set, queue)- event loop (or at least an abstract interface for one)- locks, atomics- logging API- common error types- regex- cross-platform filesystem API- abstract IO stream API- json parser- compression algorithms (deflate, bzip, lzma, zstd)- implementation of tar and zip file formats- sha256- popular cryptographic primitives (AES, chacha20, RSA, ECDSA)- network sockets- DNS resolver- https client?
(DIR) Post #B7qBa1tNWcSB3yT2um by sjb@mstdn.io
0 likes, 0 repeats
@wolf480pl A stdlib for what language?
(DIR) Post #B7qE1uTmsYOq5bv4vw by icedquinn@blob.cat
0 likes, 0 repeats
@wolf480pl nothing, ideally. the language shouldn't privilege its constructs to one at all.
(DIR) Post #B7qfla4nla9StUEcYS by wolf480pl@mstdn.io
0 likes, 0 repeats
@sjba new one you designed
(DIR) Post #B7qjcL3ucU7jXQfQq8 by wolf480pl@mstdn.io
0 likes, 0 repeats
@icedquinnIt doesn't privilege them in that you could just as well implement all of that in any other library.It does privilege it in that the language spec promises that library will be there, and will have a speicific API.The reason I believe there should be an stdlib are two-fold:1/
(DIR) Post #B7qk2m2UwRrEjfbwga by wolf480pl@mstdn.io
0 likes, 0 repeats
@icedquinn1. Portability. Some of these constructs' implementations need to be platform-dependent (fs, sockets, locks), so if everyone porting the language knows to implement these, and everyone trying to write portable knows these will be present, then it's easier to write portable code.2/
(DIR) Post #B7qkJEQt8xQxQgrpJY by wolf480pl@mstdn.io
0 likes, 0 repeats
@icedquinn2. Inreroperability. Some constructs (data structures, event loop, locks, error types, abstract IO streams) are used for interfacing between two libraries, or a library and an application. If everyone uses a different, incompatible implementation of those, then every time you want to use two libraries together you'll end up writing a translation layer, eg. converting ArrayList from fancycollections to Vector from miscdatastructures3/3
(DIR) Post #B7rBNcf6LLhWIRAZWK by mburakov@mastodon.social
0 likes, 0 repeats
@wolf480pl IMO anything that manipulates entities in memory is generally useful. That is, read memory - process - write memory. If the intended area is system programming, I’d then go with super primitive io only usable for print-debugging. For any kind of “external” interactions - only provide basic (but solid) building blocks, e.g. strongly typed syscall wrappers. Engineers will figure out how to build the rest on top of that in an optimal way for their particular usecases.
(DIR) Post #B7rDwR8HOvMUaAXty4 by mburakov@mastodon.social
0 likes, 0 repeats
@wolf480pl introducing super-advanced io with async sockets and stuff is exhausting and won’t cover all the possible scenarios anyway, forcing people to resort to syscalls in some cases. So… why bother?
(DIR) Post #B7rDwRL2dTZPDkW5rM by mburakov@mastodon.social
0 likes, 0 repeats
@wolf480pl If you are thinking of higher-level language above system programming, I’d say there’s no need for a new one. The amount of already available ones is wild.
(DIR) Post #B7rDwRVfzw4pkjUaR6 by wolf480pl@mstdn.io
0 likes, 0 repeats
@mburakovI'm also thinking for criteria for picking a programming language, possibly a high level one. And I've heard many of them are trying to split things out of their stdlibs into regular packages.Also, name a good high level language :P
(DIR) Post #B7rEGf2dOhx1VnY6Ge by wolf480pl@mstdn.io
0 likes, 0 repeats
@mburakovyeah but if you ignore it, then you'll end up with 5 competing, mutually-incompatible event loops, and every library that does IO (eg. postgresql client) will need to pick one of them, and will be only usable with that one.Same with logging - if you don't have a logging framework in stdlib, every library will end up using a different one, and configuring logging program-wide will be a pain.
(DIR) Post #B7rF6PSQaEikEmHzqy by mburakov@mastodon.social
0 likes, 0 repeats
@wolf480pl or pgre client might implement a new one ;) I believe you will anyway end up in a situation like this if this hypothetical language gains some popularity. Or maybe even worse, where stdlib io has some _fatal flaw_ which surfaces in ~25% of usecases but you can’t fix it without breaking compatibility with clent code…
(DIR) Post #B7rFdrkCR3GrWUYTUu by mburakov@mastodon.social
0 likes, 0 repeats
@wolf480pl I am mostly involved in system programming, so my word here hardly counts… JS+Node? Kotlin+Android? Swift+iOS? Dart+Flutter? Depends a lot on what you up to IMO.
(DIR) Post #B7rK5YclW2ga9HXOVs by wolf480pl@mstdn.io
0 likes, 0 repeats
@mburakovA web backend with no clientside JS, for example.I could write it in Golang, but Golang is full of footguns.I could write it in Python, but then it will stop working in a year due to breaking changes in Python.Haven't tried coding in JS+Node, but AFAIK JS also has a ton of footguns, and also the code of all Node apps I've seen was very difficult to follow (only other place where I've seen this much indirection was the source code of Gradle)
(DIR) Post #B7rKiP52vw6DqJHyuO by wolf480pl@mstdn.io
0 likes, 0 repeats
@xgqtAll good suggestions.yaml/toml/ini fit in the same category as "json parser", so I'd assume if someone says "no json parser" they're against these three too.CLI parser is a good one I didn't think of.Helpers for higher order functions sound really depend on what kinda language it is, but in general "pure helper functions that support the paradigm of the programming language" sounds like something everyone would agree should be included.
(DIR) Post #B7rKoHRIFwB3siUt7Y by wolf480pl@mstdn.io
0 likes, 0 repeats
@xgqtDo you think any of the ones I metioned are excessive and should be split to an external library whose API is not mandated by the language specification?
(DIR) Post #B7rLF2yI9fK0pThANk by wolf480pl@mstdn.io
0 likes, 0 repeats
@mburakovSome languages are trying to do this (see Python, Zig).What you could do is standardize the interface between the async code and an event loop implementation and allow people to bring their own event loops, so that eg. a gtk app can use gtk's event loop and a Wayland compositor can use libwayland's event loop, but most libraries would work with any event loop.But yeah, the API is the hard part, and getting it wrong would be hard to fix.
(DIR) Post #B7rMw0Zr22iJoIJXpQ by mburakov@mastodon.social
0 likes, 0 repeats
@wolf480pl oh, for this purpose go looks like a good option (after carefully disarming the footguns). It will give you a proper stability if you care about this. If the backend functionality is not super complicated, I’d even try nginx+fcgi+c. It probably contains more footguns though :) Overall there’s a plenty of options. Go with the approach that brings you most fun. IMO this is more important than maturity of a language or completeness of its stdlib.
(DIR) Post #B7rP2FUOhbN9hkrhui by wolf480pl@mstdn.io
0 likes, 0 repeats
@mburakovYeah but I think there's still room for better high level languages.
(DIR) Post #B7rSglvboXq1l3bk7k by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@wolf480pl my perspective on this is still unchanged
(DIR) Post #B7rStm52YmIFziDej2 by p4@masto.ai
0 likes, 0 repeats
@wolf480pl one big omission from your list is text manipulation utilities: searching, splitting, removing whitespace, left pad, etc. This is the part where everyone complains about JavaScript, meanwhile I'm silently starting at ~60 different Java classes named StringUtil included from random dependencies...
(DIR) Post #B7rWBxHTxF0Bo8Oq80 by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakovI forgot what your perspective was :/
(DIR) Post #B7rWccdGpjc9aOJ55E by wolf480pl@mstdn.io
0 likes, 0 repeats
@p4Good point.But what I'm more interested in is: which things from the ones I listed would you remove? How far is too far?
(DIR) Post #B7rXLxrIlG5KRvUTia by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@wolf480pl https://mastodon.gamedev.place/@amonakov/114378379245984182RT: https://mastodon.gamedev.place/users/amonakov/statuses/114378379245984182
(DIR) Post #B7rhUkc0Nf3PVtAEqm by wolf480pl@mstdn.io
0 likes, 0 repeats
@xgqtIf by imported you mean thrown into the namespace of a file being compiled - no.If you mean being accessible to being imported by individual source files without specifying them as a dependency in buildsysten configuration - I'd say negotiable.Tree-shakable - with LTO I'd hope so, without LTO one could probably do one section per symbol, but idk how practical that is. And if instead the stdlib is dynamically linked, it doesn't matter.
(DIR) Post #B7s91v7v0PEaRW8GQK by sjb@mstdn.io
0 likes, 0 repeats
@wolf480pl If it's *new* you might want to write all that in the standard library just because there's not that much code for your language out there yet.In the case of a mature language, I'd remove anything that's likely done better by an independent project. Like there are really fast regex projects in C/C++ and it would be silly to rewrite a worse one for a standard library.
(DIR) Post #B7sAEBwSPfHE1VBdOS by wolf480pl@mstdn.io
0 likes, 0 repeats
@sjbyeah but it's a commitment - once you add something, removing it means breaking a large part of existing code written in that language
(DIR) Post #B7sArMiGIgBuisE5zs by sjb@mstdn.io
0 likes, 0 repeats
@wolf480pl Depending on the licensing conditions of the "replacement" projects. Like, you could put a BSD-licensed regex project in with just a shim to change the API names.