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

The Decade of Swift

swiftbysundell.com

Post reply on HN
Print view View original

141–145 of 145 posts

Re: The Decade of Swift

#141

Post by m45t3r »

cableshaft wrote: post #63
m45t3r wrote: post #57

Earlier quoted context omitted.

> One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html . Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another t…

Good to know, thanks :) I've only ever used Python for my own tinkering purposes so I haven't been too aware of any new developments. But I assume the old ways are still valid code, so if you're working with Python code you may encounter any of now 3 different systems of just navigating paths for file i/o, what the parent claims should be dirt simple.

It is still relatively simple because the conversion between Pathlibstr is literally one method call (from pathlib, just call `str(pathlib_object)`, from string, just call `pathlib.Path(str_object)`.

I know this because I started a project using only strings and `os.path`, however when testing it started to become complicate to mock the correct paths so in tests I use `pathlib` (with conversions back to string when I finish path manipulation) and the code still works.

Re: The Decade of Swift

#142

Post by skohan »

developer2 wrote: post #112
skohan wrote: post #37

Earlier quoted context omitted.

Can you go into any specifics? Personally I've found Swift to be incredibly easy to read and write, and that it largely delivers in terms of rolling out complexity through progressive disclosure. Most of the complexity is only there if you need it in my experience.

Has Swift improved their text handling? Last time I looked, it took way too many lines of code and temporary variables just to extract a substring range from a string. Their convoluted idea that a string can't be directly sliced with integer indexes–by bytes, let alone by Unicode code points or graphemes–was so frustrating I swore I would never look in Swift's general direction again. It was such a joke just to try t…

It's gotten a bit better, but Swift is still probably not the tool you want to use if you need to do a lot of string manipulation. Swift's string implementation has some interesting properties in terms of memory efficiency and performance, but it still requires fairly the verbose use of string indexes when working with strings rather than simple int offsets. There are good reasons for this, but it's not terribly ergonomic to work with.

FWIW it would probably be fairly easy to implement some String extensions which would give you the kind of API it sounds like you are looking for.

Re: The Decade of Swift

#143

Post by adonese »

6700417 wrote: post #18
m_ke wrote: post #7

With Chris Lattner's move to Google and the state of Java it would interesting to see Google embrace Swift and add official support for it to Android.

This seems very unlikely to me. They would need it to interoperate with their existing stack. They chose Kotlin where they reasonably could have chosen Swift and then worked to extend it to work with their existing stack. Judging by what I would argue has been a lukewarm reception to Swift for Tensorflow, I think it would a very hard sell to convince people within Google to support Swift as a first-class language in…

Are not they use c++/GO for their server side programming?

Re: The Decade of Swift

#144

Post by steveklabnik »

skohan wrote: post #140
steveklabnik wrote: post #135

Earlier quoted context omitted.

A few people have tossed around the idea of “what if Rust but drop the commitment to zero cost abstractions.” That’s probably our principle that causes the most ergonomic hit. Of course, Rust won’t start taking that path, but if I were to start a new language today, that’s what it would look like.

Interesting. There was a really good talk at the last CPPCon by Chandler Carruth about how there is really no such thing as a zero-cost abstraction. The main point being, while you might be able to optimize against a runtime performance cost for abstractions, the cost will almost always be shifted to compile time, or to the cognitive burden on the developer. It really makes me think there must be something like the f…

Yeah, I haven’t watched the talk, but as you’d expect, Chandler has his head on straight. This is a common misconception: zero cost refers to runtime only. There’s always cost. Some people have started saying “zero overhead” instead to make it more clear, but it takes a while to change entrenched terminology.
Post reply on HN