Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift UTF-8 String

swift.org

Post reply on HN
Print view View original

51–60 of 97 posts

Re: Swift UTF-8 String

#51

Post by accatyyc »

ta7775466 wrote: post #21
ilovecaching wrote: post #4

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.

They'll need to do an awful lot more on their IDE for that to happen. That GUI drag'n'drop onto code... ugh.

That's just a convenience thing. I've worked in Xcode for nearly 10 years and I never use that feature. Good feature for teaching though. But if you hate it, just don't use it.

Re: Swift UTF-8 String

#52

Post by nicky0 »

sonnyblarney wrote: post #22
asveikau wrote: post #20

Earlier quoted context omitted.

I don't think a lot of people realize that Unicode itself, in any representation, is complex, and there is no one abstraction that will make it always easy in all cases. So I think your goal is unobtainable. Some of that complexity is because world languages themselves are not simple. (eg. If you were to ditch Unicode and start from scratch, it would remain hard to do bi-di text, to pick a random example.)

Totally see what you are saying (the underlying issue is language itself), but it's pragmatically obtainable.

The think is, strings that make sense has been a major goal of Swift, that's why they have been iterating on it so heavily. FWIW I think Swift's is probably one of the cleanest String abstractions out there with respect to unicode correctness balanced against efficiency and usability.

Re: Swift UTF-8 String

#53

Post by pjmlp »

saagarjha wrote: post #48
pjmlp wrote: post #45

Earlier quoted context omitted.

Right, I was wrong about the start date, on my mind it was started in December. As for being active, no signs of life since 08th February, more than one month without updates.

There's still stuff going on on the GitHub repository: https://github.com/SwiftCommunityPodcast/podcast

So in one and half months they haven't found time nor a volunteer willing to do another podcast?

My favourite podcasts have weekly and bi-weekly updates.

Re: Swift UTF-8 String

#54

Post by WanderPanda »

cageface wrote: post #9
phamilton wrote: post #8

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.

I would assume good debug-tooling should make spotting such cycles quite easy, why is this even considered a problem?

Re: Swift UTF-8 String

#55

Post by pjmlp »

cageface wrote: post #32
ilovecaching wrote: post #16

Earlier quoted context omitted.

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 applica…

Ref counting can also be slower than tracing GC when getting rid of complex data structures, heavy multi-threaded code and can lead to stack overflows if destructors are incorrectly written.

Re: Swift UTF-8 String

#56

Post by repolfx »

ygra wrote: post #37
ezoe wrote: 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 t…

It's even harder than that - APIs have expected performance characteristics, and APIs that involve string manipulation can change their performance when needing to work directly with UTF-8, e.g. working with file paths might become slower.

Re: Swift UTF-8 String

#57

Post by Twisell »

sonnyblarney wrote: post #13

If I ever wrote a language, handling strings wrt unicode would be the first thing I would fix so so that it's clear, concise and especially consistent. It bothers me that in 2019 it can still be difficult to manage even basic things with strings, and yet, whenever we talk/argue/bike-shed about 'languages' we get caught up in intellectual meandering. Please, give us strings that make sense. Then argue about monads.

Tell that to the Python community where switch to UTF8 was/is a huge battle!

Swift is meant to be retro compatible with Obj-C and all. As someone pointed out windows in the meantime have basically no announced battle plan to transition out of UTF16.

I this game latecomer were rewarded because they started with UTF8 or switched from ASCI. But innovators actually tried UTF16 in the mean time an now have to do the job twice in a retro-compatible manner.

Re: Swift UTF-8 String

#58

Post by repolfx »

phamilton wrote: post #8
ilovecaching wrote: post #4

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.

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…

Kotlin has an LLVM backend these days and can compile to native binaries. It's more Swift-like, then.

Re: Swift UTF-8 String

#59

Post by saagarjha »

skrebbel wrote: post #44

I have never written a single line of iOS/macos code, but I'm interested in Swift because it's a cool language. Can anyone explain why this is done now and not when Swift was first released? I mean, UTF-8 was already the clear winner when Swift started. Is it some obj-c compat story?

Objective-C strings are UTF-16, so it’s likely this was the case. The String ABI has diverged since then, but there is a need to finalize those changes now due to ABI stability.

Re: Swift UTF-8 String

#60

Post by cageface »

WanderPanda wrote: post #54
cageface wrote: 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.

I would assume good debug-tooling should make spotting such cycles quite easy, why is this even considered a problem?

It’s not easy and iOS developers spend a lot of time explicitly breaking ref cycles in code and tracking down resource leaks. I’ve seen a lot of code from experienced iOS devs that gets it wrong.
Post reply on HN