Forget the hype, these are 3 languages that existed 30 years ago and will still exist in 30 years: C, SQL, POSIX sh. If you are learning software engineering, knowing these will help in so many ways and will make you stand out of the crowd.
@vikingkong I love Common Lisp, but learning it is useless for the vast majority of developers out there. Worse than useless actually: it will make you hate almost everything that is currently popular in the tech industry.
@louis LLVM is the perfect example of what happens when you ignore the law of diminishing returns. Yes, it is one of the best compiler/optimizer on the market. Yes it does crazy things. But I would be much happier with a compiler 80% as fast but 10x smaller and simpler.
@louis I have not heard of anyone referring to SUS in any context for more than 10 years. POSIX 2018 (i.e. POSIX.1-2017, do not ask) is currently the theoretical reference to be portable on Unix-like systems.
Of course no one bothers getting POSIX certified nowadays, so as usual test and add workarounds as needed.
In #Go, you cannot call the String method on a literal URL struct ("cannot call pointer method String on url.URL") because the String method has a pointer receiver. String does not modify the object, but it uses a pointer receiver to avoid copying the object for each call.
This is what you get when 1/ you design a language with pointers (why would you do that in 2009?) and 2/ you do not have "const".
@holgerschurig And yet I use C libraries just fine in Common Lisp, a language which does not use pointers as a language mechanism. No intermediate C. A pointer is just an address, as long as your language has integers and the necessary primitives to call C code, you can use C libraries directly. Ruby FFI does the same thing.
Modern Common Lisp implementations also have typed foreign types, this is not the wild west ;) Pointers are not "emulated", I honestly have no idea what you imagine. There are a lot of issues with Common Lisp, and I'm the first one to complain about them, but working with C libraries has always been very comfortable compared to what it is in Ruby, Erlang, or even Go (well, CGo).
I do not frown on pointers in general (I wrote way too much C professionally for that), but they do not make sense in Go: there is a GC and pointer arithmetic is not available! There is nothing useful you can do with them, and they cause so many headaches.
Because I deleted (not edited) some of my answers on Stack Overflow (7 in total) during the last two days, my account is now locked because I "defaced" the community.
They seem to be really desperate. But with their decision to sell their data to OpenAI, they sealed their own fate.
@louis Everyone knew what would happen after Stack Exchange was sold to a private equity conglomerate. Founders made their money (good for them!) and are out. At the end of day it is yet another company exploiting users for data. Nothing new and no real future.
> Can't quite get it why anyone would still volunteer their time as a moderator to this company, err, "community".
It's funny because reading the beginning of your message, this is what I immediately thought. Same thing with Reddit moderators. Companies have been doing a very good job at convincing people that they were providing free services out of the goodness of their heart. Hopefully users will learn from this.
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.
@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…).
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.
I was playing again with my #CommonLisp 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.
@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.