[grishka]

> It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc.

Yeah and that's exactly what I would call a disadvantage. I prefer dumb programming languages like Java, C++11 without the auto keyword, and Objective-C. They're much easier to understand because there are fewer ways to achieve the same thing and they don't require keeping as much context in your head while reading the code.

IRL example with Swift: I wanted to fix a logic bug in someone else's code and spent an hour trying to get a field from an object. I could see it in the debugger but every way to get it I could think of produced an uninformative syntax error. There was nothing to google because there were no keywords around it, even. Then the author of the code in question came online and explained that it's an "enum with associated value" (wtf?!) and you have to use this `if let` or `case let` abomination to extract the fields into local variables.

Another IRL example with Swift is that this whole immutability-by-default thing was just driving me insane because I'm too used to the fact that I can overwrite function/method arguments but Swift won't ever let me.

[julius_set]

That’s not a problem with the language that’s just you not knowing how to use it, two very different things.

Associated values with enums are very powerful features of the language.

[grishka]

Another problem of these languages is that you have to actually learn them, and there's too much to learn. And good luck understanding anything without that encyclopedic knowledge.

To me, it's all just abstractions that get in the way more than they help, tbh.

[uryga]

> good luck understanding [Swift] without encyclopedic knowledge.

> I prefer C++11

C++ is like the prototypical example for "languages that require encyclopedic knowledge" so this seems like a weird comparison

[grishka]

C++ has most of its complexity in the standard library, and that is easy enough to look up if you don't understand something. It's relatively barebones as far as the syntax goes. Swift, on the other hand, has way too many features a.k.a. syntactic sugar in the language itself.

[saagarjha]

Uh, no? Just parsing the language is undecidable, there's problems with "vexing parses" and strange overloads, there's like twenty seven ways to initialize things, there's new syntax every release to do something that has already existed in the language…

[ratww]

Exactly. The Most Vexing Parse is so popular it has its own Wikipedia page: https://en.wikipedia.org/wiki/Most_vexing_parse

[ratww]

Sorry, but in a previous comment you mentioned that you prefer "dumb programming languages like [...] C++11 without the auto keyword". However "too much to learn" and needing "encyclopedic knowledge" is exactly how most people with different levels of familiarity with the language would describe C++ (with or without auto).

To me it sounds as if your problem is purely lack of familiarity with modern languages, rather than them lacking some specific property that your usual languages have.

[julius_set]

I mean you can say that for any language. If someone has to learn C or Java, you still need to learn how those languages work, build domain expertise and so on.

Swift is a very nice general purpose language and I’ve been writing code decades in almost most mainstream languages. I much prefer writing Swift code, in face some of my back end projects have been written in 100% swift, this allowed me to reuse models and APIs with the iOS and MacOS counterparts.

[hajimemash]

How have you written backend code in Swift, were you able to use it in places you would normally use e.g. C++?

I'm asking because I like Obj-C/Swift, and am wondering if it's possible through some clang/LLVM magic to be able to code Obj-C/Swift in environments that expect C or C++, for example like in Qt. Like, could I have a traditionally C++ app (Qt app) but have most of my code be in another LLVM-compatible language.

[ratww]

> Like, could I have a traditionally C++ app (Qt app) but have most of my code be in another LLVM-compatible language

It is possible! I mix Swift and Rust in my day job. I use the C ABI to interface between the two. The Swift layer is very thin and pretty much just a bridge between Rust and Cocoa/UIKit/Metal, but there's nothing stopping you from doing the opposite.

If you're going to bridge Swift with Qt, the sanest way is to use Objective-C++ to wrap Qt calls and call it from Swift.

However keep in mind that the Swift experience in other Operating Systems might not be as good as in Macs. That's why I went with Rust for this project. But things might have changed in the meantime!

[hajimemash]

That sounds really cool.

I did some searching to see people's experiences substituting other languages for C++ through LLVM, and didn't find much other than samples of translated calls.

Given that there would be a big benefit to this (not having to learn a new language, less manual memory management), are there good reasons this isn't way more common?

[julius_set]

There’s a very vibrant backend community for Swift, Vapor is growing and used in production for a lot of companies.

https://vapor.codes

[saagarjha]

> C++11 without the auto keyword

That's still a massive language; the part you removed makes it basically be C++03 but even worse :/

[grishka]

How worse? How would you even begin to understand this line without an IDE?

    auto something = someObject->someFunction();
    // and then 10 lines of various operations on "something"
    // also imagine that someObject is also auto and returned from somewhere

I've had to deal with code like this. It wasn't pleasant, even with an IDE. There are very few cases where type inference is good and doesn't make your code an unreadable mess.

[saagarjha]

Step number one is not naming your things "something". I for one am glad I can use "auto" instead of "std::vector<int>::size_type" in my code–in this case the actual type this couldn't matter less; all you need to know is that it's some kind of unsigned integer. The same is true for Swift, where it's generally a lot more useful to know you have some type of sequence rather than "I have a LazyMapSequence<LazySequence<[Int]>.Elements, String>". Plus, C++ is one of those languages where certain things have types that you cannot write down, so auto is required to use certain parts of the language!

[snazz]

Type inference is the usual tradeoff for being able to write statically-typed code efficiently. I think it's better than

  MyType something = new MyType(...); 

like in old-school Java, is it not? IDEs and LSP-enabled editors are pretty much the standard nowadays, although I agree that it's nice to be able to read code without one.

Also, that code you mentioned seems like bad style with the auto keyword; the type should be obvious.

Do you have a better solution in mind?

[grishka]

> IDEs and LSP-enabled editors are pretty much the standard nowadays

There are many places where you see code without IDE-like features. One that comes to mind is everything related to git. Web-based git tools like github, git GUIs, command-line git, you name it.

Besides, it's nice to be able to read and understand the code without needing to download the entire project and importing it into an IDE just for that.

My idea is that you almost always write in an IDE, but not necessarily read in one. Thus, for verbose languages, the IDE would generate most of that example for you (I know for sure IDEA does this exact completion) but it will be perfectly understandable in a git diff.

[dragonwriter]

> There are many places where you see code without IDE-like features. One that comes to mind is everything related to git. Web-based git tools like github, git GUIs, command-line git, you name it.

Both git and web-based git+ services like Github are frequently used through deep editor/IDE integrations, so, no, I disagree that “everything related to git” is a good example here.

[pjmlp]

I use all such tools mostly from the comfort of my IDE.

[vips7L]

You just need to use auto properly.

auto/var/val etc are best used when you can tell the type from the rvalue.

    var m = new HashMap<String, List<Pair<X, Y>>>();

    var m: Map<String, List<Pair<X, Y>>> = obj->someFunc();

All of the examples you have should be caught in linting or code review.

[grishka]

> You just don't know how to use auto properly.

I do. The problem is, others don't necessarily do. A good-in-my-world language makes it take more effort to write unreadable code than readable.

Everyone seems to only be judging languages by the code you write yourself, totally oblivious to the fact that reading and understanding someone else's code, including in projects you don't influence, is also an important part of being a software developer.

[saagarjha]

Believe me, we've read a lot of code written by other people. There's a point where you read

  HashMap<Integer, ArrayList<String>> mapping = new HashMap<Integer, ArrayList<String>>();

enough times that you start to get tired of reading stuttering code, too.

[vips7L]

By your logic we shouldn't program because someone else MIGHT mess it up.

Should we remove every feature that someone might misuse?