@galdor@emacs.ch
@galdor@emacs.ch avatar

galdor

@galdor@emacs.ch

Contrarian software engineer. Hire me to solve your technical problems.

$argon2id$v=19$m=64,t=512,p=2$0rwNagYG9nw58bd3D5HBfw$ZDMVWlX+adPhtQKcnrqI5A

This profile is from a federated server and may be incomplete. Browse more on the original instance.

louis, to random

Exciting news for SBCL users. A coroutine proof-of-concept was created during ELS after-hours in a pub :-) I for once hope, what happened in Vienna, doesn't stay in Vienna.

galdor,
@galdor@emacs.ch avatar

@louis I hope it means green threads (let me dream).

galdor, (edited )
@galdor@emacs.ch avatar

@louis From a quick check in CCL documentation, it used to have cooperative userland multithreading and switched to OS threads in 0.14.

The thing is, naïve cooperative multithreading (i.e. Stackless Python or what some Scheme implementations do with continuations) is pretty much useless without a runtime able to deal with IO (global IO handler with epoll/kqueue, yield on all IO ops and resume on IO events), which is tricky because none of this is defined in the Common Lisp standard.

Also this is 2024, if your green threads cannot be dispatched on multiple cores (as in Go or Erlang), the benefits are more than limited.

Doing all of this really efficiently is a very hard problem, especially if you are a native compiler (now you have potentially millions of green threads, each with a tiny stack, then suddenly you make FFI calls and the C code is convinced you have your 4+MiB of stack…).

amoroso, to Lisp
@amoroso@fosstodon.org avatar

Are you going to European Lisp Symposium 2024?

I have a favor to ask you. Please tell the Lispers there if any of them writes a Common Lisp book I'll be more than happy to buy it, back a kickstarter, spread the voice, and support the author any way I can.

This is just one data point but my hunch is many Lispers are like me.

galdor,
@galdor@emacs.ch avatar

@amoroso What would you like to see in a new Common Lisp book?

galdor, to random
@galdor@emacs.ch avatar

I had some fun: went through chapter 2 (Syntax) of the standard and bootstrapped a reader. I learned a few things:

  • Pure C99 is (still) easy to read and to write.
  • The standard is very well written: just do what is described and it works.
  • If you did not read the standard, there are a lot of things you do not know about Common Lisp.

Now I need minimal support for arbitrary-precision arithmetic, and I do not want any dependency.

galdor, to random
@galdor@emacs.ch avatar

I was playing again with my HTTP implementation and I've made my peace with its blocking nature. It is irrelevant with a buffering reverse proxy (HAProxy or NGINX), performances are excellent and the code of the server stays simple.

Here, 210k+ req/s on 64 connection handling threads with 390µs P90 latency and sub-ms P99 (Linux amd64, SBCL 2.4.1).

Of course I can't use the same approach for my SMTP server (too many parallel connections that stay alive and no buffering proxy possible), but not all software have to use the same language.

galdor, (edited )
@galdor@emacs.ch avatar

@louis No, there are 64 threads handling connections, i.e. reading requests and writing responses. However these read and write operations are blocking, meaning that they only return once data have been read/written. Without buffering, if a client opens 64 connections and does not send anything, the server will lose the ability to process requests.

With a buffering reverse proxy, e.g. NGINX, the proxy manages connections in a non-blocking way (usually with epoll or kueue), without requiring one thread per connection, and accumulates requests until they are complete, then only forward them to the real server. No risk of blocking. Of course in theory I could write the HTTP server in a non-blocking way in Common Lisp, but then we're back to the lack of green threads, callback hell, etc.

louis, to random

Or, we could just build our own Mastodon client with Common Lisp.

Took me less time to build this with than desparately trying to fetch that data in the Web UI.

Who knows what this will morph into. :p

galdor,
@galdor@emacs.ch avatar

@louis I remember reading that the problem with Mastodon was the protocol that makes it impossible to be efficient. Do you concur?

galdor,
@galdor@emacs.ch avatar

@louis @screwtape Curious to see the result indeed, thanks for the explanations.

galdor, to random
@galdor@emacs.ch avatar

I love SQLite, but everytime I see someone claiming you do not need PostgreSQL, I feel the need to remind them that SQLite has very limited type handling and that you'll seriously miss row locking as soon as you want HA. And it's just the tip of the iceberg.

galdor,
@galdor@emacs.ch avatar

@loke My point is that every debate on the subject is focused on performances, which is mostly irrelevant unless you have a ton of concurrent writes.

What people do not realize is how many features SQLite is missing compared to PostgreSQL. And do not get me started on the brain dead idea of allowing NULL primary keys…

galdor, to random
@galdor@emacs.ch avatar

Some say you must start with a simple programming language and learn your way up. Others tell you to learn a low level language such as C to understand how everything works.

I've seen plenty of developers who started with Python or JS, and some who started with C. Comparing them, there is no doubt about which method yields the best developers.

The good news is that it's never too late to go back to the fundamentals.

louis, to openSUSE

Two full months into Pop_OS now. While genereally happy, I struggle a bit with the system getting slower and slower over time, I need to reboot every 2-3 days to get back to normal. Resource monitors shows no havoc procresses and no excessive memory usage.

For some other reasons I installed openSUSE Tumbleweed in a VM with KDE 6 and now find it very tempting to switch. It was super fast and KDE seems just so much better at this point.

Switching distro is a huge PITA, so if you have any arguments against it, I would appreciate that before I go down that road 🙂

galdor,
@galdor@emacs.ch avatar

@louis I have been using Archlinux for so long I do not remember using anything else for my workstation or my laptop (still use FreeBSD for my servers and Ubuntu LTS for production professional work because it’s the path of least resistance despite being a shitty distribution).

I have neither the time nor the interest in tinkering with my OS (I had my Gentoo phase a long time ago thank you very much), so a distribution with up-to-date packages and very little opinions (I’m looking at you Debian) suits me perfectly.

Also, yes, Gnome and KDE are self inflicted pains, using i3 or equivalent is a game changer.

galdor, to random
@galdor@emacs.ch avatar

Firefox tip of the day: create/update "userChrome.css" in the "chrome" subdirectory of your profile directory and add:

moz-input-box.urlbar-input-box {
font-family: monospace !important;
}

Do not forget to set "toolkit.legacyUserProfileCustomizations.stylesheets" to "true" in "about:config" (blame Mozilla for this BS).

Because yes, URIs should be readable in your browser.

louis, to random

While most programming languages pride themselves in how they limit the programmer, there is one that does quite the opposite. One, that rewards you with every day you spend, every struggle you overcome with a new box of undiscovered tools. And when there are no more, you have all the tools you need to build your own.

You all know which one I'm talking about.

galdor,
@galdor@emacs.ch avatar

@louis I am starting to wonder which one of us is going to go crazy and start writing an implementation ;)

galdor, to emacs
@galdor@emacs.ch avatar

The value of is not in the packages that are available (Gnus, org-mode, Magit, etc.). It is the fact that these packages live in the same application, manipulate text the same way, and can interact with each other to do exactly what you want them to do.

galdor,
@galdor@emacs.ch avatar

@holgerschurig @dougbeney

> How would one discover that, except by doing programming language archeology?

Like everyone, by reading the documentation: https://www.gnu.org/software/emacs/manual/html_node/eintr/index.html

There is a lot of problems with Emacs Lisp, but at least it has documentation. And taking Python as an example is hilarious given how shitty the language and its ecosystem are.

galdor, to random
@galdor@emacs.ch avatar

There is a fundamental misconception about how software licenses and copyright work. Since Redis Labs relicensed Redis, I've read multiple times that it would not have happened if Redis had been GPL-licensed. This is incorrect. The entity (or entities if they all agree when there are multiple copyright holders) owning the software, company or individual, can relicense it at any time, and no license can change that.

Using the GPL license would also not have prevented Amazon from making money by hosting Redis (nothing wrong with that btw). Making it AGPL would have forced them to release any modification, but then again if it was AGPL, lots of companies would not have touch it (for good reasons).

There is absolutely nothing stopping anyone from forking the last BSD-licensed release of Redis and continuing the work with another name ("Redis" is a trademark that belongs to Redis Labs).

louis, to random

Call me old school (or just old) but I hate to see that more and more corporations switch to the informal German "Du" ("thou") and dismiss the more respectful "Sie".

I know in English "thou" is no longer common, but in German the distinction between Du and Sie is pretty much alive and we use it all the time between adults that don't know each other, especially in a business relationship. Usually the older or higher-ranked person is in the position to offer switching to "Du".

In Switzerland it is a bit more relaxed (within most companies all are using "Du" no matter which rank), but the rules still apply to people unknown to each other.

How is that working in your country?

galdor,
@galdor@emacs.ch avatar

@louis Same problem in France, lots of companies abandoned the respectful "vous" and abuse the casual/informal "tu" both internally and in their communication with clients/users.

In the past, I have been in multiple job interviews where a manager I've never met before started immediately using "tu" in a very casual way. Of course when that happens, I immediately do the same; always fun to observe their reaction.

louis, to random

Is it just me or is code using the advanced LOOP macro horrible to debug / step through...?

galdor,
@galdor@emacs.ch avatar

@louis LOOP is a terrible macro. People like it because it can be shorter than the equivalent DO form, but it is a very non-lispy form that makes it really hard to understand what is really going on.

Of course everytimes I say that, I get all kinds of people attacking me because "muh LOOP is just fine", but hey this is the Internet :)

galdor,
@galdor@emacs.ch avatar

@louis @pkw

By someone much more reputed than me: https://www.paulgraham.com/loop.html

As for iterate, I still do not see the point of pulling an external library when DO & co do the job perfectly. Developers will go through extreme lengths just to avoid writing a bit more of code, even though the slightly longer code is so much simple (something Go got right, at least).

galdor, to random
@galdor@emacs.ch avatar

I've seen too many managers complain about engineers being "difficult" for being exigent about work environment and tools. Developers are not machines, and their tools are important to them even if you do not understand why.

(source: @dhh in https://world.hey.com/dhh/finding-the-last-editor-dae701cc)

galdor,
@galdor@emacs.ch avatar

@louis It's too soon to tell, but I do not expect things to change that much.

Companies mass producing shitty corporate software or run-of-the-mill websites will use and abuse AI code generation the same way they current subcontract (with or without offshore teams). Quality does not matter to them, it's all about cheap and fast.

Companies treating software as an asset will continue hiring as they currently do; AI may be used as a tool (or not, given the obvious liability; time will tell), but will not replace engineers because they work is not just about puking code everywhere.

galdor, to random
@galdor@emacs.ch avatar

REST does not make any sense for HTTP APIs. A request is just data: encode it in the request, use the request path as the name of the operation you are performing, the end. Same thing for responses. Forget about nested routes, query strings, path variables… They just make your life more complicated and do not bring anything to the table.

I've been using this model for multiple HTTP APIs and I only regret I did not realize that sooner. BTW I'm not alone, see the AWS API or the Telegram one.

Also makes writing API clients magnitude order easier.

galdor,
@galdor@emacs.ch avatar

@louis @bonifartius @Sophistifunk
API caching at the HTTP layer is a mine field and usually best handled in the application layer. But if you have good reasons to use HTTP caching, nothing is stopping you from accepting both GET and POST for all routes. I do it for convenience.

galdor, to emacs
@galdor@emacs.ch avatar

I find it hilarious that people perceive Firefox as a bastion of freedom when it makes it impossible to install add-ons which have not been signed by Mozilla. You cannot add new signing keys. You cannot event install your own unsigned add-on on your own Firefox instance on your own computer.

Imagine if did not let you install a package if it was not signed by the FSF…

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • normalnudes
  • kavyap
  • DreamBathrooms
  • hgfsjryuu7
  • magazineikmin
  • thenastyranch
  • vwfavf
  • ethstaker
  • Youngstown
  • slotface
  • rosin
  • Durango
  • mdbf
  • PowerRangers
  • anitta
  • everett
  • InstantRegret
  • tacticalgear
  • osvaldo12
  • modclub
  • cubers
  • GTA5RPClips
  • ngwrru68w68
  • khanakhh
  • Leos
  • tester
  • cisconetworking
  • provamag3
  • All magazines
    •