regex-benchmark

gn (worse for throughput, but lighter runtime). * Fun type system that is superficially "everything is a string" (like sh) but in reality "everything is a tagged union with on-the-fly conversion when needed and a guaranteed string representation". Allows for transparent serialization (`puts $mydict stdout` <=> `set mydict [read stdin]`), like CL's read/write. * Powerful introspection through `info` (mainly). Allows for stuff like getting the name/body/arglist of a procedure, get all the registered procedures, know if a variable exists, get information on the stack frames and their content, etc... Together with `trace`, you can even write an internal debugger in few lines. * Procedure arguments are passed by pointer with a copy-on-write system: don't modify the argument and you don't get any memory copy. To you, it just looks like regular passing by value. * Modifying the procedure arguments is done via `upvar`: in Tcl, a variable reference is just a name (string) attached to a relative stack frame number, quite elegant considering the language's core concepts. * If you use at least the builtin extensions (thread, http, tdbc, tcltest, msgcat) and the very basic tcllib/tclX/tclUdp/tklib packages, you're almost set for life. Personally, I also recomment the very convenient tclreadline, tdom, pipethread, tablelist and tclcurl. * Channels is one of the cleanest I/O implementation I've ever used with some cool features: - Transformations allowing filters like deflate/zlib/gzip or TLS to be put on a channel (see `transchan` for the API). - Reflected aka virtual channels, to make your own channels. Basically like glibc/BSD's unportable fopencookie/funopen or CL's gray streams. - Centralize a lot of ioctl/fcntl mess and even more (like defining the EOF char) in `chan blocked/configure/pending`. - Integration with the event loop via `chan event/postevent` allows for a nice callback oriented approach to sockets and pipes. - Other third-party channel types include pty (expect), random, memory or fifo (memchan). * Builtin event loop (see `after`, `vwait`, `socket -server` and `chan event`) for powerful and seamless concurrency/command scheduling. Much simpler than Python's very "AbstractBeanFactory" asyncio. * An elegant thread extension consisting of an interpreter per thread and no raw access to other thread's memory. Comes with both simple (`thread::send/broadcast/transfer`) and performant (`tsv`) synchronization/communication facilities. * Finally a sane, light and portable (even more with Tile) GUI toolkit: Tk. * One of the fastest Unicode aware regex implementations, written by Henry Spencer himself. Has its own greater-than-POSIX-ERE syntax called ARE, not as complete as PCRE (lacking lookbehind constraints, most importantly), but still great for an hybrid NFA/DFA engine. Performance comparison with Perl: https://github.com/mariomka/regex-benchmark/pull/44. * `uplevel` (eval a script in a different stack frame) and `tailcall` (replace the current procedure with another command) let you augment the language by implementing control structures and keywords yourself. Inferior to CL's synergy between unhygienic macros, "naked AST" style homoiconicity, symbols as first-class objects, gensym and quasi-quoting, but still quite powerful. * Safe interpreters let you do very fun things like config files in Tcl with limited access to the machine and master interpreter. * Recent versions (>= 8.5) really embraced FP with: - Real lambdas (but not closures, these have to be emulated) through apply. - Purer hash maps (dict) than ugly sticking-out-like-a-sore-thumb arrays. - Lisp style prefix arithmetic (allowing for `* 3 [+ 1 2]` instead of `expr {3 * (1 + 2)}`) including sane behaviour for more than two (reduce) or zero (neutral element) arguments. - Builtin map/filter (lmap) with 8.6. See https://wiki.tcl-lang.org/page/Functional+Programming for more. * Multiple more-or-less powerful OO systems (now based on the builtin TclOO): [incr Tcl] for C++ style OO, XoTcl for a take on CLOS or Snit for something Tk oriented. * Some massive issues on the top of my head: lacking a LSP/SLIME equivalent, the warts of the weird type system (no way to differentiate between atoms and single element lists or evenly sized lists and dicts), missing metaprogramming facilities like quasi-quoting, no official support for UDP and UNIX domain sockets, no GC for class instances (cf https://core.tcl-lang.org/tips/doc/trunk/tip/550.md), no FFI in core, subtly broken exec (cf https://core.tcl-lang.org/tips/doc/trunk/tip/424.md and https://core.tcl-lang.org/tips/doc/trunk/tip/259.md) Here are some project I made with it, still worth using compared to CL which is my true love, simply because its stdlib is better suited for a lot of tasks: https://git.sr.ht/~q3cpma/mangadex-tools https://git.sr.ht/~q3cpma/rymscrap https://git.sr.ht/~q3cpma/lemonbar-tcl https://git.sr.ht/~q3cpma/tcl-misc

because the reference may become stale, but Rust can enforce this with lifetimes. * Let you clone a map without rehashing every key to a new seed. I generally measure at least 15x speedup from this alone, unlocking very useful design patterns like "clone a map and apply a few temporary updates for a one-off operation like validation or simulation" with no extra code complexity. Go gives you no better option than slowly rehashing the entire map. And that's just hash maps. How about Go's regex engine being one of the slowest in the world while Rust's regex crate being one of the fastest: https://github.com/mariomka/regex-benchmark#optimized https://github.com/BurntSushi/rebar#summary-of-search-time-b... Further, Go refusing to have macros means that many libraries use reflection instead, which often makes those parts of the Go program perform no better than Python and in some cases worse. Rust can just generate all of that at compile time with macros, and optimize them with LLVM like any other code. Some Go libraries go to enormous lengths to reduce reflection overhead, but that's hard to justify for most things, and hard to maintain even once done. The legendary https://github.com/segmentio/encoding seems to be abandoned now and progress on Go JSON in general seems to have died with https://github.com/go-json-experiment/json . Remember that next time someone parrots the myth that Go is ideal for HTTP JSON APIs. Many people claiming their projects are IO-bound are just assuming that's the case because most of the time is spent in their input reader. If they actually measured they'd see it's not even saturating a 100Mbps link, let alone 1-100Gbps, so by definition it is not IO-bound. Even if they didn't need more throughput than that, they still could have put those cycles to better use or at worst saved energy. Isn't that what people like to say about Go vs Python, that Go saves energy? Sure, but it still burns a lot more energy than it would if it had macros. Maybe someone's recipe website doesn't care but world-scale datacenter applications do. Rust can use state-of-the-art memory allocators like mimalloc, while Go is still stuck on an old fork of tcmalloc, and not just tcmalloc in its original C, but transpiled to Go so it optimizes much less than LLVM would optimize it. (Many people benchmarking them forget to even try substitute allocators in Rust, so they're actually underestimating just how much faster Rust is) Oh yeah, aside, tcmalloc was designed for C++ code with lots of temporary allocations that are allocated & freed by the same thread so they're very cheap when cached per thread/core. Go almost always frees things on a separate GC thread, completely undermining this design goal. So tcmalloc isn't even a good fit for Go, yet there's no other choice available. People don't even discuss it any more because what is there to discuss, Go and all of its users are just stuck with it. Finally, even Go Generics have failed to improve performance, and in many cases can make it unimaginably worse through -- I kid you not -- global lock contention hidden behind innocent type assertion syntax: https://planetscale.com/blog/generics-can-make-your-go-code-... It's not even close. There are many reasons Go is a lot slower than Rust and many of them are likely to remain forever. Most of them have not seen meaningful progress in a decade or more, and I'm not holding my breath for the next decade either.

e any implementation fast or slow. You can have a well performing search engine in go and JS. The performance difference will most likely not be caused by the language with these two choices. And the same will apply with C/Rust. The language won't make the engine performant and creating a maximally performant search engine is hard. But a theoretically perfect implementation would likely be fastest in C/Rust, followed by the usual suspects such as Go/Java/C#/JS and finally ending with all other interpreted languages such as ruby and python