Earlier quoted context omitted.
Protocols and formats absolutely should not require decoding strings. I think you are mistaken. Can you name any well-established protocol or format that does not treat strings as opaque encoded bytes? Edit: so far these examples have been given: * HTTP: wrong. the spec does not tell you to decode any strings * CSV: wrong. the spec does not tell you to decode any strings, nor is it necessary to have any unicode aware…
> * CSV: wrong. the spec does not tell you to decode any strings, nor is it necessary to have any unicode awareness in order to properly read and parse the data or deal with the delimiters. CSV is defined in terms of characters, not bytes, so CSV parsing does require you to be encoding-aware: if your CSV file is encoded as UTF-16, bytewise parsing will destroy the data.
Zig 0.9.0
161–170 of 250 posts
Re: Zig 0.9.0
#162Earlier quoted context omitted.
I don't see anyone seriously using it in production, outside of the Zig ecosystem itself, so long as this remains true (from the posted link): > The Zig standard library is still unstable and mainly serves as a testbed for the language. After the Self-Hosted Compiler is completed, the language stabilized, and Package Manager completed, then it will be time to start working on stabilizing the standard library. Until t…
I believe there is someone using it in production for a field deployed embedded system that is tied to revenue. IIRC Forwards compatibility is not an issue because those deployments are one-and-done.
Sure. But people do all kinds of not advisable things, even if revenue is at risk.
In fact, it might even be fine, for their use cases. The build it once, it has the libs they want covered, it works like the want, that's it.
That can work with any early release language/lib.
The problem is with someone casually putting it into production, and then not expecting breakage, missing libs they will need, finding that there's not much tooling, and so on.
In other words "can it be put into production?" is another question compared to "is it ergonomic, stable, full featured enough to be a good and easy production choice?"...
Almost everything can be put into production (and even work reasonably well), even a 1000-liner Perl script written by someone who first tried Perl that same week.
Re: Zig 0.9.0
#163Earlier quoted context omitted.
A lot of people reach for string handling when the actual correct thing to do is intentionally avoid string handling, and only handle strings as opaque encoded UTF-8 bytes, that cannot be reasoned about in terms of human language. I would even argue that having string handling in a standard library (or language) has the potential to cause a net increase in bugs, because of people thinking they are handling strings wh…
IMO, Swift is a language that gets it right, by exposing an interface which feels to very closely match how "humans" understand text — the default String interface is a collection of grapheme clusters, while `.utf8View`, `.utf16View`, and `.unicodeScalarView` are optional views which expose data explicitly encoded as needed. Swift is pretty pedantically strict about Unicode correctness, and avoids some pitfalls which…
One thing to note: aside from programming interviews, these operations are fairly rare. And that's a good thing, because none of these produce results that are very intuitive, because they are not very well defined on strings in general (I don't fault Swift for this, but it's just a general problem with text). Using any of these to create a new String may cause entirely new characters to show up, or the length of the text to change. So Swift actually doesn't expose these as "string" operations, but operations on the characters themselves; in each case returning a new collection of characters that is not a String. Now, you can reconstitute them into a String pretty easily, but you should keep the this in mind when doing so.
Re: Zig 0.9.0
#164Earlier quoted context omitted.
I can't comment for all the other people who are posting and voting for those posts, but at least for me Zig has quickly become my language of choice for side projects. Its cross compilation features alone are enough for it to replace the system C/C++ compiler toolchains I used to use, and the language itself is everything I'm looking for. Readable (IMO) syntax, proper namespaces, order independent declarations, powe…
It seems strange to compare to C++ when it has none of the features that most define C++ like RAII, OOP & templates. Its not really "simplified" - its something totally different.
Re: Zig 0.9.0
#165Earlier quoted context omitted.
It seems they don't want unicode strings as part of the language, at best as a library. But unless there's a single sactioned one, this will not end well. And this is met with answers like "just avoid string handling" from the language designers... It's probably because they don't work in any related domain, and even less so have to do with international strings (except as byte buckets they don't care about and don't…
It seems way nicer to have a language that treats strings as byte arrays and use libraries to handle encodings than to have a language that treats strings as UCS-2 and use libraries to handle UTF-8 strings that live inside of UCS-2 strings.
Re: Zig 0.9.0
#166Earlier quoted context omitted.
I'm pretty new to Zig, but after taking another look recently I was pleasantly surprised by the progress on SIMD operations via builtin Vector types [1],[2]. For an application of "I want to speed up my math-intensive code with SIMD while supporting x86-64, aarch64, and non-SIMD fallbacks" it might be suitable for you now, and Zig certainly exposes more readable SIMD syntax than with C intrinsics imho [3]. But if you…
It's planned to have feature parity with all the intrinsics that are available in the wild, for any CPU architecture. The difference with C is that we want to make the intrinsics part of the language; not a compiler extension. So, while you could do compile-time CPU feature detection to check if an intrinsic will lower to machine code and choose a different implementation, you could also just express the code with th…
Re: Zig 0.9.0
#167Earlier quoted context omitted.
Evolving how? I'm not aware of any reason to move beyond UTF8 for encoding Unicode.
Which version of UTF8?
"Which third-party strings lib of several half-complete incompatible libs" will be a much realer concern...
Re: Zig 0.9.0
#168Re: Zig 0.9.0
#169Earlier quoted context omitted.
IMO, Swift is a language that gets it right, by exposing an interface which feels to very closely match how "humans" understand text — the default String interface is a collection of grapheme clusters, while `.utf8View`, `.utf16View`, and `.unicodeScalarView` are optional views which expose data explicitly encoded as needed. Swift is pretty pedantically strict about Unicode correctness, and avoids some pitfalls which…
> Given a specific string manipulation task, I'd be happy to provide an example of what it might look like in Swift! How would you safely get the nth index of a string, clamped to the valid indexes? So if the nth index is out-of-bounds you get the first/last index instead?
extension String {
func character(atClampedIndex index: Int) -> Character? {
guard !self.isEmpty else {
return nil
}
let clamped = max(0, min(index, count - 1))
return self[self.index(startIndex, offsetBy: clamped)]
}
}Re: Zig 0.9.0
#170Earlier quoted context omitted.
Which version of UTF8?
When adopting a new niche language, with hardly any following, and frequent changes, and not even an 1.0, like Zig, "which version of UTF8" (as if that's an issue) is the least of your worries... "Which third-party strings lib of several half-complete incompatible libs" will be a much realer concern...
I've worked on a full-duplex file synchronization system that had to support cross-platform operating systems and file systems, across a variety of Unicode normalization schemes (and versions [1], which is why I introduced the question), and I'm personally satisfied that baking this into the language specification would be a mistake.
[1] For example, depending on the file system, there's simply no way to get the normalization right unless you reverse engineer the actual table they're using, or probe the file system to do the normalization for you.