You omit the fact that he took those words back and said “Crimea is Ukraine” while being in prison, knowing well it will not make his life (and death) easier
If you had read the link you posted you would know those are various historic proposals for language reforms not something that's widely used. Same way there have been various proposals for English spelling reforms. That's not the normal way for writing or reading Russian. Russian uses Cyrilic alphabet which if anything is closer to Greek alphabet than Latin. There are other slavic langauges which actually use Latin based scripts. If you don't read Russian it might look like some of the letters look similar but that's only less than half of alphabet and from those half have completely different meaning than Latin lookalikes.
Yes there are various schemes for transliterating Russian into latin script, which people occasionally use for various reasons like typing on a computer or phone which hasn't been fully configured for use with Russian language, in contexts where unicode isn't supported or to make street signs legible for tourists. That's different from the "Russian Latin alphabet". In most cases where proper Cyrillic is problematic dedicated "Russian Latin alphabet" that's based on Latin with extra diacritic marks would also be problematic.
Similar thing could be said about other languages like Japanese or Chinese, but I don't think anyone would describe them as "languages that use the Latin alphabet".
As for typing on keyboard the main Russian layout is nothing like qwerty. Computer keyboards sold in relevant regions often have dual labels. I personally never learned touch typing in Cyrillic and use the phonetic layout in the rare cases I need to do so since for me it was a second foreign language.
Which exact approach Click chose - who knows. Will it be possible to choose your preferred Russian layout like on a desktop computer? Likely not. If they supported that I would have expect them to also add layouts for more languages. Although maybe they didn't want to promise anything for languages for which they don't have OS UI translations.
Fortunately, I then assumed that I knew nothing and asked anyways. I'm glad I did — this thread is now much more interesting than the one-word comment conveyed to me at first.
Transliteration is certainly a thing but it's only ever used as a last resort when you really have to pass Russian text through a system that only supports the Latin alphabet, or when you can't input Cyrillic for some other reason. It used to be somewhat common for SMS 20+ years ago.
Palm Treo/Pre and BlackBerry users! And probably Clicks users too. It's not a matter of "Does Russian language use the Latin script?" (it doesn't), but rather "What is the least annoying method to input Cyrillic on a BB-style keyboard, which doesn't have enough buttons for the йцукен layout?". Phonetic layouts such as яверты or яшерты were very popular for such devices back in the day.
For anyone one confused, the first part is an approximate transliteration into Cyrillic of the English sentence “Much like how you can/could spell English in Cyrillic.”
> The Zigbook intentionally contains no AI-generated content—it is hand-written, carefully curated, and continuously updated to reflect the latest language features and best practices.
You can make it run much better by increasing the game's process priority with `renice`. I know that sounds like something that should not work, but it does.
> If you have a struct with a simple int field, and you store that somewhere as an *int, the entire struct and anything it points to will be kept alive.
While Go allows interior pointers, I don't think what you say is true. runtime.KeepAlive was added exactly to prevent GC from collecting the struct when only a field pointer is stored. Take a look at this blog post, for example: https://victoriametrics.com/blog/go-runtime-finalizer-keepal...
I don’t believe that’s the case based on the example in the blog post. The fd field in that struct was passed into the later function by value (i.e. as an int, not an *int), so there was no interior pointer in play at all.
1) The idea is that your library should accept the slog logger and use it. The caller would create a logger with a handler that defines how log messages are handled. But there are problems with supported types; see my other comments.
1) Right, but this is complicated and annoying. Imagine a world where you could just pass your existing logger in, because my library references an interface like `stdlib/logging.GenericLoggerInterface` and slog, zap, zerolog, etc. all implement that! Would be nice!
2) TIL about `T.Output`, thank you, that's great to know about. Still annoying and would be nice if the slog package showed an example of logging from tests with correct callsites. Golang gets so many things right about testing, so the fact that logging in tests is difficult really stands out and bothers me.
But that is exactly what slog provides? The a unified interface that can be implemented by other logger libraries. Yes the Logger itself is not the interface, but the Handler it is backed by is.
My biggest gripe with slog is that there is no clear guidance on supported types of attributes.
One could argue that supported types are the ones provided by Attr "construct" functions (like slog.String, slog.Duration, etc), but it is not enough. For example, there is no function for int32 – does it mean it is not supported? Then there is slog.Any and some support in some handlers for error and fmt.Stringer interfaces. The end result is a bit of a mess.
So the code that uses slog but does not know what handler will be used can't rely on it lazily calling the `String() string` method: half of the standard handlers do that, half don't.
And I know that I can create a wrapper for unsupported types. My problem is exactly that – I don't know what types are supported. Is error supported, for example? Should I create a wrapper for it? And, as a handler author, should I support it directly or not?
Not sure what your definition of "supported" is, but I'm afraid you're going to have to bite the bullet and ... gasp ... read the documentation https://pkg.go.dev/log/slog
Not sure I understand your sarcasm. I read the documentation, source code, handler writing guide, and issues in the Go repository multiple times over two years, and I use slog extensively. Go is my primary language since r60. I think I know how to read Go docs.
Now, please point me to the place in the documentation that says if I can or can't use a value implementing the error interface as an attribute value, and will the handler or something else would call the `Error() string` method.
My definition of "supported" is simple – I could pass a supported value to the logger and get a reasonable representation from any handler. In my example, the JSON handler does not provide it for the fmt.Stringer.
> Values are formatted as with an encoding/json.Encoder with SetEscapeHTML(false), with two exceptions.
> First, an Attr whose Value is of type error is formatted as a string, by calling its Error method. Only errors in Attrs receive this special treatment, not errors embedded in structs, slices, maps or other data structures that are processed by the encoding/json package.
So the json handler more or less works as if you called json.Marshal, which sounds pretty reasonable.
I think you missed the “any handler” part. Currently, the types that my library package could use depend on the handler used by the caller. This limits types to an unspecified subset, making things quite impractical.
The output of data is handled by the handler. Such behaviour is clearly outlined in the documentation by the JSONHandler. I wouldn't expect a JSONHandler to use Stringer. I'd expect it to use the existing JSON interfaces, which it does.
I'd expect the Text handler to use TextMarshaller. Which it does. Or Stringer, which it does implicitly via fmt.Sprintf.
My problem with that is that it makes it impossible to use slog logger safely without knowing what handler is being used. Which kind of defeats the purpose of defining the common structured logging interface.
As a producer of the response, if I didn't care about being understood, I would use a made-up language. As a consumer, you may care about understanding my response, but you cannot do anything about it.
Hence the design. The producer coming up with a made up language that makes sense to the producer, but probably doesn't make sense to the consumer — especially when you have many different consumers with very different needs — is far more problematic than the producer providing an abstract representation and allowing the consumer to dig into the specific details it wants.
As with everything in life, there are tradeoffs to that approach, of course, and it might be hard to grasp if you come from languages which different idioms that prioritize producer over consumer, but if you look closely everything about Go is designed to prioritize the needs of the consumer over the needs of the producer. That does seem to confuse a lot of people, interestingly. I expect because it isn't idiomatic to prioritize the consumer in a lot of other languages and people get caught up in trying to write code in those other languages using Go syntax instead of actually learning Go.
A good, if a bit strange, example. A CPI logger wouldn't need to log the same thing as an access logger, but the producer need not care about who is consuming the logs. Consumers might even want to see both and, given the design, can have both.
Certainly logs lose their value if they are wrong. And either approach is ripe for getting things wrong. But the idea is that the consumer is more in tune with getting what the consumer needs right. The producer's assumptions are most likely to be wrong, fundamentally, not having the full picture of what is needed. What is the counter suggestion?
We've banned this account for continually posting unsubtantive comments and ignoring our previous request to observe the guidelines.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
