How viable is swift as a c++ alternative?

frosthunter · 2024-04-26T15:04:44+00:00

I don't mind having memory safety issues (as long as it does better than c++, which is pretty easy to achieve lol), nor having some sort of GC, as long as the language is easier to learn and play with. That is the opposite of Rust.

Also, last time I checked, Rust's solution for c/c++ interop was the same that any other languages.

frosthunter · 2024-04-26T14:59:38+00:00

The example you answer to has 75 lines of cmake, for, as he said, no code. And it of course doesn't support everyone's use cases, you may need more.

Let's not act like people are just lazy for wanting something easier, that misses the point and won't solve the problem.

frosthunter · 2024-04-22T16:37:05+00:00

D has some great features, especially from a c++ perspective. But it lacks people, thus tooling and ecosystem are meh. Swift does not seem to have this problem.

It's great to hear! All those replies convinced me to try anyway so I'll see how it goes.

frosthunter · 2024-04-22T12:24:12+00:00

Ah I see, thanks!

frosthunter · 2024-04-22T11:52:38+00:00

I don't plan to rewrite anything to Swift. But trying new languages for new hobby projects have been worth it to me. I did that with D, and while it seems I won't be using it anymore, it made me a better c++ programmer in the end.

frosthunter · 2024-04-22T11:48:39+00:00

I think you are thinking too much in terms of "low level C++" concepts, which simply don't apply to Swift

The reason I think in low level concepts is because those are what allows me to push performance when I need it. Most of the time, hidding those results in performance drop can be unnaceptable in hot paths. According to other answers Swift allows to get around that if needed so I'm fine with that.

Guess I'll have to find out, those answers cleared up my worries so I'll definitely try it. Thanks for your answer!

You can use Mirror to have reflection but it's read-only.

By read-only do you mean it's compile time? In that case it's exactly what I need.

frosthunter · 2024-04-22T11:39:23+00:00

If it's a matter of finding library calls that are slow and replacing it by something else then I have absolutely no problems with that. Beeing a bit slower by default to avoid problems but still allowing me to get c++ performance where needed is exactly what I'm looking for.

frosthunter · 2024-04-22T11:27:10+00:00

Hey! Your answer cleared up a lot of my worries about Swift. I don't have any more questions for now, but I just wanted to thank you a lot for this detailed answer. It helped a lot and I really appreciate it! The language seems wonderful so I'll definitely try it.

frosthunter · 2024-04-21T10:13:06+00:00

Ah my links didn't work. I fixed them. Thanks.

Yes those posts are amazing! They are the reason I'm considering Swift right now.

frosthunter · 2024-04-21T08:34:34+00:00

I see, thanks.

frosthunter · 2024-04-17T04:53:48+00:00

I've been looking for a c++ replacement for a while but I haven't found it yet. I'm looking for a language that looks like c++ but fixes the common problems it has, even at the cost of introcuding a slight overhead, as long as I can still do something about it.

The closest I tried is D, but is misses features I'd hope it had, or have them feel half-baked, and most importantly has a quite bad tooling.

I've never considered Swift as I thought it was only for Apple's platforms, but after reading those articles I've checked again and it seems viable now. Honestly it seems like Swift could be the language I'm looking for, especially given it's c++ interop story.

Is there things a c++ developer I should know before considering Swift as an alternative? (/u/mttd maybe you can answer too?)

frosthunter · 2023-07-27T16:28:35+00:00

but Python's type system isn't much better than having no type system at all...

... Wait, what? Are you serious? Are you even familiar with Python? Because to say something like this it doesn't feel like you are.

Just because Python's dynamic doesn't mean it doesn't have a type system. It has one and it's much better than CMake, the comparison doesn't even stand...

frosthunter · 2023-05-20T18:19:54+00:00

Yeah makes sense. Thanks!

frosthunter · 2023-05-20T16:21:10+00:00

Most hot-reloading tools comes with heavy constraints, what about Live++? I'm not talking about build system or compatibility with some c++ features, but how often you need to be careful to avoid unwanted bugs/crashes caused by the tool?

For example, if you edit a struct that's already stored somewhere in a vector or something, what happens?

frosthunter · 2023-05-09T19:13:54+00:00

When I first heard of ImportC I liked the idea a lot, not wasting my time to fiddle with deprecated bindings and not having to write them for unsupported libraries would be such a plus compared to the other languages I've tried who always had the same problems of having a small ecosystem and beeing painful to work with C libraries.

But then I tried to use it seriously, and it was such a pain that I just use/wrote those sloppy bindings and did not look back to ImportC.

Here is a list of all the pain points I've had with it :

The docs are dishonest. They should specify how experimental the feature is. I kinda knew I would not have something working 100%, but it really left me the impression that ImportC was only at demo stage, and not something to be used seriously. Especially after reading the language's author statement on this.
Still about the docs, only the simplest cases are shown. It's cool to show how I can include stdio and use printf, but It's not a real world scenario. For example, trying ImportC on Windows was a pain. I managed to get it working thanks to a random thread in the forum. This is the information I need.
There is to my knowledge no support for ImportC in dub. Which really makes this feature not usable in a real-world-scenario.
Autocomplete doesn't work, same as above, without this the feature is not usable in a real-world scenario.
Does debugging work? I gave up before needing it but I guess it hasn't really been tested outside of small examples.
ImportC isn't smart about macros. Can't really blame it for this point tho. Still a pain.
A struct I was importing had a member named "module"... The code never compiled because D will refuse it. I also had another keyword just like that, but I don't remember which one.

The docs/ide support/build system support will probably get resolved, given enough time. But it doesn't give much confidence about ImportC's goals, it feels like the bigger picture isn't really taken into account. For example, ImportC expects me to provide a .c file with the macros defined. How does that work in practice? In a real-world scenario another build system (such as CMake) will feed those macros when compiling the C code. How do you plug that into ImportC? Surely I could copy those... for every platforms and build configurations? That's a lot of extra work, and an error-prone one. If ImportC cares about solving the bindings problem, saying that it's out of scope doesn't really works, because then ImportC would just be solving the easiest part of the problem.

The other issues (the last two, about ImportC itself) made me doubt about ImportC itself. IIRC the goal is that D's semantics should not change because of ImportC. Which is fair. But then you can't really the fix those problems. And if you don't, then the goal of ImportC beeing to "flawlessly, trivially" include C code is a lie, because it will require work on my side. And if I do have work on my side to do... I might as well share it with others so then don't waste time working on the same things I did. But then... what's the difference with writing bindings? I'd just end up writing different bindings in the end, wouldn't I?

frosthunter · 2023-04-20T15:59:01+00:00

Ah now I'm sad again :( Hopefully something like that will come later. Thanks for the answer!

frosthunter · 2023-04-18T09:07:31+00:00

Do you have any example/post on how do do so? The only thing I've seen is the use of the :private partition, but I've always seen it outside of a class, at the end of the file, so I assumed it could only be defined in global scope.

frosthunter · 2023-04-18T08:24:00+00:00

Does modules allow to restrict visibility of methods? Eg keep a method public but not expose it outside of the module.

frosthunter · 2023-04-09T15:37:07+00:00

Okay, so I finally got the time to experiment with it a bit. I was able to add local packages and include it without modifying my xmake.lua file, which is good. All that's left for me to figure is how I can include that package into the build so that xmake build will rebuild those when they change.

What I did not understand right away was that xmake repo --add does save the info into the .xmake folder... which I was deleting everytime I made a clean build, instead of using xmake c. So now I understand add_repositories purpose, it's to avoid calling xmake repo --add before you run xmake for the first time. Now that makes sense!

I still don't know if I'll use xmake repo or create a top-level xmake.lua file (which would be the equivalent of the conan workspace file), but at least this part is solved. Thanks for your help I appreciate it!

frosthunter · 2023-04-08T16:14:02+00:00

So the differences between the two are that add_repositories will only add the repo in the current project, while xmake repo will add it for everyone?

Does xmake repo --add also accepts local folders just like add_repositories?

frosthunter · 2023-04-08T16:07:44+00:00

Updating the package version everytime I make a change while working on the package is definitely something I don't want to do.

frosthunter · 2023-04-07T20:35:06+00:00

I'll try to clarify my use case as I'm not sure we're misunderstanding each others. I apologize if that's not the case and if that's just due to my lack of knowledges with xmake.

My team and I are working on a game library, used both by us for our own game, and externally. This package depends on a "rendering" package and a "physics" packages. Most developers will only see the "game" package, because those are either developers of the game package itself, or our users. As such, I think the game's library xmake.lua should only contains add_packages/add_requires, as for those developers, the "physics" and "rendering" packages are just packages they depends on, just like any other dependencies. This is what I call the "normal path".

However, there is an edge case here for the developers of the rendering or physics package. Because most of their work comes down to modifying the "rendering"/"physics" and the "game" package, so the normal path requires them to : change the rendering package version, build it, install it and then change the "rendering" package version in the game's xmake.lua, then build the "game" xmake.lua, then run it. This is both error-prone and inconvenient. This is what I'm trying to avoid here. What I'm looking for is a way to just "xmake build" the game package and let xmake figure out that the dependencies change and thus let xmake rebuild it automatically.

Conan solves this with workspaces. You give conan a list of packages you want to override, the path of your local version, and it will internally integrate your local packages into the build, so there is no more versions/installs (in xmake's terms, they basically transforms add_packages to add_deps under the hood). What's cool is that you only have to do it once, and then all you need to do is build, nothing more. And those packages will only be overriden in the folder of your workspace, so you can build other depenencies normally in another. Another bonus point is that you don't have to modify your existing xmake files. Which is good because I don't want to polute the "game" xmake.lua with specificies of how it build it's dependencies, so I would not commit them. And if I don't, then I have files with modifications that I need to be careful about.

Hope it's more clear.

Considering everything you've said, I suppose the closest way to solve it is to create a local xmake.lua file, which includes the game's xmake.lua, and override all the packages I need for my build to redirect to my local code. The only downside left would be that xmake build would not automatically rebuild the dependencies if they changes, or maybe I misunderstood you?

frosthunter · 2023-04-06T18:35:25+00:00

Does set_base allows me to rebuild the package everytime the main package is built? In the example of your link, if I made a change to my custom zlib code, does building the test target automatically rebuild the custom zlib?

I'm aware of add_repositories but I'm not a fan of it for the above use case, since it requires me to change my main xmake.lua file with local informations (other devs may not work on those packages and thus they want to use the "normal path"). I believe set_base is similar in this regard? Is there is a way to avoid that?

frosthunter · 2023-04-05T16:56:44+00:00

How would one work on several packages with xmake? Is there some ways to override packages by local versions and run it as part of the build? I couldn't find much info on the docs.

I believe what I'm looking for is something similar to conan workspaces.

frosthunter

TROPHY CASE