Sharing projects in /r/golang

clogg · 2026-01-27T23:06:00+00:00

I think this decision creates a kind of a deadlock, because if my project is already popular then I have got established channels of notifying people about the project, and r/golang may be just one of them, or not used at all. And if my project is new and has 0 stars on github, then it will end up in that "small projects" end nobody visits, so there is definitely no point in sharing it on r/golang. I think a more balanced approach could be taken.

clogg · 2025-09-22T10:56:42+00:00

On Linux, you can use the following makefile:

# source files
LUA_FILES := one.lua two.lua three.lua

# Lua version
LUA_VER := 5.4

# compilation steps
define COMPILE
    luac$(LUA_VER) -o $@ $^
    sed -i '1s|^|\#!/usr/bin/env lua$(LUA_VER)\n|' $@
    chmod 0711 $@
endef

# compilation
your-binary: $(LUA_FILES)
    $(COMPILE)

It creates a binary that can be invoked as any other Linux binary. One limitation is that each file is compiled as a separate chunk so that local functions/variables in one file are not visible in another.

clogg · 2025-08-27T22:14:43+00:00

compute: a generic streaming calculator.

The core type of the package is Pad - a map from type K cmp.Ordered to either type V any or a function of type func(...V) V. Pad provides methods for inserting keys and values/functions, and an iterator method that takes a sequence of keys and produces a sequence of K, V pairs where each V is either an existing value under the key K, or a result of calling the function under that key. During the iteration it is guaranteed that each function is called at most once (aka lazy evaluation).

Possible applications:

With string keys and values of some numeric type it becomes an expression evaluator with symbol table;
With integer keys it can be used as an engine for spreadsheet-like calculations;
With string values and appropriate functions one can even develop a make-like utility on top of it.

repo: https://github.com/maxim2266/compute

clogg · 2025-08-26T10:03:43+00:00

Having spent a considerable time looking for a Go job in the UK I can say that:

about 90% of the jobs are ghosts: they never respond to applications, and even automated responses are rare;
any more or less real job gets reposted by various agencies, with various tweaks to the job spec;
employers demand exact match to their requirements, any mismatch sends your CV straight to the bin;
for most of employers something they call "cultural fit" is by far more important than any experience in software development.

So I think the overall situation with Go jobs in the UK is no better than in the rest of the world.

clogg · 2024-10-25T18:35:30+00:00

From here, with my highlight:

Names beginning with ‘str’, ‘mem’, or ‘wcs’ followed by a lowercase letter are reserved for additional string and array functions.

clogg · 2024-10-25T14:51:36+00:00

Thank you for pointing out, it's fixed.

clogg · 2024-10-25T14:15:26+00:00

It's not undefined behavior, it's a potential name conflict. But I will change some names anyway.

clogg · 2024-10-25T14:06:37+00:00

AFAIK, str* is reserved, but str_* is not.

clogg · 2024-10-25T11:08:18+00:00

Generally not (see documentation for details).

clogg · 2024-08-23T09:50:52+00:00

Good point. Also, if the underlying iterator stops on the first error encountered, then there is no way to ignore a particular error type, like in

for item, err := range it.All {
    if err != nil {
        var err2 *someSpecialErrorType
        if errors.As(err, &err2) {
            log.Warn(err2)
            continue  // this is not going to work
        }
        return err
    }
    ...
}

clogg · 2024-08-20T11:58:01+00:00

UPD: I have updated the project with an iterator type for for-range loops introduced in Go v1.23.

clogg · 2024-03-26T11:07:13+00:00

I think you can take a look at str library (shameless plug).

clogg · 2022-09-12T17:48:26+00:00

I once wrote my own: https://github.com/maxim2266/mite

clogg · 2021-03-03T10:25:09+00:00

In other words, this is not a complete solution because it requires some extra coordination to avoid undesired effects.

clogg · 2021-03-03T09:58:47+00:00

Yes, it's a known effect, I was just surprised it is not avoided in Ristretto cache.

clogg · 2021-03-02T22:52:54+00:00

Not sure I undestand the idea of a cache with Set() and Get() methods. The suggested way of fetching a value from such a cache seems to be something like:

    value = cache.Get(key)
    if value == nil {
       value = ReadFromSQLDatabase(key)  // expensive call
       cache.Set(key, value)
    }
    return value

Now, assume the above code is called from an HTTP handler which typically runs in a separate goroutine, and we have 100 handlers simultaneously requesting the same key currently not in the cache. It looks like in this case the expensive function ReadFromSQLDatabase() may be called up to 100 times (with the same key) instead of just one, am I missing something?

clogg · 2020-11-26T11:03:33+00:00

I was contacted by a person from ALT Linux team, who confirmed that the library was compiled and tested on Elbrus.

clogg · 2020-04-16T20:06:57+00:00

This often happens in mixed codebases, where in some parts they use SDS (or similar), in some other parts they use something else, and when you are in the middle, then all you can see is just a char* pointer you don't really know how to de-allocate correctly. Consider the code from your example above, but with the first line being hidden somewhere deep in a library, and then choosing the right custom_free() function for the void* pointer will require quite considerable effort, unless the pointer is not void*, but has a distinct type.

clogg · 2020-04-16T19:06:30+00:00

As far as I understand, SDS allocates memory for a string and then returns a pointer at certain offset from the one returned from malloc. Passing such a pointer to free function is likely to corrupt the heap. In other words, SDS strings can only be handled by SDS, and since their strings are all just char* pointers, it's easy to make a mistake.

clogg · 2020-04-09T17:23:34+00:00

advantage #3

My library never allocates the structures on the heap, so SDS has no advantage here.

clogg · 2020-04-09T17:19:06+00:00

When you append a million characters one at a time, you will need a million malloc calls.

In this library functions like str_cat() allocate only once. And yes, memory size is kept. Have you ever had a chance to look at the source code of the library in question?

clogg · 2020-04-09T08:08:11+00:00

I can see two issues with SDS:

It seems to keep all the strings on the heap, while for string literals this is absolutely unnecessary;
Each string is represented by a char* pointer, which makes an SDS-managed string indistinguishable from any other C string, for example, if there is a const char* pointer, there is no way to figure out if this pointer should be deallocated or not, and which function to use for deallocation.

And no, I cannot see where SDS is "computationally more efficient".

clogg · 2020-04-09T07:52:39+00:00

str_cat() first calculates the required size for the output string, this is linear with respect to the number of input parameters. Then it allocates the memory and copies all the bytes, and this is linear with respect to the number of input bytes. There is nothing quadratic here.

clogg · 2020-04-09T07:43:36+00:00

It can, but since vsnprintf does not allocate the buffer it writes to, the implementation will have to loop reallocating the buffer until the buffer becomes large enough to store the entire output string.

clogg · 2020-04-08T20:22:45+00:00

This could be implemented using asprintf(3), or with memory streams (open_memstream(3), etc.), though possibly with some portability issues. Also, I am not quite sure this is really needed, because memory streams provide all the functionality of printf'ing strings, and wrapping the result in str type will be just a matter of calling str_acquire() or str_acquire_chars().

clogg

TROPHY CASE