Live data from Hacker News

Swift UTF-8 String

swift.org

31–40 of 97 posts

Re: Swift UTF-8 String

#31
post #9

Earlier quoted context omitted.

We've been eye-ing it for a while at remind.com. Our hangup has been that we're heavily aws focused, but https://github.com/amzn/smoke-aws is looking promising. We're interested because it's one of a handful of statically typed functional programming languages. Haskell/Ocaml are great as ML type languages, but it's a big paradigm shift for a team to jump into. Rust still has a pretty decent learning curve. Swift seem…

Swift is a nice language but I think the reliance on ref counting is going to limit its adoption. You have to work a lot harder to avoid reference cycles in Swift than you do in a garbage collected language. Unless GC latency is a deal breaker for your problem domain it’s not worth the extra effort. My money is on Rust for really low level stuff and Kotlin for anything where JVM overhead is acceptable.

> You have to work a lot harder to avoid reference cycles in Swift

It depends on how you use it. As I understand it, if you use enums everywhere it all sort of works out. If you start mixing in structs, there are certainly a lot of minefields.

Re: Swift UTF-8 String

#32
post #9

Earlier quoted context omitted.

Swift is a nice language but I think the reliance on ref counting is going to limit its adoption. You have to work a lot harder to avoid reference cycles in Swift than you do in a garbage collected language. Unless GC latency is a deal breaker for your problem domain it’s not worth the extra effort. My money is on Rust for really low level stuff and Kotlin for anything where JVM overhead is acceptable.

What do you see as the advantage of Rust or ref counting?

I've just read the Rust docs and not written any code so I'm probably the wrong person to ask but Rust's ownership rules seem to make it possible to eliminate a lot of dynamic allocations in the first place.

Ref counting can beat GC if you're in a domain where GC pauses can be an issue. Things like games, for example. Although I understand state-of-the-art GCs can also be fast enough to use for these kinds of applications in some cases now. Ref counting can also be more memory efficient than GCs.

Re: Swift UTF-8 String

#33
post #26
post #7

Earlier quoted context omitted.

Unless you consider reference counting to be a form of GC¹, Swift is not a GC'ed language. ¹It technically is, but most people don't mean reference counting when they say GC.

It doesn't matter what people think, rather CS definition. Software Engineering is not about what people think, rather what is technically correct.

Well.. what is technically correct depends on a definition. And there are customary/practical definitions too. And sometimes definitions are tainted by context, like in "is this gc or ref counting language".

Re: Swift UTF-8 String

#36

Great work by the Swift team on stabilizing this (especially around UTF-8) for Swift 5. One question: how do Objective-C's tagged NSString pointers fit into this? Are these imported as "opaque" strings? I see that _SmallString seems to store its characters inline; are there any plans to do tagged pointers in Swift as well?

It would have to be opaque as there is no backing allocation of any kind so the string can’t provide a pointer to the contiguous memory. (Plus tagged strings use an encoding scheme that makes the incompatible with UTF-8 anyway) It’s possible that a smallstring version of the tagged pointer is created in some situations.

SmallString actually was just a tagged cocoa string at one point but that was removed in favor of more powerful implementations. The latest implementation allocates no memory on the heap either but can store more characters, so using a tagged pointer would be a step back.

Re: Swift UTF-8 String

#37
post #35

I wonder how long Windows can hold UTF-16 as the default native encodings. They recently added UTF-8 locale.

CP65001 has existed for quite a while. There just have been plenty of places where it never really worked (I think the console was one of them).

Nonetheless, UTF-16 will most likely stay. They might add wrappers around all API functions that convert arguments first, so we'd get CreateWindow8 alongside CreateWindowW and CreateWindowA, but I wouldn't hold my breath. The duality of API functions was to enable programs to be built for NT and 9x with the same codebase. It was never really intended for people to call them directly to enable non-Unicode-aware applications on NT.

The file system cannot migrate from UTF-16 anyway without breaking things, so that will stay as is.

IMHO there's pretty much nothing to gain, except a lot of risk in trying to change Windows to UTF-8 internally and the current interface might be an inconvenience to some developers, but not as much as to justify changing the whole OS.

Re: Swift UTF-8 String

#38

Earlier quoted context omitted.

It really depends on what you're doing. A lot of the time, neither garbage collection pauses nor reference cycles are an issue; and when they are it's typical that one or the other will solve the issue.

If GC pauses aren't an issue for your app then you're better off with a full-blown GC because it's a lot easier to code for. Reference counting, as used in Swift, forces you to think a lot about cases where you might be creating reference cycles and memory leaks. GCs can figure this out for you and take that burden off the programmer.

Yes, but reference counting doesn't have unpredictable pauses, which can be important in certain situations. That's what I was trying to say above.

Re: Swift UTF-8 String

#39
post #25

Earlier quoted context omitted.

Sibling comments mention Chris Lattner. For readers that might not know him, he's the main inventor of Swift. Him pushing Swift should not necessarily be taken as a sign of general community enthusiasm. I would love to see more Swift on the backend. It's surprisingly hard to find a language that's concise, expressive, statically typed, and easily accessible to beginners. Swift checks all these boxes. That being said,…

He started a podcast last year to promote Swift outside Apple platforms, it lasted three episodes.

Which podcast are you talking about?

Re: Swift UTF-8 String

#40

Is anyone using Swift outside of Apple specific stuff professionally? When they first announced swift it felt like it might catch on as general purpose gced language. The language itself is quite beautiful in a lot of ways (although being OO was obviously an awful step backwards). But it feels like it's still just the crazy language Apple uses, just like Objective-C was.

Sibling comments mention Chris Lattner. For readers that might not know him, he's the main inventor of Swift. Him pushing Swift should not necessarily be taken as a sign of general community enthusiasm. I would love to see more Swift on the backend. It's surprisingly hard to find a language that's concise, expressive, statically typed, and easily accessible to beginners. Swift checks all these boxes. That being said,…

Swift is a great language.

The main problem for me is that it's still very Apple centric. Other platforms are still very second class.

For Linux, there are only Ubuntu packages. Even on Arch which is usually front of the pack with these things, there are only brittle third party (AUR) packages.

Windows support is even worse.

Post reply on HN