[lloydjatkinson]

Then C++ has failed. If it has so many competing standards and subsets, then it is too fragmented. This is why when you see C++ written in one standard it looks like a whole other language when you look at other C++.

If after a decade there are so many details still obscured from you, then that's pretty much again a fault of the overly-engineered and tacked on language called C++.

Other mainstream language work fine and allow you to still write clean and modern code without having literally dozens of subsets and implementations. So why is it that C++ feels the need to have so many?

[flohofwoe]

On the contrary, the one nice thing about C++ is that it is 'multi-paradigm'. Don't like boost's philosophy of overengineering every little detail? Then don't use boost. C++ without exceptions, RTTI, or even the whole STL? Perfectly fine. Other languages don't have this freedom. It's a double-edged sword of course. Less freedom also means wasting less time with pointless discussions about which combination of C++ features is 'right'.

[imron]

> Then don't use boost.

After using boost in several projects and regretting it each time (slow compile times, painful to configure), I finally learned my lesson and "don't use boost" is now one of my guiding principles when programming in C++.

[ndh2]

While I would mostly agree, I would humbly suggest a small nudge in perspective: Boost does not equal Boost. While I passionately hate most of Boost, I find boost::optional to be one of the most useful template classes. So you shouldn't treat Boost as one library, but as a collection of different libraries. Same goes for STL in my opinion.

[imron]

I think boost has definitely had a positive impact on c++ and the fact that large amounts of it are now in (or had a major influence on) the std library certainly makes it much easier to forgoe using it.

[nurettin]

I use boost filesystem and string algos. I can't say they slow down compilation that much. And they save a lot of typing.

[VHRanger]

Theres filesystem TS in c++17. Also experimental/filesystem in all compilers except gcc since 2014

[nurettin]

Sure, threads and datetime has been in certain implementations, too. I think anyone can appreciate the fact that these libraries are not compilation hogs (such as phoenix or mpl) and are portable and save a lot if time.

[fsloth]

We use C++ because of the C++ the ecosystem not because of the C++ the language.

There really is no other language that fits all of the constraints C++ fits. If there was, I'd be using it. And before you ask 'Have you looked into...' the answer is yes, unless the language is obscure, in which case it lacks the ecological robustness of C++.

[FiveDegrees]

I hope Jai ends up being made interoperable with C++.

[imron]

I just hope Jai end up being released.

jblow, I know you read HN, lots of us are looking forward to Jai.

[cr0sh]

Gotta say I'm looking forward to it too, even though I might not ever use it.

There are some things I disagree on with it, but most of those are orthogonal to the domain of which the language was meant to be applied, namely game programming. For that end, I can get behind those.

That said - the main things I don't like are the lack of exception handling, and no automatic memory management. I understand for game programming why these aren't going to be a part of the language. At the same time, I fear that without these, it may relegate the language to something of a niche language only used for game development and nothing else. While it is laudable to think that these features aren't needed, there is a reason they became available - and it mainly has to do with the fact that even "good programmers" aren't "perfect programmers"; we are all humans, not machines.

Features that make the language stand out, though, are the ideas of functions that run at compile time, which allow for a build system that is written in Jai and builds on compile (so you don't need to learn some other "language" just for building your world), the whole AOS/SOA mess that is made simple to implement with only one keyword (kinda neat!), plus the whole "uplift" of code from inner to global usage, with minimal changes, as it morphs from "lines of code" to "capture" to "anonymous function", etc - that's pretty powerful.

The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor. There's one part on this that I question - namely that variables are declared like:

name: type = value

...so:

foo: int = 0;

...but functions are defined as:

name := () -> return_type {}

ie:

bar := () -> float {}

I would have thought that a function would be defined as:

name: return_type = () {}

so:

baz: float = () {}

...thus more like the variable declarations (plus it would allow for turning a variable into a function easier, perhaps). There is probably something about compiler design, parsing, etc that I don't know that pre-empted things? That would be my first guess as to why this difference exists, but I would love to hear the actual reason from the author, if he reads this.

[imron]

> The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor.

Go, Rust, Swift, Ada, Pascal - languages both modern and old also use that inverted syntax and it's not such a burden to get used to.

> I don't like are the lack of exception handling

If done properly, it's possible to do without exceptions and have more robust and readable code - see for example Rust with its Error type and the try macro/? operator, which I've found I much prefer to exceptions.

[harrisi]

I'm not an expert at parsing, but one main issue I can imagine with having the same syntax for declaring functions and variables is that you need to look at six tokens to understand if it's a function declaration or a variable declaration. I say six because you have the name, colon, type, equal, parentheses (certainly you can't use this because then I couldn't declare a variable using parentheses, e.g., foo: int = (4 + 5) * 3;), and finally a pair of curly braces. And even then, I don't know Jai at all so it may be legal to use them in variable declarations.

With the name := () -> return_type {} syntax, you know whether it's a variable declaration or function declaration after two tokens: name (for either), then colon or colon-equal to differentiate the two.

[ndh2]

> no automatic memory management

Pretty sure Jai is already powerful enough that you could add this dynamically to any program.

[pjmlp]

Then by that point of view, C (hello UB), Python, Ruby, JavaScript, Java, among many other programming languages have failed as well.

Using my favorite scripting language (Python) as an example, I always need to check which version is installed on a given OS and then validate at https://docs.python.org/ if all the features I want are actually available on that version.

Not to mention CPython, PyPy, Cython, JPython differences on top of that.

[ksk]

Which other systems language allows the same style of programming while giving the same performance? You pretty much know if and when you need C++ - which is rare unless you live near the hardware.

That said, I'm not sure how you wish to engage people here with that comment. Do you have any specific criticisms of C++ (there are many!) that we can discuss beyond your personal feelings?

[sqeaky]

I would disagree that C++ is only useful "near the hardware" I have spent the bulk of my career not near the hardware and have found C++ to be the most useful of languages I have learned. My current job is as close to the hardware as I have gotten, I am even on the "Firmware Team" and I feel pretty removed.

If you need interop between two languages you almost always have to drop to C, if you want to do that while keeping high level concepts like object, then use C++.

If you need more performance and you have already maxed out perf in some "higher" language. Then a naive C++ rewrite is often just faster. Then when you start breaking out C++ profiling tools and carefully managing memory you get insane speeds that didn't seem possible before.

With some of new stuff in C++11/14/17 it is actually fun to work in C++, not as fun as Ruby... up until 3d things start appearing on the screen.

[ksk]

>I would disagree that C++ is only useful "near the hardware"

Okay, but I didn't say that? I said C++ has limited uses, _unless_ you're near the hardware, where its much more common. You can disagree, but its better if you disagree with what I actually said :P

But to your reply, Personally, I don't agree that C++ is fun to work with. Like any other language, I tolerate it as and when I need to. And like I said in the previous reply, sometimes C++ is the only choice, and you accept that and do the best you can. I've found that good tooling does reduce some of the headaches, especially when it comes to debugging (although stepping through optimized production code still remains a giant pain in the ass). I'm happy that the language is progressing and with all of the new features, its like a cafeteria where you chose what you like and what works for you and your team. I certainly don't agree with all the advice that the C++ cheerleaders put out on the internet about inserting every new feature into production code. Personally I take a very conservative approach and only use features that have shown tobe useful across the entire dev cycle of - helping to conceptualize an idea, being easy to reason about by everyone on the team, being easy to debug, and being reliable enough for 24/7 execution (though this applies more to the library side of things). My code runs automation machinery, and it has to have zero bugs in it. I choose C++ because currently its the best tool for the job.

[sqeaky]

I figured that by providing examples of where C++ was required that cases near those were it is used but not required would be evident.

In pretty much every type of application domain there are a large number of C++ applications. It is used in finance, business, games, medical, as you point out it is used very close to the hardware particularly when that hardware is custom and image the web with many fewer browsers and servers. The only kind of developer that might outnumber C++ devs is Java devs because there are so many custom internal enterprise applications that place higher emphasis on being barely functional than performant (and they are largely correct in their decision).

I find no need for your needlessly specific separation of limited vs whatever my wording used. I hope that whatever your take from this, should you choose to continuing nitpick, is that C++ is hugely useful in many places it just is new and glamorous so it doesn't get much press.

[0xbear]

Fun to work with? Perhaps not. But 99% of the software you're using to post your reply (and generally do just about anything on your computer) is written in some derivative of C or C++. So C++ has that going for it, which is nice.