Right now icons indeed just add clutter.

They also make you think how could the designer depict a concept.

For example, why should "Save" button look like a diskette. What if it was Jesus, like the Christ Redeemer statue. That actually could be a funny game, like in the post, to invent icons.

But I wonder if this can be a better abstraction than async. (And whether I can build something like this in existing Rust.)

I understand this is extreme, but a good illustration. He was doing something on his own, and was charged. Such enforcement is extremely unlikely in Russia even in todays situation. For instance, a recent law explicitly banned _searching_ for extremists materials, e.g. Navalny's party website (they're labelled as extremists ex-court by the Interior or the Justice ministry, I don't remember). But there's been just 1 court case since then. You can search whatever you want as long as you're not public about it. As soon as you get enough publicity, you do get on the radar.

Same kinds of examples: in the 1950's USSR some musicians were shadow-banned (there was no legal ban on them), and not published. A man made a lathe and carved disks with their music on used x-ray films. He was arrested when he got enough publicity and sold good deal of copies. He was charged not for copying them -- there was no ban on this -- but for illicit enterpreneurship, or speculation as it was called back then. Had he been doing this alone, he'd probably have not got under arrest.

I actually, think it's roughly the same as dealing with Torrent and trackers in the Western world nowadays.

https://www.cnews.ru/news/top/2024-11-22_v_rossii_zapretili_...

Seeking extremist materials is illegal as of September. If that is not "bypassing censorship" then what is?

By the way. Extremist materials is a big list of thousands of things that no one can always know. What it means for a normal person? If you use VPN you can be finding extremist materials, if you don't = then you don't (because they are all helpfully blocked)

After 3 months there is one guy with a case for looking up Azov for example https://meduza.io/amp/cards/mvd-vpervye-popytalos-oshtrafova...

These people were on the Europe's side politically, yet they were targeted by just the passport.

I'm not saying they should be lifted, but they punished the most exactly the pro-European Russians, inside our outside.

My libertarian friends criticise this from the point that "everything state-run is inefficient". Even if this is true, they fail to notice that state-run healthcare keeps prices of the private sector down. You don't have to sell a car if you're seriously sick.

In 1992-96 on Russian state TV, there was a translated program called something like "Rescue number 911", with nobody else but William Shattner. (We already knew him at the time.) I got an impression that the US healthcare was impeccable.

There's Julia -- it has serious drawbacks, like slow cold start if you launch a Julia script from the shell, which makes it unsuitable for CLI workflows.

Otherwise you have to switch to compiled languages, with their tradeoffs.

Have you tried Polars? It really discourages the inefficient creation of intermediate boolean arrays such as in the code that you are showing.

> There's Julia -- it has serious drawbacks, like slow cold start if you launch a Julia script from the shell, which makes it unsuitable for CLI workflows.

Julia has gotten significantly better over time with regard to startup, especially with regard to plotting. There is definitely a preference for REPL or notebook based development to spread the costs of compilation over many executions. Compilation is increasingly modular with package based precompilation as well as ahead-of-time compilation modes. I do appreciate that typical compilation is an implicit step making the workflow much more similar to a scripting language than a traditionally compiled language.

I also do appreciate that traditional ahead-of-time static compilation to binary executable is also available now for deployment.

After a day of development in R or Python, I usually start regretting that I am not using Julia because I know yesterday's code could be executing much faster if I did. The question really becomes do I want to pay with time today or over the lifetime of the project.

The problem is not usually inefficiency, but syntactic noise. Polars does remove that in some cases, but in general gets even more verbose (apparently by design), which gets annoying fast when doing explorative data analysis.

Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time.

1) The arrays append is one example. Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is a pointer to a piece of vector).

2) enums creation is just nonsense

3) To make matters worse, at work we have a linter that forbids merging a branch if you a) don't do if err != nil for every case b) have >20 for & if/else clauses. This makes you split functions in many pieces, turning your code into enterprise Java.

It feels like, to implement same things, Go is 2x slower than in Rust.

On the positive side,

* interfaces are simpler, without some stricter Rust's limitations; the only problem with them is that in the using code, you can't tell one from a struct

* it's really fast to pick up, I needed just couple of days to see examples and start coding stuff.

I think Go would have been great with

* proper enums (I'll be fine if they have no wrapped data)

* sensible arrays & slices, without any magic and awkward syntax

* iterators

* result unwrapping shorthands

Other random things I hate:

- first element in a struct, if unnamed, acts like extending a struct;

- private/public fields of method based on capitalisation (it makes json mapping to a struct have so much boilerplate);

- default json lib being so inept with collections: an empty slice is serialised as null/absent (empty list is not absence of a list, WTF, but the new json lib promises to fix that json crap);

- error type being special, and not working well with chanels;

- lambda syntax is verbose;

- panics (especially the ones in libs);

- using internal proxy in companies for packages download is very fiddly, and sucks.

But, the tooling is pretty good and fast, I won’t lie. The language won’t win beauty contests for sure, but it mostly does the job. Still weak at building http servers (limited http server libs with good default headers, very limited openapi spec support).

I’m not 100% sure what you’re referring to here. Struct embedding maybe? (FWIW struct embedding is not limited to the first field in a struct, hence my confusion)

> - error type being special, and not working well with chanels;

I don’t think the error type is special? Do you mean that it is the only interface implicitly defined in each package?

> - using internal proxy in companies for packages download is very fiddly, and sucks.

Yes this one is annoying. I ended up writing an entire go module proxy just so that it works with bearer tokens. It’s crazy that Go only supports http basic auth for proxy authentication in 2025.

what?

It has enums (sum type), tuple, built-in Set[T], and good Iterator methods. It has very nice type inferred lambda function (heavily inspired by the swift syntax)... lots of good stuff!

https://github.com/alaingilbert/agl

>3) To make matters worse, at work we have a linter that forbids merging a branch if you a) don't do if err != nil for every case b) have >20 for & if/else clauses. This makes you split functions in many pieces, turning your code into enterprise Java.

That is not a problem with Go.

It has iterators - https://pkg.go.dev/iter.

> It lacks simple things like check if a key exists in a map.

What? `value, keyExists := myMap[someKey]`

> Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is a pointer to a piece of vector).

First of all, if you're removing elements from the middle of an array, you're using the wrong data structure 99% of the time. If you're doing that in a loop, you're hitting degenerate performance.

Second, https://pkg.go.dev/slices#Delete

If I don't need the value, I have to do awkward tricks with this construct. like `if _, key_exists := my_may[key]; key_exists { ... }`.

Also, you can do `value := myMap[someKey]`, and it will just return a value or nil.

Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict.

This construct (assigning from map subscript) is pure magic, despite all the claims, that there's none in Golang.

...And also: I guess the idea was to make the language minimal and easy to learn, hence primitives have no methods on them. But... after all OOP in limited form is there in Golang, exactly like in Rust. And I don't see the point why custom structs do have methods, and it's easier to use, but basic ones don't, and you have to go import packages.

Not that it's wrong. But it's not easier at all, and learning curve just moves to another place.

Err, no Go doesn't do that. No insertion happens unless you explicitly assign to the key.

  my_map := make(map[int32][]int64)
  val := my_map[123]
  val = append(val, 456)
  my_map[123] = val
  fmt.Println(my_map)

I guess it's convenient compared to Rust's strict approach with entry API. But also, what I found is that golang's subscript returns nil in one case: if the value type is a nested map.

  my_map := make(map[int32]map[int32]int64)
  val := my_map[123]
  val[456] = 789
  my_map[123] = val
  fmt.Println(my_map)

  panic: assignment to entry in nil map

    val, ok := my_map[123]
    if ok {
        ...
    }

nil is equivalent to the empty array, which is why the rest of the code works as it does.

It might if your map is a `map[typeA]*typeB` but it definitely won't return a `nil` if your map is anything like `map[typeA]typeC` (where `typeC` is non-nillable; i.e. int, float, string, bool, rune, byte, time.Time, etc.) - you'll get a compile error: "mismatched types typeC and untyped nil".

Hard disagree. Go has its sharp corners, but they don’t even approach the complexity of the borrow checker of Rust alone, let alone all of the other complexity of the Rust ecosystem.

Sorry but that’s not categorically true. Rather it’s highly scale-dependent. 90% of the slices in a typical code base will be 10s of elements long, in which case the memory overhead and mutation overhead are comparable to, say, a map. Oh and also it’s ordered and (in the above case) can fit within a cache line.

From what I’ve experienced, if you need any fine-grained control over your data or allocations, precision on the type level, expressing nontrivial algorithms, Go is just too clumsy.

The more I read about how people use Go today and what issues people still have, the more I’m happy I picked Rust for almost everything. I even find it much more productive to write scripts in Rust than in Python or shell script. You just get it right very quickly and you don’t need to care about the idiosyncrasies of ancient tech debt that would otherwise creep into your new projects. And of course the outcome is way more maintainable.

Not saying that Rust hadn’t had its own warts, but most of them are made explicit. This is perhaps what I appreciate the most.

Intuitively, however, I still notice myself creating a new Python or shell script file when I need something quick, but then something doesn’t really work well the moment the logic gets a bit more complex, and I need to backtrack and refactor. With Rust, this hasn’t been an issue in my experience.

And intuitively, I still tend to think in Java terms when designing. It’s funny how it sticks for so long. And when writing some Java, I miss Go’s use-site interfaces and TypeScript’s structural typing, while I miss nominal typing in TypeScript. It’s just maybe that you get used to workarounds and idiosyncrasies in some system and then carry them over to another paradigms.

I do like Go’s value propositions, and lots of its warts have been sorted out, but I’m just not as productive in it for my use cases as I am with Rust. It just checks way more boxes with me.

p.s. upvoted, because some mob came and downvoted those who replied to me.

Well, then they look awkward and have give a feel like it's a syntax abuse.

> Its arrays and slices are exactly the same as how you would do it in C. So while it is true that trips up many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic.

In Rust, I see exactly what I work with -- a proper vector, material thing, or a slice, which is a view into a vector. Also, a slice in Rust is always contiguous, it starts from element a and finishes at element b. I can remove an arbitrary element from a middle of a vector, but slice is read-only, and I simply can't. I can push (append) only to a vector. I can insert in the middle of a vector -- and the doc warns me that it'll need to shift every element after it forward. There's just zero magic.

In Go instead, how do I insert an element in the middle of an array? I see suggestions like `myarray[:123] + []MyType{my_element} + myarray[123:]`. (Removing is like myarray[:123] + myarray[124:]`.)

What do I deal in this code with, and what do I get afterwards? Is this a sophisticated slice that keeps 3 views, 2 to myarray and 1 to the anonymous one?

The docs on the internet suggest that slices in go are exactly like in Rust, a contiguous sequence of array's elements. If so, in my example of inserting (as well as when deleting), there must be a lot happening under the hood.

https://pkg.go.dev/slices#Insert

It could have been a builtin function, I suppose, but why not place it in the standard library? It's not a foundational operation. If you look at the implementation, you'll notice it simply rolls up several foundation operations into one function. That is exactly the kind of thing you'd expect to find in a standard library.

So nothing to worry about?

> how do I insert an element in the middle of an array?

Same as in C. If the array allocation is large enough, you can move the right hand side to the next memory location, and then replace the middle value.

Something like:

    replaceWith := 3
    replaceAt := 2
    array := [5]int{1, 2, 4, 5}
    size := 4
    for i := size; i > replaceAt; i-- {
        array[i] = array[i-1]
    }
    array[replaceAt] = replaceWith
    fmt.Println(array) // Output: [1 2 3 4 5]

> The docs on the internet suggest that slices in go are exactly like in Rust, a contiguous sequence of array's elements.

They're exactly like how you'd implement a slice in C:

    struct slice {
        void *ptr;
        size_t len;
        size_t cap;
    };

Which isn't exactly the same as Rust. Technically, a Rust slice looks something like:

    struct slice {
        void *ptr;
        size_t len;
    };

Of course, that does mean operating a bit lower level than some developers are used to. Go favours making expensive operations obvious so that is a tradeoff it is willing to make, but regardless if it were to make it more familiar to developers coming from the land of magic it stands that it would require more magic, not less.

I don't follow. Information isn't agreeable or disagreeable, it just is.

> And I was right that you can't just concatenate different slices

That's right. You would have to physically move the capacitors in your RAM around (while remaining powered!) in order to do that. Given the limits of our current understanding of science, that's impossible.

> hence Go has to do a lot of work under the hood to do that.

Do what? You can't actually do that. It cannot be done at the hardware level. There is nothing a programming language can do to enable it.

All a programming language can do is what we earlier demonstrated for arrays, or as slices allow dynamic allocation, if the original slice is not large enough you can also copy smaller slices into a new slice using a similar technique to the for loop above.

Go does offer a copy function and an append function that do the same kind of thing as the for loop above so you do not have to write the loop yourself every time. I guess that's what you think is magic? If you are suggesting that calling a function is magic, well, uh... You're not going to like this whole modern programming thing. Even Rust has functions, I'm afraid.

The Go standard library also provides a function for inserting into the middle of a slice, but, again, that's just a plain old boring function that adds some conditional logic around the use of the append and copy functions. It is really no different to how you'd write the code yourself. So, unless function are still deemed magic...

(with the caveat that anything else sharing `a` will be mangled, obvs.)

[0] https://go.dev/play/p/uQdoa3mUF00

In other areas, software engineering seems a lot like alchemy, ages before it became the serious science of chemistry.